Inaccessible Boot Device error in Windows 10

Here is some info that might help others:  In my last post I asked for new methods to deal with the latest "bad" update to ver .248 by KB4074588 Rollup.  Since no one answered, and I had 2 machines to repair after failing to boot with that version, I have again been experimenting after finding that the previously detailed "remove-package" method no longer works if you are at ver .245 or .248 .  Note that the following will NOT help everyone in this boat.  As are most of us in the industry, I am very insistent that my customers run backups.  I have convinced most to use Veritas (previously Symantec) System Recovery (previously Norton Ghost) image backup.  I won't say or debate that this is the best image program out there, but it has save MANY machines over the years I have been using it.  IF YOU HAVE image backups, the following process may help you recover a machine failing to boot after a failed .248 install.

The two machines I have that won't boot were in the same state:  Failure to boot after trying to install  KB4074588 to version .248, Feb 13 or 14.  The best recovery method for "inaccessible boot device" previously posted here (following is a combined summary of steps posted by a few of us) was to remove bad rollup packages from January, achieve a "one-time" boot, do an in-place upgrade using the media creation tool, then manually installing the most stable update (imo) KB4058258 to version .214 and postponing future updates for 35 days with the hope Microsoft will finally provide us with a proper fix in that timeframe.  Then, after Feb 14 or so, we were faced with ver .248 machines unable to boot and we find the "remove-package" repair method outlined above no longer works.  What to do??? 

Help for this case IF YOU HAVE A C: IMAGE

I restored the C: drive image taken by Veritas System Recovery on those 2 machines to an image created before Feb 14.  Before doing this, I saved away a few user files and maybe an email store from the last few days since that data was about to be overwritten with the image from before Feb 14.  After restoring the image I could boot successfully.  I then made sure there was no internet connection to avoid updates from downloading and then ran the dism get-packages command and found that I was running ver .192.  This rollup package was marked as "installed" and is easily removed with the dism remove-package command and the process we have previously used successfully.  After removal I was running ver .125 and could do an in-place upgrade (still at .125 after the inplace upgrade)  and then manually install the KB4058258 to "good" version .214.  Make sure system protection is on, create restore points along the way and make sure updates are deferred.  I have ONE machine running the home version and need to determine how to avoid updates since the defer option isn't present.  Let me mention that at first, I restored to a C: image taken on Feb 14.  The machine still would not boot after this image restore because the bad .248 update package was probably already downloaded and waiting for a reboot.  Moving to an image from Feb 13 allowed a successful boot followed by package-removal.

Note one question in my own mind:  After the package removal and being at ver .125, I'm not sure the inplace upgrade is required because you are still at ver .125 after it completes.  I do it anyway because I know it "clears the decks" of any waiting "bad" updates.  I then manually run the update to ver .214.

Hope this helps some of you.

"We who support Microsoft products for the world need their help NOW!!"

Thank you handstand2001.

However, I am trying a different strategy.... play the clock. I was able to do a system restore to a late Dec 2017 image. After reading a few posts and other places it appears this issue might be attributed to more than one KB — January to February 2018 time frame. Interestingly, KB4014329 is one and is from about a year ago -check here. Meanwhile, my system is back and Norton has updated fine.

Seems KB4074588 is the most recent (Feb 13) - catalog update as of Feb 18 13:05 AZ time. So I decided to be healthily skeptical. I turned off Updates until a proven cumulative KB is in place. I'll monitor these posts closely. I am hoping this matter is root caused properly and fixed without reservations or doubts sometime in coming weeks. Once fully tested and vetted by the community, I will turn back on Updates. 

PS: It appears Ira Shapiro, Susan Bradley and a few others are relentless about solving this matter— my gratitude and appreciation to them.

In this case, X drive is not your OS drive, it's the temporary environment that you're booted into (Via Windows install disk/drive, or Windows recovery environment). In order to find your OS drive, follow these steps

• > Diskpart
• > List disk
• Single out the number on your hard drive disk. There may be only 1
• > select disk x           (x is the disk number)        (e.g. "select disk 1")
• > detail disk
• The largest partition on this should be your OS, and you can see the drive letter associated with it

There are other ways, like guessing what drive letter it is, but this is the most reliable, IMO.

When I boot into a recovery environment, it's pretty common for the temporary environment ramdisk to get the letter X and the OS partition to be the letter D.

Win 10 Pro, Version 1709, OS Build 16222.192

I need assistance, I have been impacted by this latest MS update in early Feb 2018. I have tried Dism /Image:X:\ /Get-Packages (X is the drive in my case, also put a space between \ and /). I get the following:

"The /Image option that is specified points to a running Windows installation.

To service the running operating system, use the /Online option. For more information, refer to the help by running DISM.exe /Online /?"

What is this about?