Do Son 
Enterprise WSUS update servers began faltering around 13 July 2026. The disruption spread widely across corporate networks. Windows 10, Windows 11, and Windows Server systems all struggled to update normally. Specifically, devices attempting to check for updates met scan failures or scan timeouts. Consequently, IT administrators could not deploy essential security patches.
Microsoft Traces the Fault to Stray Test Detectoids
Microsoft has published its findings in support document KB5121986. The culprit proved oddly mundane. A buildup of mis-published test detectoids had accumulated in the WSUS channel. Their titles follow a telltale pattern beginning with “Product Detectoid for ProductName TestProduct”.
That accumulation lengthened synchronisation times considerably. In worse cases, sync operations simply timed out. Administrators consequently lost the ability to push the latest updates through WSUS and similar management tools. The trouble started shortly before 13 July, when many administrators first noticed deployments stalling.
What Clients Report
The pileup also breaks Windows Update scans on client machines. The signature error is 0x80244010, meaning the scan exhausted its maximum round trips to WSUS. Other symptoms include SOAP faults, HTTP 503 responses from an overloaded WsusPool, and plain WININET timeouts.
Microsoft’s Server-Side Mitigation
Conditions worsened noticeably heading into the weekend. Microsoft therefore deployed a service-side mitigation on 18 July 2026. Synchronisation times and sync operations have since returned to normal. In principle, new WSUS installations and rebuilds should now proceed without incident. The mitigation shields freshly built servers, though it does not clean existing ones.
The Manual Cleanup for Servers Still Affected
Administrators still seeing scan failures or timeouts must intervene by hand. Microsoft has outlined a cleanup that removes the offending detectoids and restores healthy synchronisation.
Back Up First
Back up every SUSDB database before touching anything. The cleanup permanently deletes update metadata. Without a backup, you cannot reverse it.
Run the Cleanup Query
Next, run Microsoft’s cleanup query from SQL Management Studio. Point it at every SUSDB database, replicas included. Deletions do not propagate between WSUS servers, so each catalogue needs cleaning directly. Otherwise, clients reporting to an uncleaned downstream server will keep seeing the stray detectoids.
The query also sets MaxXMLPerRequest to 0. That step lifts the 5MB ceiling temporarily and helps clients finish scanning. Microsoft additionally suggests throttling maximum concurrent connections on the WSUS Administration site in IIS, then raising them gradually while keeping CPU usage near 80 percent.
Restore MaxXMLPerRequest Afterwards
Do not leave that value at zero. Once WSUS stabilises and clients scan successfully, return MaxXMLPerRequest to its default of 5242880. Many readers conflate this with the cleanup query itself, yet it is a distinct later step.
After the Cleanup
Client recovery happens automatically. The first Windows Update scan on each machine performs a one-time catch-up and runs longer than usual. Subsequent scans return to normal timing, and individual clients need no attention.
Server maintenance still matters, however. A deletion of that size fragments the SUSDB indexes. Administrators should therefore reindex SUSDB, run the WSUS Server Cleanup Wizard, and then perform an IISReset or recycle the WsusPool application pool to clear cached catalogue state.
One final note on disk space. The client-side DataStore.edb will not shrink once the detectoids disappear. That behaviour is expected and does not degrade scan performance.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
