Microsoft explains WSUS error 0x8024401c in Windows 10 V1607

[German]Cumulative Updates for Windows 10 Anniversary Update (V1607) and Windows Server 2016 are causing a connection error 0x8024401c in WSUS environments after install. Microsoft has now published an explanation, why this occurs and how to workaround.


Update error 0x8024401c in Windows 10 V1607

In August 2017 Microsoft released two cumulative Updates KB4034658 (August 8, 2017) and KB4034661 (August am 16, 2017) for Windows 10 Anniversary Update (Version 1607). Both updates are causing WSUS issues, the clients are reporting error 0x8024401c during update search. Error code 0x8024401c stands for


Same as HTTP status 408 – the server timed out waiting for the request.

I’ve discussed this issue within my blog post Windows 10 (V1607): KB4034658/KB4034661 causes WSUS error 0x8024401c. Microsoft finally has confirmed this issue, and I found on August 13, 2017 a blog post WSUS SUP causes high CPU and clients fail updates scan  mentions a high CPU and RAM load and posts some hint to fix this issue.

Microsoft explains the background for this error

Microsoft has posted an article High CPU/High Memory in WSUS following Update Tuesdays, explaining, what’s going on under the hood. The symptoms of this issue are:

  • High CPU on your WSUS server – 70-100% CPU in w3wp.exe hosting WsusPool
  • High memory in the w3wp.exe process hosting the WsusPool – customers have reported memory usage approach 24GB
  • Constant recycling of the W3wp.exe hosting the WsusPool (identifiable by the PID changing)
  • Clients failing to scan with 8024401c (timeout) errors in the WindowsUpdate.log
  • Mostly 500 errors for the /ClientWebService/Client.asmx requests in the IIS logs

Those symptoms occur after installing an update for Windows 10 Version 1607 clients (Updates KB4022723, KB4022715, KB4025339 etc.). The reason for this behavior is:

WSUS has a caching mechanism whereby the first time update metadata is requested by any client WSUS will store it in memory. Further requests for the same update revision will retrieve the update metadata from memory instead of reading it from the database. Some of the metadata in the database is compressed, so not only must it be retrieved, it must be decompressed into memory, which is an expensive operation.

This results in the following scenario:


For large metadata packages and many simultaneous requests, it can take longer than ASP.NET’s default timeout of 110 seconds to retrieve all of the metadata the client needs. When the timeout is hit, ASP.NET disconnects the client and aborts the thread doing the metadata retrieval.

Then the client reports an update error 0x8024401c and fails with the update. The issue hasn’t been observed for Windows 10 V1703, because there are not enough cumulative updates to trigger the behavior discussed above – but the issue will occur in near future.

Microsoft addresses several workarounds within the Technet article to avoid an overload on WSUS:

  • Configure IIS to stop recycling the App Pool
  • Limit the number of inbound connections to WSUS
  • Increase the ASP.NET timeout

Let’s hope, that this will help to prevent future WSUS issues with Windows 10 updates.

Addendum: Microsoft’s explanation not consistent?

Within my German blog I received a comment from an administrator working with WSUS. He asked, why we haven’t seen this issue for Windows 10 V1507 and V1511? And why we haven’t seen this behavior with WSUS and Windows 7/8.1? I’ve counted the amount of updates for Windows 10 and found:

  • V1703: 10
  • V1607: 29
  • V1511: 22
  • V1507: 21

So in my view it’s clear, why we see this issue with Windows 10 Anniversary Update – it’s the Windows 10 version with the highest number of updates. Not sure, when we will hit the same issue with other Windows 10 versions. Any thoughts?


This entry was posted in issue, Update, Windows and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *