Inaccessible Boot Device error in Windows 10

I am getting the same error after the DSIM get packages fix.  Gets to around 82% and then kicks out with Error:  0x800f0922

Hi,

I just finished repairing another one!  I've been using the Wizard's step-by-step process (thanks again to the Wizard) and want to post a couple of observations.  I made more detailed checks and observations during today's repair and uncovered a surprising fact.  Maybe someone can explain.  

System is a Dell Optiplex with Intel core i5, Windows 10 Pro 64 bit, no domain.

User reported sudden unexpected restart resulting in "inaccessible boot device" loop.

I tried system restore, which did not bring back the ability to boot.  There were no restore points before 2/6/18 so I did not expect restore to be successful.  THERE WAS NO NETWORK CONNECTION at this time.

I ran the DISM commands from the WinRE.  It identified that current version was 16299.192 (installed) and .125 superceded.

I successfully removed the .192 package and was able to achieve the "one-time" boot.  NETWORK STILL DISCONNECTED. 

I disabled AV (norton) and made sure System Protection was enabled.  I checked Winver and found that it was running at version .125 which is what I expected based on the DISM commands.  I created a restore point (I know, probably useless).

I plugged in the USB Win 10 media from the Media Creation Tool.  I made this USB drive YESTERDAY  so I was confident that the next step (in-place upgrade) would result in a current version of Win 10.  I ran setup (note: network still disconnected).  I chose to NOT get updates and to retain files and apps.

The in-place upgrade took 1hour, 20 minutes and the system booted successfully.  I set advanced update options to PAUSE for 35 days.  I connected the LAN, turned on System Protection (it was off after the in-place upgrade), and created a restore point.

HERE'S THE SURPRISE:  WINVER SHOWED 16299.125, same as before the in-place upgrade.  I then manually downloaded and ran KB4058258 1/31/18 for version 16299.214 which we all seem to believe is a "GOOD" level.  

Because of today's reports about KB4074588 2/14/18 version 16299.248 saying that systems are again failing to boot with this update, I chose the 16299.214 level.  Updates are paused.  I created a couple more restore points.  The machine seems to run fine and is restartable/rebootable.  It is at ver .214.

Can anyone explain why runnig the latest media creation USB left the system at version .125 after the in-place upgrade?  Is it possibly because the option to "get updates" was not enabled when running the in-place upgrade?  This is why I asked in an earlier post if there is a way to tell what version is being created when making a new USB bootable device.  I know the in-place upgrade does a lot of cleanup of pending or faulty packages and it produces a system that can be rebooted.  Just wondering if there is a way to know in advance what version an in-place upgrade will produce on the machine it is being executed on.

Hello,

   Has anyone seen threads comparable to this one that deal with users that only

developed this problem within the last week (since Tuesday). My machine handled the January

updates without any problem. I blue screened the first time Tuesday. My get-packages look like

(from the bottom):

Installed       Version                Type                       State

  2/14     16299.248.1.17        RollupFix               Pending

  2/2       16299.214.1.17        RollupFix               Pending

  2/1       16299.192.1.9          RollupFix              Superseeded

  12/14   16299.125.1.6          RollupFix              Superseeded

  2/14     16299.245.1.0          KB4087256            Installed

  2/1       16299.212.1.0          KB4074608            Installed

  2/9       10.0.1.0                    KB4074595            Installed

  2/1       16299.188.1.0          KB4058702            Installed

  1/13     10.0.1.0                    KB4058043            Installed

  plus several others on 1/13, all installed.

I've tried using remove-package(c:), but it fails with 800f082f, but I was not in RE(e:)

While trying to recover from the BSOD I remember last weekend just prior the error I had problems trying to back up my files using Seagate.  I would start the Seagate Dashboard and start the backup and within a minute or so, it would halt with a "unable to connect to the drive".  I updated the Dashboard, but still the same problem.  I could run Chkdsk with no problems and access the files on the USB backup drive. There was also plenty of space available on it to do backups.  

I was able to recover the system by using a system restore 2/2/2018 (another Critical update).  I checked everything out and everything appeared to work fine.  I had the wireless connect off, so I went in and paused updating for a month.

Before rebooting, I ran the Seagate Dashboard again using the same USB drive, and it worked as expected backing up all of my files.  I rebooted, plugged in the USB wireless connection and everything worked fine. I did not apply any updates, so hopefully it will continue to run for awhile.