[continued from previous message]   
      
   >> So when I first tried the windows (10) disk in my EFI box maybe I didn't   
   even have it in compatibility mode (or maybe I did, can't remember), it failed   
   to boot and THAT's when I lost the plot completely thinking 'well maybe   
   something's wrong with my    
   clone of the disk' and OTHERWISE unsuspectingly I just swapped it for the   
   (only) original one. In those few seconds win-10 on both got trashed (I   
   suspect by the w10 installer but don't really know).   
   >>   
   >> If I knew what got changed I could maybe try to fix it before beginning all   
   over but as it is I don't even have a working legacy BIOS departure point any   
   more :-(   
   >>   
   >> BTW, having made several w10 freshies, I found the USB installers made with   
   the WoeUSB linux utility fairly good AND persistent. The one made by the MS   
   uti (on my laptop 'for another computer' which is my only windows also box)   
   never worked at all,    
   and the ones made with Ventoy got invariably destroyed for each 2nd attempt   
   (see prompt blowup in image).   
   >>   
   >> https://imgur.com/59mcvHC   
   >>   
   >>   
   >   
   > The boot menu is in a file called "BCD". The internal format is "registry   
   file"   
   > but that never comes up when using tools to work on it. I mention that in   
   case   
   > your hex editor examination shows "binary" and you are wondering why it is   
   binary   
   > inside. They used a registry format, as a storage format for small objects.   
   >   
   > It takes somewhere on the order of four specific commands, to make a brand   
   new   
   > BCD file appear before your eyes. But because there are other files that   
   > are typically nearby, we don't usually "start from scratch" all that often.   
   >   
   > Instead, we're looking for the directory where that is located, and   
   > doing something to augment the file.   
   >   
   >     bcdedit                        # Dump the BCD file that the system   
   booted with (good when OS is working)   
   >   
   >     bcdedit /store C:\boot\BCD     # Dump the BCD file from selected   
   location (while using install DVD to do maintenance)   
   >   
   > Here are two pictures showing the Legacy and UEFI boot devices I have on the   
   other machine.   
   > I'm showing these pictures, as the partition structure is a bit less noisy.   
   >   
   >    [Picture]   
   >   
   >     https://i.postimg.cc/7L4JqvX0/legacy-boot-example.gif   
   >   
   >    [Picture]   
   >   
   >     https://i.postimg.cc/zGZVkms6/UEFI-boot-example.gif   
   >   
   > As an example of a "thing" you would do with bcdedit while   
   > the OS is running, these kinds of commands set the OS description   
   > in the on-screen boot menu, early in boot. The "identifier",   
   > can be spotted when you use the "bcdedit" command without parameters.   
   > and the "identifier" is context sensitive. It may appear with   
   > a different value when you are booted using a Windows installer DVD   
   > and the Troubleshooting Command Prompt window.   
   >   
   > bcdedit /set {current} description "Windows 10"   
   > bcdedit /set {default} description "Windows 10"   
   >   
   > If I was booted from the DVD, I would do them similar to this. The boot DVD,   
   X: is the system partition.   
   > Leaving C: available as a letter for this sort of repair activity. Notice   
   when I am using the DVD   
   > like this, I have to "know my stuff" to target the correct BCD file.   
   >   
   > bcdedit /store C:\boot\BCD   /set {current} description "Windows 10"   
   > bcdedit /store C:\boot\BCD   /set {default} description "Windows 10"   
   >   
   > *******   
   >   
   > General rules of thumb (you know these already):   
   >   
   > 1) Since "usually", the dependencies of an OS are on a single disk drive,   
   >    it makes the most sense to have boot material for it, right on that same   
   drive.   
   >    This allows BIOS steering to the drive, if and when needed, for   
   emergencies.   
   >   
   > 2) You are certainly allowed to have a boot manager on disk 1, and jump over   
   >    to disk 2, using GUIDs or UUID or identifiers of that sort. But you also   
   >    want whatever OSes on disk 1, to be bootable from the disk 1 boot   
   materials.   
   >   
   > 3) This means, the BIOS could point at disk 1 for "machine-wide" boot, or   
   >    the BIOS could point to disk 2 for "disk 2 specific boot". There can be   
   >    a boot menu on disk 1 and disk 2. The only time this gets confusing,   
   >    is when you do "sudo update-grub", and there could be the odd surprise   
   >    depending on the configuration.   
   >   
   > If I was in the room, the Windows disk with the boot problem, first   
   > we'd have to figure out whether the recommended rules were followed   
   > ("only have the disk receiving an install, connected during the install").   
   > If that was the case, then repairing the boot-ability, could again   
   > be performed on the single disk.   
   >   
   > You will notice in my picture, I used "diskmgmt.msc" to display the   
   > disk setup in Windows. And the labels hint where key materials have gone.   
   > If "System", "Boot", and optionally "Active" are smeared over the two   
   > disks, this presents some challenges, and you have to decide what   
   > you want to do as a Wizard. You can move some of the materials around.   
   > I've done that a couple times, when something was in an awful mess.   
   > The purpose of moving the items, would be to try to get all those   
   > key identifiers lit up on the one disk.   
   >   
   > I can't go much further than that, as with a non-booting system, even if   
   > we cable up the two forensic project disks to a third Windows system disk.   
   > the booted Windows will only show its own identifiers and not where   
   > everything is smeared on the other two disks. It's going to be   
   > a challenge to figure this out. By dumping the BCD file, there could   
   > be hints where the BCD is pointing. But again, no guarantees. It's all   
   > a bit of a puzzle at times, that's for sure.   
   >   
   > *******   
   >   
   > Preparing Macrium Reflect "Rescue CD", starts with the installer.   
   > I need some odds and ends to do a demo, so I'll try to post later.   
   > If your maintenance OS was 64-bit, you could use the 64-bit one.   
   > The reason for using the 32-bit one, is when booted from that,   
   > a small number of GUI-oriented win32 programs will run under that   
   > environment, which can be useful at forensics time.   
   >   
   >    https://download.macrium.com/reflect/v7/v7.3.6284/reflect_s   
   tup_free_x64.exe   
   >   
   >    Name: reflect_setup_free_x64.exe   
   >    Size: 115,719,576 bytes (110 MiB)   
   >    SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8   
   >   
   >    There is also a 32-bit one. For 32-bit setups.   
   >   
   >    https://download.macrium.com/reflect/v7/v7.3.6284/reflect_s   
   tup_free_x86.exe   
   >   
      
   OK, here is the artwork to go with preparing Macrium Rescue   
   so you can use the Boot Repair in the menu. This is one of   
   the "longer trips to fetch a pail of water". Since the Rescue CD   
   is an ISO, you can make a CD/DVD or you can make a USB stick,   
   depending on what fits your setup best. Not everyone has sufficient   
   sticks sitting around to put everything on a stick.   
      
      [Pictures]   
      
      https://i.postimg.cc/3RRxzNwf/Reflect7-Install.gif   
      
      https://i.postimg.cc/63mpKK2W/Macrium-Media-Builder.gif   
      
      https://i.postimg.cc/fLtJJkht/rufus-boot-stick.gif   
      
   You would try that with the Windows disk drive by itself,   
   then afterwards if things go well from the Rescue session,   
   try booting Windows.   
      
   It's generally always best to work with a clone, when   
   doing forensic quality work. I've ruined a good many   
   disks over the years doing this sequence, and clones   
   are best for it (live and learn).   
      
   In terms of boot repair, you try Macrium first, then   
   any Windows automation for repair comes second.   
      
      Paul   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)