Win7 bluescreen when replacing DATA drive???

J

JoH

Member
OK, so it's slightly more complicated than the title, but read on...

It sounds like something that should be repaired/corrected in the registry or BCDstore, but I'm a bit hesitant to TRY fixes/repairs in these areas without being 100% sure of what's going on, because at this very moment I have a perfectly working system, and not BREAKING things is the most important. In particular NOT BREAKING my current Win7Pro installation.


So I've got a DELL Precision 7510 laptop with:

- 512GB M.2 PCIe SSD, with Win7Pro System partition
*** this is currently still the OS that I use 95% of the time, and my priority would be to KEEP this functional ***
*** EVEN if it would mean that I wouldn't be able to boot into the Win10 for a while until I reinstall everything when Win7 support stops ***

- 1TB SAMSUNG 2"5 SATA SSD, with Win10Pro System partition, and the main data partitions for the Win7Pro

When I installed the system 3 years ago, I went through quite a bit of trouble (making Win7 able to boot from PCIe for example) to get this into a dual-boot config. On top of that, and I'm not 100% sure to what extent this complicates matters, the Win7Pro System partition is encrypted with TrueCrypt. Too long ago to remember the exact details of how and in which order I achieved this.

When I boot the laptop I first have to provide the TrueCrypt password, I then get the "Windows 7 style" black text screen choice of which OS to boot, in which I also have an entry for the (not encrypted) Win10 Pro on the 1TB SATA SSD, and I can boot into either of them.



I now wanted to replace the 1TB 2"5 SATA with a new 2TB 2"5 SATA because of diskspace shortage. (both current and new SSD are SAMSUNG EVO). This sounded like a piece of cake to me, as in just cloning the contents of this drive, and it should be smooth and transparant because in my view any "important" references should all be residing on the M.2 (?)

First approach was to boot into the Win10 on the current SATA SSD, and use the Samsung data migration tool to just clone the system partition "live". However this fails at the very end of trying to transfer this system partition (offers no clues why). I then used the free "AOMEI Partition Assistant" tool, and this seems to do totally fine with for example "Disk Clone", it reports that cloning is successful, I find the partitions on there etc.

So I remove the 1TB SATA and put the 2 TB SATA with the cloned contents in the system.

BUT... WHATEVER I try(cloning partitions or full disk, sector-by-sector or just data...), not only does the Win10Pro on the new SSD fail to boot with this error:

File: \WINDOWS\system32\winload.exe
Error code: 0xc000000e

EVEN the Win7Pro (which boots from the PCIe SSD that wasn't touched!) bluescreens with:

"UNMOUNTABLE_BOOT_VOLUME"
STOP: 0x000000ED



I finally did some additional tests, trying to at least get the Win7Pro to work with the new 2TB SSD as new data drive, and forgetting about the Win10 for the moment:

- when I use EasyBCD in the Win7Pro to remove the Win10 entry from the bootmenu screen, and I also remove the driveletters from all partitions that were NOT on the PCIe SSD in the hope that NOTHING would still be referenced on other disks than the M.2, the Win7Pro (on the M.2 SSD !) STILL bluescreens with the error
- when I remove ALL partitions again from the 2 TB SSD and put it in the system, the Win7Pro (on the M.2 SSD !) STILL bluescreens with the error

- when I remove the 2 TB SSD COMPLETELY (empty slot), the Win7Pro only goes through "diskcheck" requests, but then boots just fine


Can someone explain what is going on here EXACTLY??? WHERE is Win7 referring to / depending on the original 1TB SATA, and in such a way that it ONLY is a problem when an actual disk is populating the slot, but NOT when it's entirely missing???

If there is an EASY solution that allows me to ONLY use the Win7Pro, but with the 2TB SATA available to it as datadrive, then I would be satisfied already! But I'm really hesitant to try any "automatic fix" options that could potentially bork the ability to boot my Win7Pro.
 
So here's what Disk Management shows when I'm booted into the Win7Pro:

Clipboard01.jpg

I guess the root of the problem might be related to the fact that the PCIe is seen as "Disk 1", and the SATA disk is seen as "Disk 0"... I might misremember, but it COULD be that this was the only way I found back then to get this particular configuration functional(a TrueCrypt-encrypted Win7 in dualboot with Win10, with the Win7 on PCIe)


I also tried to do some non-destructive testing, by trying to virtualize the setup via VMWare vCenter Converter. Also with the idea of keeping the Win7 around THAT way. Trying to do that, ends with an error that also refers to an inability to edit BCD etc. in order to make the system hardware-agnostic once virtualized to make it boot in VMWare workstation. In fact, when I start experimenting with booting the resulting VM from Windows installation media, and trying out all kinds of startup-repairs, "bootrec" commands etc, the maximum that I'm able to achieve looks exactly the same as when I clone the SATA disk in the physical system: my usual boot-menu where I can choose between the Win10 and Win7, a Windows 7 that APPEARS that it will boot correctly (with the fading-circling lightning balls animation running for 5-10 seconds), until the bluescreen BEFORE the actual logonscreen is able to appear.
 
You need to allocate a drive letter to Win10Pro in Disk Management and by the way, there is no such thing as Win7Pro...I think that should be Win7Ult. I made the same mistake with mine a while ago.
Once all accessible drives have letters allocated then you can use EasyBCD to boot between systems. A blue screen can occur when changing out a hard drive or SSD, but if you can get into Windows 7 then you can easily fix that.
 
Hi,

First of all thanks for replying!

I'm not quite sure what you're referring to, though...

As a reminder: the screenshot I posted is just from my system in "original" status (so with the PCIe SSD and original 1 TB SATA SSD installed). Just an illustration of the disk layout. The Win10Pro and other partitions that have no driveletter are like that on purpose, as to not accidentally f*ck it up from within Windows 7 Professional. The setup as seen there works perfectly fine with dual-booting between the 2 OS.

The ONE thing that would make me most happy right now (after trying a bunch of stuff that didn't work), is JUST to manage to put this 2 TB SATA SSD in place of the 1 TB SATA SSD, have the Win7 Pro on the PCIe NOT crash in that situation, and able to access it. If I want Windows 10 again, I'll start from scratch at some point, lol...


A blue screen can occur when changing out a hard drive or SSD, but if you can get into Windows 7 then you can easily fix that.

That's nice... But:

1) I HAVEN'T been able to get into Windows 7 in that situation (with the 2 TB SATA seated, completely empty or not)
2) it would be nice to know that "easy fix" :smile:

So yes, I was thinking along the lines that it was all about booting from installation media and doing somekind of hiveload - and registry editing - and/or correcting something in the BSD database.
 
Sorry, one piece of additional information that I forgot: when I removed the PCIe SSD from the list of bootable devices in the BIOS, the whole boot process got stuck right there, which confirms that the PCIe SSD *IS* the "first hop" in the process in the current situation. I was starting to think that maybe the SATA SSD was the "first hop" all long , but that seems not the case.
 
The difference between yours and mine are 1. I installed Win 10 from within Wn 7, all my partitions except hidden ones put there by the system are lettered so therefore accessible by EasyBCD (or appear in the boot menu if you don't want to use EasyBCD) and 2. I see an EFI partition so am not much use advising you as I don't use EFI at all.
@Terry60 can you help this poster?
 
To be clear: I don't suspect that this problem has anything to do with EasyBCD or other Neosmart products. I'm just posting this here because I suspected that these forums might contain a whole lot of detailed expertise about the boot process, multi-booting, dependencies, related things that might cause bluescreens...

The ONE finding that makes me think that this should be solvable by editing somekind of setting in the BCDstore or the registry in the Windows 7, is that I DO manage to get into the Windows 7 when there is simply NO SATA disk in the slot. So what's on that SATA SSD is NOT absolutely needed to be able to boot and use the Windows 7.

Yet, when I put the 2 TB SATA disk in there (even contents and partitions completely wiped), it bluescreens with the "UNMOUNTABLE_BOOT_VOLUME" STOP: 0x000000ED somewhere between loading the kernel and the appearance of the login screen. Like, I'm able to CHOOSE "safemode with command prompt", but then it gets stuck sometime later without the ability to USE the commandprompt.

I'm at the point that I'm willing to troubleshoot much deeper, but I need to have the idea that we're going to find something first, since it's going to require some effort. Like, the first step will have to be temporarily decrypting the Windows 7 system partition so I can access it from installation media...
 
The trouble is these forums are sparsely populated now since several of our regular posters stopped posting. So good help here is less likely than say the Seven forums or Ten Forums which are staffed by some Microsoft MVP's or even the Microsoft Community itself. I've always received good help in both places.
 
I can see one potential problem from your Disk Management screenshot.
You appear to have installed W10 as a UEFI system, but W7 as a BIOS/MBR system.
With the UEFI SSD first in line, bootmgr will need to find the EFI bootloader winload.efi not winload.exe.
It will not be capable of booting a non-UEFI W7 in any case.
You can conversely boot a UEFI installed OS from the BIOS/MBR version of bootmgr which will use the non-efi loader to load the OS.
However, you can't boot a newer Windows OS using an older version's bootmgr. e.g. W7 bootmgr can't boot W10 (invalid dig sig)
From the fact that you have apparently been doing so, the W7 bootmgr must have been replaced with the W10 version at the time of W10 installation. (That's the MS architecture to make dual-booting automatic during the installation of a newer OS alongside an older one)
Have you tried connecting the two drives the opposite way round ?
 
Hi,

thanks for taking a look!

That's a LOT to digest... (and I'm not terribly well-versed in the whole UEFI<->BIOS issue)

First of all, I don't see HOW I could "connect the two drives the opposite way around", since one is an M.2, and the other a 2"5 disk, and it's a laptop with ONLY those two bays available. Or did I misunderstand what you meant? If you mean just pointing the BIOS to boot from the SATA (where Win10 is) instead of from the PCIe (where Win7 is) : I tested that by removing the PCIe from the bootable device list in the BIOS, and then it gets stuck there and reports something about no bootable device found.

If I remember correctly, "UEFI boot" is currently disabled in the BIOS. From my vague memory of +2 years ago, I NEEDED to do that to be able to encrypt the Win7 system partition with TrueCrypt(doesn't support system encryption with UEFI). But as I said, it's a couple of years ago that I setup the system like this, and I forgot most details but I do remember that I had to trial & error a bit to get it to work like I wanted. Is it possible that the visible "EFI system partition" remained from a PREVIOUS install of Windows10 as UEFI, that I then found out that this would prevent me from using Windows 7 with TrueCrypt, and that I just reinstalled Windows 10 on the same disk as BIOS/MBR? Maybe there's a way to check in Windows 10 whether it's on UEFI or BIOS/MBR?

I also want to repeat once more that the diskmanager screenshot is from my currently perfectly functional setup.

To me the REAL mystery (and what needs to be understood and solved) still seems to be why both a clone of the SATA drive in that bay, or an empty SATA drive in that bay, bluescreen the Windows 7 on the PCIe, while removing it completely is NOT a showstopper???
 
Sorry, didn't read back carefully enough. Assumed you had 2 2.5" bays.
When you truly "clone" a system (i.e. make a bit for bit identical copy) from one device to another there's a potential problem with the BCD.
Despite how it might appear, there are no disk letters in the BCD. The ones you see reported by EasyBCD are translated for your convenience from the actual UID in the BCD which contains a hash of the unique device signature assigned to the hardware, and the offset of the partition position on that device. That human-unintelligible string is translated both ways (when you talk to EasyBCD, and when it replies) using the device/partition to disk letter map contained in the registry of the running OS.
Your BCD is pointing to the original device where W10 was installed, hence "unable to find" winload when you try booting W10 on the new SSD.
That explains your 0xc000000e error, and should be easily fixed by deleting the W10 entry from the BCD and adding it again. The translation of the disk letter you use to point to W10 will find the correct disk signature on the new device and create a correct hash in the BCD.
But that assumes that W7 boots normally, which you say it fails to do with the bigger SSD connected under any circumstances.
That is much more puzzling as it shouldn't be concerned with any other device when booting W7 on the same drive.
I can only assume therefore that it is being caused by the encryption in some way, but not having gone down that route, I'm not even sure how it works. I was going to suggest that maybe the original SSD is important to Truecrypt in some way, but your last sentence would seem to rule that out.
If your SSD is hot pluggable, you could boot W7, insert the cloned drive, then add a new BCD entry for W10 and see what happens when you reboot.
 
OK, so now we're getting somewhere indeed... The good thing is that the Windows10 boot problem has been explained by this. The bad thing is, that it doesn't get me ANYWHERE as long as the Windows 7 issue hasn't been solved as well, haha...

I think it's very unlikely that the TrueCrypt encryption has anything to do with it. TrueCrypt generally tries to work as "transparantly" as possible. The fact that Windows 7 STARTS booting, indicates to me that everything is fine there, since it can only do that in decrypted status. I do have a DATA-partition on the SATA that is TrueCrypt- encrypted, but I don't auto-mount that one, it's always by hand when I need it. So Windows7/TrueCrypt shouldn't depend on it in any way. Still wouldn't explain the difference between an empty bay and a bay with an empty SATA drive, either...

I find it very unlikely that the SATA-slot is hot-plug enabled. It's not even accessible without removing the battery first. My appetite to RISK it is extremely low LOL.

Is there any chance that detailed bluescreen information could provide (you) with more information? Or is that just as much gibberish to you, as it is to ME? :smile:

Another idea I had, was to take the 1TB SATA drive "offline" in disk management, reboot Windows 7 that way, and THEN try by replacing it with the 2TB SATA. But I'm just too afraid that it gets me into the situation that I can't get into my Windows 7 anymore as well, lol...

At this moment, I'm at the point that I would consider ordering a new 1TB M.2 as well, try to clone the Windows 7 M.2 to have a "fallback" drive, and experiment more freely with the other one. But that only makes sense if at least SOMEONE would have a reasonable suggestion where exactly the issue could be...

ONE other thing I might try though, is putting a normal 2"5 HD that I still have lying around, in there instead of the 2TB SATA. See if it still crashes THEN. I never thought that made much sense, but since it seems mysterious even to YOU, maybe it's worth a try after all.
 
Back
Top