Windows 11 Check for updates -> 0x80240439; Check online for updates from Microsoft Update -> works

Question

Windows 11 Check for updates -> 0x80240439; Check online for updates from Microsoft Update -> works

Andrey Yankin 0

Enerprise PC is configured to use an internal WSUS server named http://wsus for managed Windows Update behavior. Check for updates

-> fails with 0x80240439

Check online for updates from Microsoft Update

-> succeeds

The Windows Update datastore initializes successfully:
- JetEnableMultiInstance succeeded
- CreateStore cleanup, dsStatus: 0 This makes obvious DataStore.edb corruption less likely.
The client is definitely initializing with your WSUS configuration:
- WSUS server: http://wsus
- WSUS status server: http://wsus
- Alternate Download Server: http://wsus
- Target group: Workstations
The WSUS protocol exchange appears to complete successfully:
- Existing cookie is valid
- SyncUpdates round trips: 2
- Cached CWSCookie
- TMI 0/0 bad core; 0/0 bad behavior

0 comments

3 answers

Your answer

Answer 1

Adam J. Marshall 11,031 MVP

Run through my troubleshooting guide here:

https://www.ajtek.ca/wsus/client-machines-not-reporting-to-wsus-properly/

Work from top to bottom. It should help you identify and fix the problem.

Also, I'd recommend using FQDN and not 'hostname' because an FQDN will always resolve via DNS, and 'hostname' can fail in many scenarios.

0 comments

Answer 2

Hello,

The error 0x80240439 when checking against WSUS but succeeding against Microsoft Update indicates that the client can reach WSUS but fails during the content retrieval phase. Since the datastore initializes cleanly and the protocol handshake completes, corruption of DataStore.edb is unlikely. The failure is typically tied to either misconfigured WSUS content directories, SSL/HTTP mismatches, or incorrect MIME types on the WSUS IIS configuration.

First, confirm that the WSUS server is serving update content correctly. On the WSUS server, open IIS Manager and check the Content virtual directory under WSUS Administration. Ensure that it points to the correct path, usually C:\WSUS\WsusContent, and that permissions allow NETWORK SERVICE read access. Also verify that MIME types for .cab, .xml, and .bin files are present; missing MIME type entries will cause 0x80240439 errors.

Next, check whether the client is configured for SSL while the WSUS server is only serving plain HTTP. If the client registry keys under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate point to http://wsus, then the server must be accessible over HTTP. If SSL is required, update both the server bindings and the client policy to https://wsus.

Finally, review the WSUS IIS logs (%SystemDrive%\inetpub\logs\LogFiles\W3SVC1) for the client’s request at the time of failure. If you see 404 or 500 errors, that confirms a content serving issue. A common fix is to run wsusutil reset on the WSUS server, which forces WSUS to verify and re-download missing update files.

If all of the above checks out and the error persists, the issue may be tied to a known WSUS bug in certain cumulative updates where the client fails with 0x80240439 despite proper configuration. In that case, applying the latest servicing stack update and cumulative update on both WSUS and the client is required, as Microsoft has patched WSUS synchronization and content handling issues in recent builds.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HP.

Answer 3

The behavior points to the managed WSUS path, not the general Windows Update engine.

0x80240439 means the Windows Update agent starts but cannot complete its startup sequence. Documented causes include:

corrupted Windows Update agent data store
damaged or incomplete Windows Update registry configuration
corrupted state files in %windir%\SoftwareDistribution
a system policy or Group Policy setting that blocks agent startup
an incomplete previous Windows Update reset

Since Check online for updates from Microsoft Update works, focus on the WSUS-managed configuration and policy path.

Recommended troubleshooting path:

Generate and review effective Windows Update policy Run:
```
   gpresult /h gpresult.html
```
In the report, review: Computer Configuration > Administrative Templates > Windows Components > Windows Update Look for policies that could block initialization or force an invalid managed-update state.
Refresh Group Policy after any correction Run:
```
   gpupdate /force
```
Then restart the PC and test Check for updates again.
Verify the WSUS configuration is valid and reachable For WSUS-managed devices, verify:
- the client can connect to the WSUS server URL
- firewalls allow outbound access to the WSUS server
Check whether the environment is configured to use WSUS without approved updates A documented bad configuration is when UseWUServer=1 is set and the client scans WSUS, but WSUS has not approved updates for that client. In that case, scans can complete but the client has no install/download direction from the server.
Reset the Windows Update agent Risk: this clears the local Windows Update data store and state cache. Back up the OS disk first if this is a VM. Run from an elevated Command Prompt:
```
   net stop wuauserv
   net stop bits
   net stop cryptSvc
   
   ren %windir%\SoftwareDistribution SoftwareDistribution.old
   ren %windir%\System32\catroot2 catroot2.old
   
   net start cryptSvc
   net start bits
   net start wuauserv
```
If repeating this procedure, delete existing SoftwareDistribution.old and catroot2.old before rerunning.
Check BITS health on the client WSUS uses BITS for update downloads. Verify BITS is running under LocalSystem and is started:
```
   sc config bits obj= LocalSystem
   sc query bits
   sc stop bits
   sc start bits
```
Stopping and restarting BITS requires local administrator rights.
If the device is an Azure VM Use the Azure VM Windows Update Reset Tool from the VM’s Azure portal page under Operations > Run command.

If the issue persists after policy review, WSUS connectivity validation, and Windows Update agent reset, the remaining supported next step is to contact Microsoft Support.

References: