Inaccessible Boot Device error in Windows 10

I have been working on the process of elimination to figure out exactly what happened to this particular machine (have it encapsulated in a VM in Hyper-V, with a checkpoint created at the original, broken, state so I can make a change and revert it easily), and found that this particular computer was getting the Inaccessible Boot Device stop error because there was some missing data in the Services portion of the ControlSet. Here's the data I had to import into the registry to get it working again.

Note, in this, the SYSTEM hive is loaded as "system-fresh"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\system-fresh\ControlSet001\Services\ACPI]

"ImagePath"=hex(2):53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,\

  72,00,69,00,76,00,65,00,72,00,73,00,5c,00,41,00,43,00,50,00,49,00,2e,00,73,\

  00,79,00,73,00,00,00

"Type"=dword:00000001

"Start"=dword:00000000

"ErrorControl"=dword:00000003

"DisplayName"="@acpi.inf,%ACPI.SvcDesc%;Microsoft ACPI Driver"

"Owners"=hex(7):61,00,63,00,70,00,69,00,2e,00,69,00,6e,00,66,00,00,00,00,00

"Tag"=dword:00000002

"Group"="Core"

[HKEY_LOCAL_MACHINE\system-fresh\ControlSet001\Services\ACPI\Parameters]

"WHEAOSCImplemented"=hex:00,00,00,00

"APEIOSCGranted"=hex:00,00,00,00

"CPPCRevisionGranted"=hex:00,00,00,00

"WppRecorder_TraceGuid"="{03906a40-cce8-447f-83f4-e2346215db84}"

I'm sure this isn't the only reason this error pops up, but it's the reason this computer got the error. Immediately after importing this into the registry, rebooted and the OS booted without issues.

I am delighted to report that this registry fix worked for me! Thank you!

This was an older Intel BIOS Win 10 x32 Pro system that was seemingly permanently dead after I neglected to heed the warning to IMMEDIATELY start an in-place update if and when you get your desktop back after the BSOD using System Restore, DISM or whatever.

I thought I tried everything: restoring older versions of the system drivers, using DISM /cleanup-image /restore-health, using previously mentioned registry tweaks. Nothing got past the Inaccessible Boot Device error.

So on Friday, a few hours before you posted your solution, I reluctantly performed a Reset PC, losing access to all of my installed programs (but not my data files, whoopee!).

Fortunately, as I discovered, all was not lost.

First, I called up regedit on my now-working PC and went to the ACPI branch noted above to discover that on a freshly installed/reset PC, the keys in this branch exactly matched the keys shown above. I exported the branch and printed it, too for reference.

After closing regedit and using explorer on drive C:, I browsed the C:\Windows.old folder created by Reset PC. It contained saved copies of the original root directories before the reset: PerfLogs, Program Files, ProgramData (hidden), Recovery, Users and Windows.

I decided to manually Go Back to a Previous Build, while saving the current working build.

First, I started regedit and loaded the system hive located in C:\Windows.old\Windows\System32\Config\Sysetm into a key named system-fresh (as noted above). I navigated to HKLM\system-fresh\Controlset001\Services\ACPI and both exported the branch and printed it.

There were 3 discrepancies:

There was a new key "Deleteflag" with DWORD value of 1. It should be deleted (not just set to zero).

The key "Start" had a DWORD value of 4. It should be 0.

The key "Owners" was missing. It should have a REG_MULTI_SZ value of acpi.inf

I then booted into the RE environment to a command prompt.

In the root of the D: drive (my windows drive) I created a Windows.new directory:

d:

md Windows.new

I then used the move command to move the 6 directories listed above from the root directory into the Windows.new directory:

move PerfLog Windows.new\PerfLog

etc.

Note: Use

attrib -s -h Recovery

to unhide the Recovery directory and

attrib -h ProgramData

to unhide the ProgramData directory before you move them.

Then I used the move command to move the 6 directories listed above from the Windows.old directory to the root directory:

cd \Windows.old

move PerfLog \Perflog

etc.

Note: Use

attrib -h ProgramData

to unhide the ProgramData directory before you move it.

Use

dir /a

to ensure there's nothing left in Windows.old

Then switch back to the root directory and use attrib to reapply the following atributes:

cd \

attrib +h +s Recovery

attrib +h ProgramData

At this point I exited and rebooted the system.

I could see from the disk activity light that I no longer had an inaccessible boot device.

But within 30 seconds the system rebooted on its own. After the second such reboot, I was back in RE.

This was probably the result of the February CU.

At this point I did a system restore to my earliest Restore Point. When I was done 30 minutes later I restarted the system. I rebooted, and was actually pleased to see the BSOD again.

Back in RE I ran regedit and loaded the system hive from D:\Windows\System32\Config\System, named it system-fresh again and made the 3 registry changes mentioned above. (Unload hive, exit regedit.)

I then used

DISM /image:d:\ /get-packages /scratchdir:d:\

to get a list of installed package. I removed the last listed rollupfix with

DISM /image:d:\ /remove-package /packagename:[the package name copied with my mouse] /scratchdir:d:\

and after about a minute it was removed.

I exited the command prompt and continued to Windows 10.

No BSOD! No reboot after 30 seconds! I made a point to disconnect the network cable at this point.

But it did take at least 15 minutes of watching those spinning dots before I got back to the original desktop with all my programs intact!

I plugged in a windows 10 usb stick and am now in the process of doing an in-place upgrade (no updates!) back to 1709 which will take 90 minutes to finish.

I couldn't be happier.

Space between /remove-package /packagename is missing.

From 

https://aka.ms/I72l5n

Thank you so much for this!  I thought for sure I was dead in the water, and I had already tried a bunch of other troubleshooting tips I had found online (but none worked).  I watched a bunch of YouTube videos, too, but no one had this exact fix listed.  My Rollup Package ended up being the first one I removed, which was dated January 15, 2018.  I was skeptical that removing it would do the trick because Automatic Repair loop didn't start happening until Feb. 8th or 9th, but it worked!  I don't typically reboot my computer that often; I usually leave it running so maybe that's why I didn't experience the issue until weeks later.

Anyway... THANK YOU!

Mark