A security update, designed to protect systems, inadvertently becoming the source of a major operational disruption is a scenario that keeps system administrators awake at night, and this is precisely what has occurred following the release of Microsoft’s December 2025 security patches. The update has triggered significant failures within the Windows Message Queuing (MSMQ) service, a crucial component for many enterprise applications. This disruption has had a cascading effect, impacting websites that rely on Internet Information Services (IIS) and other critical business systems that use MSMQ for asynchronous communication. The problem affects a wide array of Windows versions, turning a routine and necessary security procedure into a widespread operational crisis. IT departments are now facing the difficult task of mitigating the fallout and restoring functionality to essential services that were unexpectedly crippled by a patch intended to bolster their security, highlighting the delicate and often unpredictable balance between system protection and stability.
Pinpointing the Widespread Disruption
The source of the instability has been traced to a specific set of cumulative updates: KB5071546 for Windows 10 22##, KB5071544 for Windows Server 2019, and KB5071543 for Windows Server 2016. Following the installation of these patches, administrators began observing a consistent pattern of failures. The most prominent symptoms include MSMQ queues becoming completely inactive, preventing applications from writing new messages and effectively halting communication workflows. Concurrently, IIS-hosted sites that depend on this service have been reported to crash, often displaying a vague “insufficient resources” error. This is compounded by misleading system alerts suggesting a lack of disk space or memory, even on servers with ample resources, sending support teams on a frustrating and fruitless troubleshooting path. The issue is not isolated to standalone machines; it has been observed in both individual systems and complex clustered MSMQ environments, with the failures becoming more pronounced under heavy operational loads, further complicating diagnostics and recovery efforts for large-scale enterprise infrastructures.
The Underlying Cause and the Path Forward
Microsoft’s investigation revealed that the root cause was an intentional, yet problematic, change to the MSMQ security model that altered file system permissions. Specifically, the update modified access rights for the C:\Windows\System32\MSMQ\storage folder, a directory critical to the service’s operation. The new security posture now requires that the account running the MSMQ service must have write access to this folder. This change directly conflicts with common enterprise security practices, where services are intentionally run under non-administrative accounts with limited privileges to minimize the potential attack surface. As a result, any system configured this way immediately experienced service failure post-update, while systems where the service was run with full administrative privileges remained unaffected. The company’s investigation left administrators in a difficult position, forcing a choice between operational stability and system security. The only immediate, though risky, workaround involved reverting the problematic security updates, a decision that carried the significant consequence of re-exposing systems to the very vulnerabilities the patches were designed to mitigate. This incident underscored the complex interdependencies within modern operating systems and served as a critical reminder of the potential for unforeseen conflicts between security enhancements and established application configurations.
