[SOLVED] Windows Server 2022 Won't Update - Error 0x800f0922

TechFA

Member
Joined
Feb 28, 2022
Posts
9
Hello Sysnative Community,

I am seeking assistance with a Windows Server 2022 that has not successfully installed updates since July 2024, and is consistently failing with error code 0x800f0922. This is a critical production server running System Center DPM 2022 and Hyper-V (as a DPM prerequisite for VHDX handling). To ensure system stability, I am exploring all troubleshooting options before considering more drastic measures like an in-place upgrade.

I have already performed a range of standard troubleshooting steps, all of which have returned no errors or issues (unless specifically noted below):
  • SFC /scannow: Completed successfully with no integrity violations reported.
  • DISM /Online /Cleanup-Image /CheckHealth: Reported "No component store corruption detected."
  • DISM /Online /Cleanup-Image /ScanHealth: Reported "No component store corruption detected."
  • DISM /Online /Cleanup-Image /RestoreHealth: Completed successfully, stating it repaired the component store (even though previous checks showed no corruption).
  • DISM /Online /Cleanup-Image /AnalyzeComponentStore: Completed, outputting component store analysis (available in logs if relevant).
  • DISM /Online /Cleanup-Image /StartComponentCleanup: Completed successfully.
  • CHKDSK C: /F: Completed successfully with no errors found on the file system.
The server is currently reporting Microsoft Windows [Version 10.0.20348.2527]. While it appears to download and attempt to install monthly updates (specifically Cumulative and Security Updates released since July 2024), they consistently fail with error code 0x800f0922. This error is displayed during the update installation process and never reach an "Installed" state, even though event viewer logs show successful installation.

I have attempted updates through both:
  • WSUS: Approved updates are downloaded, but installation fails with error 0x800f0922.
  • Manual Installation from Windows Update Catalog: Downloading and running the .msu packages also results in failed installation, again with error 0x800f0922.
I also previously attempted to reset the Windows Update component store using the script from Microsoft. This did not resolve the 0x800f0922 error.

I have attached the latest CBS and DISM logs for your review. I am hoping you can provide targeted guidance to diagnose and resolve this update failure. I have done some preliminary searches online for this error, but haven't found solutions that apply to my specific situation.

Thank you in advance for your time and assistance.

Sincerely,

TechFA

P.S. What is the recommended upload service to share files? The logs are too large to attach here.
 
Hi @TechFA,

Welcome to Sysnative Forums!

If you haven't already, please review the posting instructions here, and attach the requested log files. Without log files, our helpers will not be able to assist, and this will slow down fixing your machine.

If logs have been already been provided, our team of volunteers will analyse the provided log files to build a fix for your system. Please be aware that this may take several days from your initial post, due to the high volume of threads that we receive.


- Sysnative Windows Update Team
 
Hi,

Please run the following command in an elevated prompt and attach services.txt to your next post.
Code:
WMIC SERVICE GET caption, name, startmode, state > "%userprofile%\desktop\services.txt"
 
Hi,

Download the
577bf0efb8088-FRST.png
Farbar Recovery Scan Tool and save it to your Desktop:

Download the 64 bit version: - Farbar Recovery Scan Tool Link

Warning: This script was written specifically for this system. Do not run this script on another system.

  • Download the attachment fixlist.txt and save it to your desktop.
  • Right-click on FRST.exe and select "Run as administrator".
  • Press the Fix button.
  • If for some reason the tool needs a restart, please make sure you let the system restart normally.
  • When finished, a log called Fixlog.txt will appear in the same directory the tool is run from.
  • Post the logfile Fixlog.txt as attachment in your next reply.
 

Attachments

Great, please attempt to update again an post the reslult. If it fails attach a new copy of the CBS logs.
 
Wow, I'm absolutely amazed - that actually worked! Checking the "App Readiness" service and setting it to "Manual" fixed the update problem immediately. I'm still trying to wrap my head around it, but updates are now installing.

I'm very curious if you have any insight into why the "App Readiness" service would have been set to Disabled. I am confident that I did not disable it intentionally. Is it possible that a previous update or perhaps my component store reset could have inadvertently changed the service state? Understanding the potential cause would be helpful for future prevention.

Regardless, the problem is solved, and I am extremely grateful for your expert assistance. Thank you so much for your time and guidance. I will mark this thread as resolved.
 
Following up on our successful resolution, and to provide a more accurate historical context, I wanted to clarify the details regarding the "App Readiness" service. Upon further investigation, reviewing my Teams chat history revealed a conversation with an associate from approximately 2.5 years ago concerning this server.

At that time, we were troubleshooting intermittent black screen issues with RDP. During that process, the "App Readiness" service was identified as potentially relevant. In an attempt to resolve the black screen problem, we initially disabled the "App Readiness" service as a troubleshooting step. According to the conversation, we then explicitly set the service back to "Manual." However, and this is the key point, between then and now, the service inexplicably reverted back to the "Disabled" state. This undocumented reversion is the most critical piece of the puzzle.

This historical context clarifies the service's journey: Manual -> Disabled -> Manual -> Back to Disabled. While disabling it initially was a deliberate troubleshooting step for the RDP issue, the unexplained return to "Disabled" is the most significant finding and likely the root cause of the recent Windows Update failures.

Thank you again for identifying the importance of the "App Readiness" service and guiding me to this resolution. Understanding this historical configuration helps complete the picture.
 
Hi,

You're welcome. Glad to hear the issue has been resolved and thanks for sharing the troubleshooting history to know why this server was disabled.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top