Inaccessible Boot Device error in Windows 10

Fix the issue Crysta from the source, no need for 3rd party.

I noticed a few affected computers were setup with an image, MBR and legacy boot. Anyone else have the same setup? Just wondering if I should convert to UEFI and GPT.

Also, I had the same problem where I could only remove the package once, then it came back, removed it a second time, but still BSOD. Now I can't boot and it isn't listed either.

If your on MBR now STAY THERE. It is Much, Much more flexible.... If you don't have HDD/SDD larger the 2.2 TB don't go to GPT!

I run hybrid MBR on 2x 256 GB SSD, partitioned for OS only and 2 Data Disk of 10 TB each, I have to do GPT.

Best Regards,

Crysta

Fix the issue Crysta from the source, no need for 3rd party.

You have, well you better tell everyone how to do it, they want to know.....

WIN 10 BSOD FIX - Inaccessible Boot Device - THIS WORKS!  I Just Repaired 2 computers that went down at the same time last night on 1/16/18

Good Afternoon Bobby,

Here is the fix I came across from another kind IT tech, please see below.  Credits go to them, I'm just forwarding so everyone can finally get their computers back up and running.

Boot Windows 10

Go to Repair

Go to Tools/Options to get a command prompt.

Confirm the drive letter for the Windows image. Usually D: –> dir d:

Run the following to view the installed packages which will also show a date of install.

Dism /Image:D:\ /Get-Packages

Find the package(s) that were just installed by date. Run the following command on the last installed package:

example: dism.exe /image:d:\ /remove-package /packagename:Package_for_KB4014329~31bf3856ad364e35~amd64~~10.0.1.0

Reboot.

The patch that caused my issue was from 1/6/18 or 1/10/18     Remove the latest windows update entry with Rollup Fix in it's name.  Once complete, close command prompt, turn off computer.  Power back up.  You should be back into WIN10.

If you still receive BSOD, rinse and repeat with the next latest update, try it again.  You'll eventually boot right back into WIN10.

I hope this helps.

Have a great day.

Showster

This seemed to work on three different machines - Immediately after removing the package I was able to boot into Windows, but in each case after one restart the system was back to the same BSOD.  I followed the same process again and made sure to disable Windows Updates and clear out the SoftwareDistribution folder before restarting, but it made no difference.

All three of the units required the same package removed "Package_For_RollupFix31bf3856ad364e35~amd64~~/6299.192.1.9" before being able to boot into Windows once.

Edit: I completed full windows reinstall on one of the units and it completed all available updates without issue, no BSOD so far.

Yes, precisely this worked for me as well.  I should just point out that you made a typo in the name of that package there.  It should be a 1 instead of a / at the end there: Package_For_RollupFix31bf3856ad364e35~amd64~~16299.192.1.9

Didn't think there was a way to remove update packages through the command prompt, especially outside of a bootable Windows, otherwise this would've been the first thing I tried.

Thanks everyone!

EDIT: For the record, the update needs to be blocked, otherwise it just happens again and causes the same issue.  This time, in order to get it to work, I actually had to remove both packages, the one mentioned by Rindokisuto AND the example given by Showster.  Stupid, especially if they're aware of it already...  These operating systems and incompetent teams make it seem like any useful/applicable AI is a century away.  If anything, the steps Microsoft have taken have only come in the form of a virus by the name of Cortana, and now these updates.

EDIT 2: I actually couldn't do it!..  Now, after removing the update again, I get the Error code 0xc0000225.  If I press "Enter" to "try again", it actually takes me to the Windows loading screen and then the same blue screen.  Having tried removing the other update through Command Prompt (which I don't get why I would even have to since it worked without doing that the first time), it actually fails and gives me the error 0x8000ffff.  The nightmare just doesn't end.....

EDIT 3: I have a feeling these bastards need to be ripped out right from the roots - perhaps something in \Windows\system32\config.  Anyone think they can help with this or anything in terms of what to do now?

I actually copied the files from \Windows\system32\config\regbackup back into config and this got the first removed package appearing again after I restarted.  Interesting - perhaps that suggests something...

Trying to remove it again, it fails and I get the same error as for the other one now...  How could the tool have suddenly become completely broken/non-functional?..  Is there possibly a more aggressive command using the DISM tool to perform this function which might ignore whatever's stopping it?

Looking at the log through the command prompt, it looks like the failure comes when it tries to "unload" the "offline registry hive" from several locations.  I can't scroll higher up; there's possibly more, but the first path I see it refer to is "/Users/Default/ntuser.dat".  Next line says, "Failed to unload offline registry, the client may still need it open" (who cares; delete that s***).  Then it says, "Failed to flush offline registry", referencing /Windows/system32/smi/store/Machine/schema.dat (I have a feeling this is what's causing the 0x8000ffff error).  Then it says the same thing and follows the same further progression as the previous path: "Unloading offline registry hive".  That's the last one I see there.

It then lists its finalizing actions, disconnecting whatever running providers/services and ends the session.  **Anyone familiar with the DISM command know what this can possibly have to do with or what can be done?**Any help would really be amazing at this point, as this really is ridiculous by absolutely any terms...

PS- I'm not sure if this message was there before, but actually when running the DISM /Get-Packages command, the first thing it says is, "The scratch directory size might be insufficient to perform this operation.  This can cause unexpected behavior.  Use the /ScratchDir option to point to a folder with sufficient scratch space."  Might that be the problem?  (It says the recommended size is 1024 MB - a GB - even though the main drive has actually way more.  I'm booting the recovery media off an 8GB flash drive which may have a little bit less, though none of the operations are being performed on it, so I wouldn't get why it could be a problem, unless that's where it's possibly trying to cache something.)  I actually tried including a "scratch" disk directory (the main drive), the message saying to do this went away, but the failure/error to remove seemingly any package still remains...