Error 0x80240069 when using WSUS on Windows 11 24H2: Causes, symptoms, and solution

When deploying a new version of Windows 11 in a company, any issues with WSUS can become a major headache. In recent waves, several administrators have seen the Windows 11 24H2 update fail with error code 0x80240069 right from the start, even when launched from the Configuration Manager Software Center.

The same scenario is repeated: the Windows Update service stops unexpectedly, the logs become filled with errors, and despite allowing direct downloads from Microsoft Update, the process continues to fail on computers managed through WSUS . The good news is that Microsoft has already acknowledged the problem, mitigated it with patches, and offers clear ways to resolve it or, at the very least, weather the storm until a permanent fix is ​​released.

What is happening with error 0x80240069 in WSUS environments?

In scenarios using Configuration Manager (for example, ConfigMgr 2409) and clients on Windows 11 23H2 attempting to upgrade to 24H2, immediate failures with error code 0x80240069 (-2145124247) have been observed when initiating the upgrade from the Software Center . The CAS.log entry typically reflects something like "Failed to download content; releasing the request," indicating an interruption during the package retrieval phase.

Coinciding with that moment, the Event Viewer shows several clues: “The Windows Update service terminated unexpectedly ,” traces that fail to start (such as WindowsUpdate_trace_log with 0xC0000035), and references to svchost.exe_wuauserv . Interestingly, if the same computer is scanned and patches are installed directly through Microsoft Update, the operation works, suggesting that the Windows Update agent is not broken and the problem arises when going through WSUS.

In another real-world case with Windows 11 24H2 during the August updates, the Software Center flagged both KB5063878 and KB890830 as failed. The WUServiceWatcher log reported that wuauserv was closing with error code 1067 , and Application Events showed a 0xc0000005 exception in ntdll.dll for the svchost.exe_wuauserv process. On Windows 10 or Windows Server 2022 machines in the same environment, however, everything worked perfectly.

Official Microsoft acknowledgement and fix status

Microsoft has confirmed an issue affecting the delivery of the Windows 11 24H2 feature update via WSUS , particularly after installing the April 2025 security patches (e.g., KB5055528 and later). In many cases, the download either failed to start or was interrupted, and the Windows Update log displayed error code 0x80240069 along with a message stating that the wuauserv service had stopped unexpectedly.

To resolve the issue, Microsoft has released a series of fixes covering several layers: a specific package for WSUS servers , client-side changes, and revisions to update metadata. In some deployments, the vendor even performed a Known Issue Rollback (KIR) and subsequently reviewed the problematic package. After resynchronizing WSUS and approving the fix , customers were able to update again without incident.

The practical recommendation is clear: ensure that both WSUS servers and clients have the latest cumulative updates installed , check the synchronization status, and force a new synchronization if necessary to download the corrected metadata. In numerous reported cases, the deployment progressed normally the day after the review, following the resync and subsequent approval.

KB5063878 and other specific symptoms that have been seen

The Windows 11 24H2 security update KB5063878 has been one of the most frequently mentioned in these incidents, with users encountering error code 0x80240069 when attempting to install it . In addition, system logs revealed repeated unexpected shutdowns of the Windows Update service, effectively trapping the update process in an error loop.

It's worth remembering that KB5063878 is important: it provides over a hundred security fixes (107 vulnerabilities) , so leaving it undeployed is not an option in corporate environments. Regarding WSUS, some administrators found a workaround to circumvent the block: manually importing the packages into WSUS using their identifiers.

Specifically, these GUIDs have been shared for manual import: Windows 11 24H2 (x64): 8018eab0-7242-4932-adf2-afda36f6b3f6 and Windows Server 2025 (x64): 92061378-be93-4659-a72a-037225e6bb0f . While not ideal, this approach has allowed some teams to unlock deployment while awaiting the official metadata revision or WSUS patch.

Meanwhile, some administrators suspected Delivery Optimization (DO) due to the error pattern, but enabling direct downloads from Microsoft Update in the ConfigMgr client did not resolve the issue, reinforcing the idea that the real source was in WSUS or the combination of metadata and monthly patches.

How the crash manifested after the April 2025 patches

Following the April 2025 Patch Tuesday, Microsoft warned that devices with the April monthly security update (starting with KB5055528) might be unable to update to Windows 11 24H2 via WSUS. The typical scenario involved the download failing to start or complete, resulting in error code 0x80240069 in WindowsUpdate.log and the Windows Update service abruptly stopping.

Initially, there was no immediate public solution; the vendor requested time while working on a fix. Subsequently, between KIRs, package revisions, and specific updates for WSUS , the process has resumed, but it is crucial that each organization validates its own system: WSUS version, correct synchronization, current approvals, and up-to-date clients.

This is not the first episode of this kind: in previous months, enterprise customers with Windows 11 22H2 and 23H2 also encountered the same code 0x80240069 when trying to move to 24H2 via WSUS, and it was resolved with similar actions by Microsoft in metadata and server.

Recommended interim measures if you are still stuck

Beyond waiting for an official fix, there are other options. One is to temporarily postpone installing the April 2025 patches if your immediate plan is to upgrade to 24H2 via WSUS and you still have time to adjust maintenance windows.

Another option is to use alternative methods for feature updates: the Media Creation Tool , Windows Update Assistant , or an official ISO in controlled deployments. These methods bypass WSUS for the feature update package, allowing you to complete the jump to 24H2 and then return to the usual WSUS path for cumulative and quality updates.

If you absolutely need it to go through WSUS, you can try the manual GUID import mentioned earlier. And, in parallel, make sure the WSUS server has received and applied any hotfixes released by Microsoft for this specific issue, followed by a resynchronization and thorough metadata verification in the console.

Quick Diagnostics: What to Check on Clients and in WSUS/ConfigMgr

As a general rule, it's best to start with the key logs . On clients managed by Configuration Manager, WUAHandler.log and WindowsUpdate.log are your best allies. The former reflects what the Windows Update Agent reports, and the latter contains the details of the cause (including error code 0x80240069 when applicable). If WUAHandler.log isn't even generated after forcing a scan cycle, there's likely a problem with policies, the location of WSUS, or communication with the software update point.

First of all, confirm that the Windows Update Agent is up to date and if you suspect local corruption, resets the SoftwareDistribution store from the client: stop the WU service, rename the folder and start again. Commandos typical: net stop wuauserv, change C:\Windows\SoftwareDistribution a SoftwareDistribution.old, and executes net start wuauserv. After that, launches an update test from the client.

If you see proxy-related errors, check your WinHTTP settings. Check with netsh winhttp show proxy and if you have the correct proxy in Internet Explorer/Windows Settings, import it with netsh winhttp import proxy source=ie. Common codes for misconfigured proxy include 0x80244021 (HTTP 502), 0x8024401B (HTTP 407), 0 x 80240030 o 0x8024402C.

To rule out connectivity issues with WSUS, check the URL from the client. Locate the setting in the registry. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and test access to typical routes: http://SERVIDOR:8530/Selfupdate/wuident.cab, http://SERVIDOR:8530/ClientWebService/wusserverversion.xml y http://SERVIDOR:8530/SimpleAuthWebService/SimpleAuth.asmx. If they fail, a power outage is likely. DNS, firewall, ports or proxy.

Speaking of ports, WSUS can work with 80, 443, or 8530 8531. Make sure they are open end to end. A quick telnet (telnet SERVIDOR 8530) gives you an instant clue. If your IIS is at play, check the WSUS site bindings in IIS Manager to confirm that the port settings are correct. matches the update point role in ConfigMgr.

SSL, certificates, and error 0x80072f0c

If you have WSUS with SSL and see error code 0x80072f0c , check that the WSUS virtual directories are using SSL but with "bypass client certificates" enabled. If " Accept" or "Require client certificates " was mistakenly configured , the scan will fail. In the ConfigMgr software update point, enable "require SSL communication" only if the site is ready, with its server authentication certificate installed and linked to the site in IIS.

In IIS, check the HTTPS bindings for the WSUS site and ensure the correct certificate is selected. If it's missing, assign it in Edit Site Binding , save, and restart as needed. Then, verify that the WSUS console is set to use SSL when synchronizing to avoid configuration discrepancies between the server and the update point.

Group Policies that override WSUS settings

Another classic: the domain GPO overrides the local settings that Configuration Manager applies to point to its update point and port. If the value in the GPO doesn't exactly match what your update point needs (including FQDN and port), the test fails. In WUAHandler.log, you'll see that the domain policies have replaced the local ones, and from then on, the client can't find its server.

Solution: Align GPOs with Configuration Manager. This means that the server name and port match those of the software update point. For example, if the default website is used, the URL should include the Correct FQDN and port (e.g., http://server1.contoso.com:80). When they are aligned, the client no longer becomes disoriented.

More checks to refine the diagnosis

If the management point returns an empty WSUS location to the client, there may be a content version mismatch in WSUS due to a failed synchronization. In the ConfigMgr console, check the synchronization status of the update point. If necessary, examine the CI_UpdateSources , WSUSServerLocations, and Update_SyncStatus tables , verifying that the source ID and content version match.

Enable detailed and debug logging on both the client and the management point. Ensure that CcmMessaging.log is free of communication errors. If the scan runs and completes, status messages should be sent to the management point; if they are not, review the message processing flow and any intermediate blocking.

Other common error codes and their meaning

Within the WSUS/ConfigMgr environment, there's a series of error codes that are worth recognizing to avoid wasting time. 0x80245003, 0x80070514, 0x8DDD0018, 0x80246008, 0x80200013, 0x80004015, 0x800A0046, 0x800A01AD, 0x80070424, 0x800B0100, and 0x80248011 typically indicate missing or corrupted components. These can often be resolved using the Windows Update troubleshooter or by resetting the SoftwareDistribution agent repository.

For connectivity issues, you'll see errors like 0x80072ee2, 0x8024401C, 0x80244023, 0x80244017 (HTTP 401), and 0x80244018 (HTTP 403) . In these cases, check the ports, proxy settings, firewall, and ensure the client can reach the ClientWebService and SimpleAuthWebService virtual directories of your WSUS server. If IIS doesn't log the error, there's usually a firewall/proxy blocking the connection.

With 0x80240069, the pattern observed in this incident is different: it is not that the client cannot reach WSUS, but that the download/installation of the 24H2 feature update fails due to transient incompatibilities (metadata, package revision or interaction with monthly patches), resolved by Microsoft with revisions and updates.