Inaccessible Boot Device error in Windows 10

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

Showster,

It worked.  Thank you, Thank you. This repaired the Inaccessible Boot Device error on my Dell XPS8500 PC.  I have Windows 10 Professional operating system. 

<moderator Susan note:  I'm going to flag this as the answer just to let folks know of a workaround.  The true answer to this is to find the root cause of the problem and ensure it never happens again. Microsoft is working on a long term fix>

https://support.microsoft.com/en-us/help/4075150/how-to-recover-devices-from-an-unbootable-state-after-installing-the-j

Follow that KB first and be aware you have one shot at those commands.  Posters here have reported that if they futz around do various other commands, they lose the ability to follow that KB.  So hopefully you have come here first and read this post first.

Note to those reading this:  Make sure you put a space between the two \ and / in this command: Dism /Image:D:\ /Get-Packages

More guidance - https://www.reddit.com/r/pcgaming/comments/7sbkxc/howto_fix_inaccessible_boot_device_caused_by/

Worse case scenario (1)  - do a refresh of the operating system that doesn't lose your data but will mean you'll need to reinstall the programs.

Once you complete the dism boot with a Windows 10 ISO and go into troubleshooting and choose to refresh the operating system.  Look here:  https://www.tenforums.com/tutorials/2294-boot-advanced-startup-options-windows-10-a.htmlfor more details.

Worse case scenario (2) reinstall the operating system.  It's my understanding that the issue is no longer triggered by the Feb updates and thus if you reinstall by downloading media from https://www.microsoft.com/en-us/software-download/windows10 that you won't catch the faulty code.

Be aware that both this issue (inaccessible boot device) and missing usb devices have the same root cause - a key driver is being uninstalled and is not being reinstalled during the patching process.

I would strongly recommend going forward that if you have a configuration that you must keep - have a plan to make a full backup of your system.

If you are still getting this error on clean install or refreshed systems AFTER Feb 2018, please post here or pop me an email at sbradcpa-at-PacBell.net (change the -at- to @) and I'll set up a support case.

<End moderator note>

Meanwhile, I was able to not only find the root cause (Veritas System

Recovery causing a GSOD/"inaccessible bloot device"), but also a

solution:

Starting with 17063, Microsoft obviously changed the default behaviour

i.r.t. "Legacy File Systems", causing Veritas' (or any other vendor's)

file system filter driver (for Veritas: "vtrack") to NOT be started,

raising system event 1205 ("Windows is configured to block legacy file

system filters").

As a consequence of ignoring this file system filter driver to be used,

the GSOD/"inaccessible boot device" will be thrown.

This can be solved (bypassed) by explicitely allowing "Legacy File

System Filters" with below registry setting to be added :

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\I/O System]

"IoBlockLegacyFsFilters"=dword:00000000

Hope this helps.

Hi,

same story here:

17046 was running fine, and after attempting to update from 17046 to both 17063 and 17074 I always received a GSOD with "inaccessible boot device" on two different systems.

After trying to pin down the trigger I was able to identify the root cause (on both systems): in my case it's definitely Veritas System Recovery (formerly Symantec System Revovery) 16 SP2 (16.0.2.56166).

After uninstalling VSR, I was able to succesfully update from 17046 to 17063 and also 17074, and after re-installing VSR then I again ran into a GSOD with "inaccessible boot device" at the next boot.

Veritas does not offer any support for Windows preview versions, so I hope they are aware of that issue already and will provide a fix for version 16 (though there also seems to be a Beta program for some version 18 at the moment) before 1803 will become available.

BTW, also O&O DiskImage 12 (which I tried as some alternative for disk image backup) seems to be incompatible with 17063 and 17074, as I also ran into a GSOD (I believe it was "Reference by Pointer") at the next boot.

I will try DISM the next time it happens. I believe it is an issue with the latest security updates, but it is affecting all types of machines. Mostly older computers, but we run Intel processors primarily.

I've had it happen on 3 different, older laptops running Windows 10, both 32- and 64-bit versions. It definitely occurs after one of the Windows Updates applied during January 2018. In all cases, chkdsk and sfc showed no major problems.

In 2 of the 3 cases, I fixed it using System Restore to go back to a time before the Windows Updates were installed. Both systems required 20-40 minutes to complete, which was much longer than I would have expected, but they did complete eventually.

After rebooting those systems, I reran Windows Update. The January 2018 updates installed without issue and I was able to reboot successfully.

Unfortunately, the default configuration of Windows 10 is to have System Restore disabled. This was the case on the third system, a very old Acer laptop which I was using mostly for testing purposes of older hardware. Without System Restore, the only other option present was to do a System Reset. That completed successfully, but I lost all of the non-store apps installed on this machine.

I would strongly advise everyone to turn on System Restore on their main disk drive, allocating about 5% to keep an adequate number of restore points. System Restore does not add any noticeable time to Windows Update on Windows 10.

If there's another way to test for and fix a damaged or missing disk driver (Intel SATA in this case) on Windows 10 from the repair console, I would appreciate a pointer. This has to be done only with the resources already available on the broken system.