Ah, the dreaded 0x800F0922 error - bane of more than a few Windows 8.1 users trying to install Update 1 so they can get security patches in a few months. I ran into this myself, bashing my head against DISM and SFC more than a few times, until I finally decided to sit down and sort out, once and for all, what the primary cause of the error was. To do that, however, I needed an installation log, something that would tell me what was going on and where. Thankfully, Windows leaves those in C:\Windows\Logs\CBS. More specifically, I needed the CbsPersist_YearMonthDayTime.log file that was last updated right after Windows rolled back the Update 1 installation. Once I did so, I performed a quick search for the error in question:
2014-05-28 15:00:38, Error CBS Startup: Failed to process advanced operation queue, startupPhase: 0. A rollback transaction will be created. [HRESULT = 0x800f0922 - CBS_E_INSTALLERS_FAILED]2014-05-28 15:00:38, Info CBS Setting ExecuteState key to: CbsExecuteStateInitiateRollback | CbsExecuteStateFlagAdvancedInstallersFailedOkay, I know I'm in the right file. Question is, what caused the installer to reach that point? To do that, I needed to search for "Error", heading from this point to the beginning of the log. Doing so revealed this:
2014-05-28 15:00:38, Info CBS SetProgressMessage: progressMessageStage: -1, ExecuteState: CbsExecuteStateInitiateRollback | CbsExecuteStateFlagAdvancedInstallersFailed, SubStage: 0
2014-05-28 15:00:38, Info CBS Progress: UI message updated. Operation type: Update. Stage: 1 out of 1. Rollback.
2014-05-28 15:00:38, Info CBS Setting original failure status: 0x800f0922, last forward execute state: CbsExecuteStateResolvePending
2014-05-28 15:00:16, Info CSI 000005e6 Begin executing advanced installer phase 38 (0x00000026) index 1122 (0x0000000000000462) (sequence 1161)At this point, I'll note that my PC had been configured to dual-boot between Windows 8.1 and PC-BSD using GRUB - this is important because the installation process for Update 1 expects to be able to modify key boot loader files. Since it was expecting to find Windows Boot Manager files to update and was unable to find them, the update was erroring out. To test this hypothesis, I restored the Windows Boot Manager by:
Old component: [ml:374{187},l:372{186}]"Microsoft-Windows-BootEnvironment-Core-BootManager-EFI.Resources, Culture=zh-TW, Version=6.3.9600.16384, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64, versionScope=NonSxS"
New component: [ml:374{187},l:372{186}]"Microsoft-Windows-BootEnvironment-Core-BootManager-EFI.Resources, Culture=zh-TW, Version=6.3.9600.17031, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64, versionScope=NonSxS"
Install mode: install
Installer ID: {c5f0e9d7-e844-4507-89e4-701b5a747221}
Installer name: [34]"CSI Boot File Servicing (BFSVC) AI"
2014-05-28 15:00:16, Error CSI 000005e7@2014/5/28:22:00:16.548 (F) base\wcp\plugins\bfsvc\bfsvc.cpp(218): Error HRESULT_FROM_WIN32(123) originated in function Windows::WCP::Bfsvc::BasicInstaller::Install expression: HRESULT_FROM_WIN32(GetLastError())
[gle=0x80004005]
2014-05-28 15:00:16, Info CBS Added C:\Windows\Logs\CBS\CBS.log to WER report.
2014-05-28 15:00:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20140527154510.cab to WER report.
2014-05-28 15:00:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20140527152339.cab to WER report.
2014-05-28 15:00:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20140523232228.cab to WER report.
2014-05-28 15:00:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20140523230555.cab to WER report.
2014-05-28 15:00:16, Info CBS Added C:\Windows\Logs\CBS\CbsPersist_20140523205330.cab to WER report.
2014-05-28 15:00:16, Info CBS Could not get active session for current session file logging [HRESULT = 0x80004003 - E_POINTER]
2014-05-28 15:00:16, Info CBS Not able to add pending.xml.bad to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2014-05-28 15:00:16, Info CBS Not able to add SCM.EVM to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2014-05-28 15:00:16, Error [0x018049] CSI 000005e8 (F) Failed execution of queue item Installer: CSI Boot File Servicing (BFSVC) AI ({c5f0e9d7-e844-4507-89e4-701b5a747221}) with HRESULT HRESULT_FROM_WIN32(123). Failure will not be ignored: A rollback will be initiated after all the operations in the installer queue are completed; installer is reliable (2)[gle=0x80004005]
2014-05-28 15:00:16, Info CSI 000005e9@2014/5/28:22:00:16.579 CSI Advanced installer perf trace:
CSIPERF:AIDONE;{c5f0e9d7-e844-4507-89e4-701b5a747221};Microsoft-Windows-BootEnvironment-Core-BootManager-EFI.Resources, Version = 6.3.9600.17031, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"zh-TW", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral;23421us
2014-05-28 15:00:16, Info CSI 000005ea End executing advanced installer (sequence 1161)
Completion status: HRESULT_FROM_WIN32(ERROR_ADVANCED_INSTALLER_FAILED)
- Downloading the Windows 8.1 Enterprise Evaluation,
- Burning the ISO to a DVD.
- Rebooting the PC and selecting the DVD as the boot device.
- Choosing Repair your computer once the DVD loaded.
- Choosing Troubleshoot.
- Choosing Advanced Options.
- I then tried Startup Repair.
- This failed, however, which meant I had to do it manually. After it failed, I went back to the Troubleshoot menu and chose Command Prompt.
Now it was the time to figure out which partition had my Windows partition on it. To do that, I ran diskpart:
X:\Windows\system32>diskpart
This loaded the DISKPART> prompt:
DISKPART> select disk 0
DISKPART> list partition
Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 1 Primary 350 MB 1024 KB Partition 2 Primary 763 GB 351 MB Partition 3 Primary 1099 GB 763 GB
Most dual boot situations start with a PC that already has a Windows partition, which is then shrunk to make room for a Linux or BSD partition. Consequently, the first partition in such a setup is usually going to be the System Restore partition (Partition 1 in the above example), followed by the actual system partition (Partition 2), followed by the *nix partitions (Partition 3 in this example, though there can be more if you're triple-booting or if you partitioned folders like /home and /var into separate partitions). Consequently, you can usually assume that Partition 2 will be your Windows system partition and work from there. However, if you're feeling uncertain or set up your multi-boot system in some other order, you can actually confirm from here whether you're dealing with your Windows system partition or not:
DISKPART> select partition 2
Partition 2 is now the selected partition
DISKPART> detail partition
Partition 2
Type : 07
Hidden: No
Active: No
Offset in Bytes: 368050176
Volume ### Ltr Label Fs Type
---------- --- ----------- ----- ----------
Volume 2 D NTFS Partition
Note that I left off some of the columns from the above output to keep the formatting straight here - the big one to pay attention to is the Fs column, which gives you the file system of the partition, assuming Windows can recognize it. By contrast, here's what diskpart will output for a UFS file system:
DISKPART> select partition 3
Partition 3 is now the selected partition.
DISKPART> detail partition
Partition 3
Type : A5
Hidden: Yes
Active: No
Offset in Bytes: 819647741952
There is no volume associated with this partition.
Alternatively, here's what diskpart will report for the System Restore partition:
DISKPART> select partition 1
Partition 1 is now the selected partition.
DISKPART> detail partition
Partition 1
Type : 07
Hidden: No
Active: No
Offset in Bytes: 1048576
Volume ### Ltr Label Fs Type
---------- --- ----------- ----- ----------
Volume 1 System Rese NTFS Partition
Having successfully identified which partition contained my Windows system partition (Partition 2 in this case), I was now ready to work against it:
DISKPART> select partition 2
Partition 2 is now the selected partition.
DISKPART> active
DiskPart marked the current partition as active.
DISKPART> exit
Note that, if you don't activate your Windows system partition in diskpart, the next few commands won't do much good.
Now it's time to rebuild the Windows boot manager. To do so, type in these commands:
bootrec /fixboot
bootrec /fixmbr
bootrec /restorebcd
That should do it - your system should now have a stock Windows boot loader once more, which means you should be able to apply Update 1 successfully. Once you've applied Update 1, you can then reinstall GRUB or use EasyBCD to restore your multi-boot configuration at your leisure.
For completeness' sake, I'll point out that I haven't tested whether or not Update 1 will apply successfully with EasyBCD or any other Windows-based boot loader managing the boot process. I'll also note that my particular solution to the dreaded 0x800F0922 error may be unique to my particular workstation, so don't be afraid to do the work, check your logs, and make sure you're experiencing the same issue I am before you dig in too deeply on this one.
Good luck!