SOLVED Illogical BSOD - Inaccessible Boot Device with RAID

[CMOSman]

The problem: system worked well for many months until a USB insertion somehow caused a reboot, but unknown to me, with a reset BIOS, so SATA RAID reverted to SATA AHCI. The boot locked up. On reboot I checked BIOS, found the change, and reset back to RAID. From then on, I have been plagued with a BSOD – Inaccessible Boot Device (BSODibd).

PC Specs: ASUS PC; MFA 78L M/B; AMD FX-6300 6 core @ 3.5 GHz; 16 Gb; 2 Tb RAID 1 (configured with 4 Win partitions (3P+1L),. Retail Win 7 Home x64 upgraded to Win 10 Home x64. BIOS boot/MBR. Multi-boot of Win 10 and unused Win 7.

I can’t afford a complete re-install (would take weeks to customize and activate everything), and I have no idea when/whether this might happen again. So far I’ve spent weeks discovering that no one seems to have a real handle on this error, since “all the usual suspects”, recovery tools, and explanations don’t seem to apply to my situation. In the end I may have to partially install and then copy backup data (minus BCD) but I need to understand what is causing this error.

Resources: Win 10 Recovery USB; Win 10 & 8.1 PEs and software;; Easy Recovery Essentials (Easy RE - Linux-based system for auto repair of Win 10 boot issues); multiple full backups of all data, including Windows hives at time of failure; Win 10 backup image from just after Win 10 install and initial config (except that when I checked, the BCD store in the image is dated with the date of the first BSODibd, while all other files are from months ago – which scares me since I don’t know why/how the image was modified for just this.)

What I’ve tried and considered:

1. Disk signature collision (Win 10 saw RAID drives as clones)? – Nope. Signatures @ h38 in all h110..01 (device) and h210..01 (OS Device) Element keys in BCD store=signature of RAID drive

2. I tried “generalizing” the BCD (Device boot) for the Bootloader and Boot sections with the result>BSODibd. Tried GUID of boot partition (\HarddiskVolume2) in BCDEDIT and it set C: as result in BCD, as it should) then BSODidb.

3. Hardware error: extremely unlikely to have the same hardware error on both RAID disks at once. Chkdsk shows OK. Registry error: should not be possible because the error occurs before an OS is selected.

4. Easy RE. Useless - didn’t recognize the standard Promise/AMI firmware RAID device (everything else does), sees no partitions, and thinks disks may be GPT not MBR (??).

5. Recovery USB. Useless. After Startup Repair->BSODibd. Even tried Reset but >Hard Drive Locked (it’s not; chkdsk is fine) so no joy. Diskpart does nothing useful since everything appears fine to it. SFC says some files not corrected (it always seems to say that); all BOOTREC and BCDBOOT command options work, including /REBUILDBCD then >BSODibd.

6. After several boot attempts, “Attempting Automatic Repair” appears, then offers a keyboard selection screen – but neither keyboard or mouse works to select so manual shutdown is forced, chkdsk to fix leftovers, then >BSODibd.

7. Partition software (about 6 different ones using Win PEs) all show MBR and partitions as perfect, and I know the pre-boot gets to the BCD because if I intentionally mistype the loader entry with BCDEDIT, it does cough and tell me the loader is missing.

8. Dual Boot Repair Tool, EasyBCD and other tools result>BSODibd



So something else is going on. Anyone have any other explanation or ideas?

 

[Trouble]

Any reason to suspect that there might be a problem with your Promise Raid controller card?

I think what I would do would be to reinstall Windows 10 and then use my disk image to restore only the Windows partition, leaving any other partitions untouched.
I use acronis as my disk imaging utility and when restoring from an image I can uncheck the partitions from the list of partitions in the image that I do not want to restore.
Unfortunately if your only images were created with the Windows native disk image utility, I don't think that it supports this kind of recovery.

What you might be able to do, in advance of any further steps, given you have a second machine.
Download the free trial of Acronis and install it on the second machine, use that to create the bootable rescue media.
Use that to boot the problem machine and backup the Windows partition to external media completely offliine.
Plug that external media into the second machine and mount the .tib (image file) using Acronis and explore it to confirm that it contains what you would expect it to contain. Open an image file, open a document, open a music file and play it, etc.
IF you have other critical data partitions back them up separately as well, mount them and inspect their contents.

Assuming that all or any of that goes as planned, then I think you might safely be able to reinstall Windows 10 and then restore those partitions, without concern regarding the System Reserved partition containing the BCD information as those will be newly created with the custom clean install of Windows 10 and presumably functioning as they should.

Just a shot in the dark kinda best guess as to what might possibly work.

 

[Saltgrass]

Any chance of getting a Disk Management picture of your system and an attached BCD store listing using the bcdedit /enum all options?

with a reset BIOS, so SATA RAID reverted to SATA AHCI.

This sounds a little strange since if the controller had been changed it probably would not have been able to boot to a RAID install. But it does make me wonder since there is a Firmware device in Device manager, which I assume if for UEFI only type bioses.

What type of USB device was this which caused such havoc?

Have you tried repairing the RAID array which you might be able to do by hitting some special key, maybe CTRL-a, during boot? The specs on the M/B say it uses an AMD SB710 Storage controller... You are using a Promise controller in addition? Have you disabled the controller which you don't use?

The motherboard specs also specifies the SB710 controller for both the Storage and USB devices... I don't remember seeing the same controller use for both, but I don't run AMD boards.

 

[CMOSman]

Any reason to suspect that there might be a problem with your Promise Raid controller card?

I think what I would do would be to reinstall Windows 10 and then use my disk image to restore only the Windows partition, leaving any other partitions untouched.
I use acronis as my disk imaging utility and when restoring from an image I can uncheck the partitions from the list of partitions in the image that I do not want to restore.
Unfortunately if your only images were created with the Windows native disk image utility, I don't think that it supports this kind of recovery.

What you might be able to do, in advance of any further steps, given you have a second machine.
Download the free trial of Acronis and install it on the second machine, use that to create the bootable rescue media.
Use that to boot the problem machine and backup the Windows partition to external media completely offliine.
Plug that external media into the second machine and mount the .tib (image file) using Acronis and explore it to confirm that it contains what you would expect it to contain. Open an image file, open a document, open a music file and play it, etc.
IF you have other critical data partitions back them up separately as well, mount them and inspect their contents.

Assuming that all or any of that goes as planned, then I think you might safely be able to reinstall Windows 10 and then restore those partitions, without concern regarding the System Reserved partition containing the BCD information as those will be newly created with the custom clean install of Windows 10 and presumably functioning as they should.

Just a shot in the dark kinda best guess as to what might possibly work.

 

[CMOSman]

Any chance of getting a Disk Management picture of your system and an attached BCD store listing using the bcdedit /enum all options?


This sounds a little strange since if the controller had been changed it probably would not have been able to boot to a RAID install. But it does make me wonder since there is a Firmware device in Device manager, which I assume if for UEFI only type bioses.

What type of USB device was this which caused such havoc?

Have you tried repairing the RAID array which you might be able to do by hitting some special key, maybe CTRL-a, during boot? The specs on the M/B say it uses an AMD SB710 Storage controller... You are using a Promise controller in addition? Have you disabled the controller which you don't use?

The motherboard specs also specifies the SB710 controller for both the Storage and USB devices... I don't remember seeing the same controller use for both, but I don't run AMD boards.

Sorry for the previous empty reply. Recognize.that the controller is built in to the mobo and when I reference Promise it is because it's firmware is the basis of most mobo RAID implementations. There is nothing wrong with the RAID drive and so there is no option to rebuild. In fact there is nothing apparently wrong with anything just that the boot process makes no sense as defined so far since nothing addresses the root.cause.

I'll get the BCD listing and Disk Management listing tomorrow as I have to crank it up with the 8.1 Win PE to get the latter.

Thanks for the response in any case.

 

[CMOSman]

Any reason to suspect that there might be a problem with your Promise Raid controller card?

I think what I would do would be to reinstall Windows 10 and then use my disk image to restore only the Windows partition, leaving any other partitions untouched.
I use acronis as my disk imaging utility and when restoring from an image I can uncheck the partitions from the list of partitions in the image that I do not want to restore.
Unfortunately if your only images were created with the Windows native disk image utility, I don't think that it supports this kind of recovery.

What you might be able to do, in advance of any further steps, given you have a second machine.
Download the free trial of Acronis and install it on the second machine, use that to create the bootable rescue media.
Use that to boot the problem machine and backup the Windows partition to external media completely offliine.
Plug that external media into the second machine and mount the .tib (image file) using Acronis and explore it to confirm that it contains what you would expect it to contain. Open an image file, open a document, open a music file and play it, etc.
IF you have other critical data partitions back them up separately as well, mount them and inspect their contents.

Assuming that all or any of that goes as planned, then I think you might safely be able to reinstall Windows 10 and then restore those partitions, without concern regarding the System Reserved partition containing the BCD information as those will be newly created with the custom clean install of Windows 10 and presumably functioning as they should.

Just a shot in the dark kinda best guess as to what might possibly work.

Re-installation of Windows is not my problem as I mentioned. I have backups that don't require the image, and I have resources to access/restore just the boot partition image if needed ,

My issue is that if I can't discover what is causing this problem, then it makes the boot process essentially voodoo, and when/if it happens again (and in my experience it will happen again).I'll have to workaround rather than solve, and that bugs me no end. I hate to think that I'll cringe every time I plug one of my many Lexar sticks.

Thanks for the response

 

[Saltgrass]

You don't have a Recovery Drive or the Install media for the latest build? You can download the install media.

And I do believe there are problems with the last build and secondary drives, but a RAID is not technically a second drive. But the problem may be based in the controller for the system which might effect who knows what..

If a Lexar Flash drive seems to be involved in the situation, are those drives set with active partitions and bootable?

You say after some boot attempts neither your keyboard or mouse work. I assume they are USB and also use the same controller as the SATA?

A startup repair on a system may take several runs. As it was in Windows 7, the system has to make some repairs before it can make others and a restart is usually required to incorporate the prior repairs. If you have run it several times and a cancel button were to be available, try it. The system might boot, unless something is amiss with the controllers on your system.

 

[CMOSman]

You don't have a Recovery Drive or the Install media for the latest build? You can download the install media.

And I do believe there are problems with the last build and secondary drives, but a RAID is not technically a second drive. But the problem may be based in the controller for the system which might effect who knows what..

If a Lexar Flash drive seems to be involved in the situation, are those drives set with active partitions and bootable?

You say after some boot attempts neither your keyboard or mouse work. I assume they are USB and also use the same controller as the SATA?

A startup repair on a system may take several runs. As it was in Windows 7, the system has to make some repairs before it can make others and a restart is usually required to incorporate the prior repairs. If you have run it several times and a cancel button were to be available, try it. The system might boot, unless something is amiss with the controllers on your system.

Thanks for the thoughts but please remember that the problem began with a BIOS reset and reboot and nothing was amiss before that. The Lexar never got fully inserted which is suggests a glitch on that port, so nothing registered, and it was data anyway.

The controllers work fine when the RAID is accessed (via Command Prompt) from the USB Recovery drive of the latest build; from all Win PEs, and when BCDEDIT is used from the Win 10 USB. Win tries to start and accesses the RAID, it just doesn't seem to get past Winload (and its not corrupted, I've tried multiple copies from my other running systems). The USB controller is separate from the SATA controller.

Startup repair has not been successful after 10 successive attempts and reboots. I have rebooted this system about 93 times so far. The Auto repair hangs on this inability to select the keyboard, and it fails each time. (and I`m apparently not the only one with this particular issue, just the only one who isn`t satisfied with a workaround, and not understanding the why of these events.

Any idea exactly what Winload accesses in the BCD and what it does after that?

 

[Saltgrass]

Winload is the Windows loader. There was someone the other day with a thread where I thought the BCD store was the problem but he ended up replacing the OS partition from a backup and the system started booting again.

All I could think was something related to the Winload since it is in the C: partition.

C:\WINDOWS\system32>bcdedit

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume2
path \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {4e9d279a-ec49-11e4-933d-a8eac534f6b4}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {4e9d279c-ec49-11e4-933d-a8eac534f6b4}
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {4e9d279a-ec49-11e4-933d-a8eac534f6b4}
nx OptIn
bootmenupolicy Standard

 

[CMOSman]

Any chance of getting a Disk Management picture of your system and an attached BCD store listing using the bcdedit /enum all options?


This sounds a little strange since if the controller had been changed it probably would not have been able to boot to a RAID install. But it does make me wonder since there is a Firmware device in Device manager, which I assume if for UEFI only type bioses.

What type of USB device was this which caused such havoc?

Have you tried repairing the RAID array which you might be able to do by hitting some special key, maybe CTRL-a, during boot? The specs on the M/B say it uses an AMD SB710 Storage controller... You are using a Promise controller in addition? Have you disabled the controller which you don't use?

The motherboard specs also specifies the SB710 controller for both the Storage and USB devices... I don't remember seeing the same controller use for both, but I don't run AMD boards.

FYI the BCDEDIT /Enum listing is below. This is the current BCD after all attempts at rebuilding it, and the list is identical to the original BCD from backups. The 300 second delay was my requirement.

Attached (I hope) is ta part of the Disk Management screen snap of the RAID and Win PE drive from today.

I think I'm getting discouraged enough that I'm going to try to find an MS technical reference for the boot process and the loader or debug it as it's running and find out what it's doing.

 

[CMOSman]

FYI the BCDEDIT /Enum listing is below. This is the current BCD after all attempts at rebuilding it, and the list is identical to the original BCD from backups. The 300 second delay was my requirement.

Attached (I hope) is ta part of the Disk Management screen snap of the RAID and Win PE drive from today.

I think I'm getting discouraged enough that I'm going to try to find an MS technical reference for the boot process and the loader or debug it as it's running and find out what it's doing.

I forgot the /Enum list, which is here:

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=C:
path \bootmgr
description Windows Boot Manager
locale en-us
inherit {globalsettings}
default {default}
resumeobject {c7bb0f6f-6c0a-11e6-b96c-f832e489d03c}
displayorder {default}
{7e823285-c727-11e5-9ce9-e6759d0cdfbb}
toolsdisplayorder {memdiag}
timeout 300

Windows Boot Loader
-------------------
identifier {default}
device partition=C:
path \windows\system32\winload.exe
description Windows 10
locale en-us
inherit {bootloadersettings}
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \windows
resumeobject {c7bb0f6f-6c0a-11e6-b96c-f832e489d03c}
nx OptIn
bootmenupolicy Standard

Windows Boot Loader
-------------------
identifier {7e823285-c727-11e5-9ce9-e6759d0cdfbb}
device partition=F:
path \boissonneau\Windows\system32\winload.exe
description Windows 7 Home Premium
locale en-US
osdevice partition=F:
systemroot \boissonneau\Windows
bootmenupolicy Legacy

 

[Saltgrass]

Since you are running the RAID, you would know better than I. Is it legal to have a Logical partition on a RAID volume? Are the drives set up as Dynamic?

You have Win 10 and Win 7 Dual Boot. I don't recognize the path entry for the Win 7 install.. Other than the two items mentioned, the rest of the Boot configuration looks OK...

I do need to check at least one entry on my Windows 7 system to see what folder the \bootmgr is in..

 

[Saltgrass]

OK, I checked my Windows 7 install and the listing is below. What I am wondering about yours is you don't show a disk volume for the bootmgr but a path and C: That might be OK but I can't say for sure. I have checked a second listing and it shows C: but the path entry (path \bootmgr) is not in the Boot Manager listing.

I have some other listings I can check tomorrow and one may be a Win 8 or 10 listing.

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {0e3be3b8-4362-11df-a0b5-d4924bc3b0e2}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows 7
locale en-US
inherit {bootloadersettings}
recoverysequence {0e3be3ba-4362-11df-a0b5-d4924bc3b0e2}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {0e3be3b8-4362-11df-a0b5-d4924bc3b0e2}
nx OptIn

 

[Saltgrass]

Here is the BCD listing from a Win 10 Legacy system. It uses a HardDisk Volume Number because the partition is not lettered, so using the C: on your system is probably OK. It still does not show a Path entry as you show so that might be messing up your boot.

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {b6edfb3d-b190-11e5-8529-e736e3ce2f1e}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {b6edfb3f-b190-11e5-8529-e736e3ce2f1e}
recoveryenabled Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {b6edfb3d-b190-11e5-8529-e736e3ce2f1e}
nx OptIn
bootmenupolicy Standard

 

[CMOSman]

Here is the BCD listing from a Win 10 Legacy system. It uses a HardDisk Volume Number because the partition is not lettered, so using the C: on your system is probably OK. It still does not show a Path entry as you show so that might be messing up your boot.

C:\Windows\system32>bcdedit

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {b6edfb3d-b190-11e5-8529-e736e3ce2f1e}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {b6edfb3f-b190-11e5-8529-e736e3ce2f1e}
recoveryenabled Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {b6edfb3d-b190-11e5-8529-e736e3ce2f1e}
nx OptIn
bootmenupolicy Standard

I believe the path setting wouldn't apply here because you have no accessible drive so it would pull the manager form the loadable Windows partition. At any rate it BSODibd's on me when I remove it.

 

[CMOSman]

To everyone who viewed and considered the problem, Thank You.

I'm going to close this out as solved, when it's not, because my answer looks like it's going to come from reviewing hex copies of disk/partition sector and boot data as is and after a partial reinstall, and deciphering the differences. I will make sector-by-sector copy of the front of the drive and save it if the problem recurs and rewrite it, overlaying the MFT and mirror sectors with their updated versions if I have to until an explanation arises.

Again thanks.