Microsoft has quietly released an out-of-band emergency update for Windows 10 — KB5074976 — to repair a Message Queuing (MSMQ) regression introduced by the December 9, 2025 cumulative update, but the fix is
not being pushed via Windows Update and must be downloaded manually from the Microsoft Update Catalog.
Background / Overview
In early December Microsoft shipped the monthly security rollup for Windows 10 ESU (Extended Security Updates) subscribers. Shortly after deployment, some enterprise and managed environments began reporting failures in applications that rely on
Message Queuing (MSMQ). Symptoms included inactive queues, "insufficient resources" errors from IIS and other services, failures to create MSMQ message files under C:\Windows\System32\msmq\storage, and misleading disk-space or memory error messages despite adequate resources.
Microsoft investigated and traced the root cause to recent changes to the
MSMQ security model and NTFS permissions on the MSMQ storage folder that effectively made write access a requirement for MSMQ users — permissions that historically were reserved for administrators. To address the regression, Microsoft issued an out-of-band cumulative update (KB5074976) on December 18, 2025, which explicitly lists an MSMQ fix and returns MSMQ to expected behavior under typical enterprise loads.
This release is notable for two reasons: it targets systems still under the Windows 10 Extended Security Updates (ESU) umbrella, and it is available only from the Microsoft Update Catalog — meaning administrators must retrieve and deploy the package themselves rather than waiting for an automatic push.
What went wrong: the MSMQ regression explained
The technical root cause in plain terms
MSMQ is a long-standing Windows feature used by many server applications, integration points, and legacy line-of-business systems to reliably transport messages between processes and machines. The December cumulative update included changes intended to harden MSMQ by tightening the security model and NTFS ACLs for the MSMQ storage location. Those changes inadvertently required non-administrative MSMQ users to possess write access to the storage folder (C:\Windows\System32\MSMQ\storage).
On systems where MSMQ service accounts and application identities did not have that write permission, operations that write messages — typically via MSMQ APIs — failed and surfaced as resource errors. In high-throughput or clustered MSMQ scenarios under load, queues could become inactive or fail categorically, causing cascading failures in dependent services such as IIS-hosted components and m-driven applications.
Symptoms administrators reported
- MSMQ queues silently becoming inactive or failing to process messages.
- IIS or web applications failing with “Insufficient resources to perform operation” when attempting queue-related work.
- Errors indicating message files (for example, storage*.mq) could not be created under the MSMQ storage folder.
- Event logs reporting “insufficient disk space or memory” when disk and memory availability were normal.
- Clustered MSMQ nodes under load showing instability or message loss.
These symptoms align with a permissions regression rather than an outright corruption or hardware fault — the system could be fine, but the service lacked an expected access pathway.
The fix: KB5074976 (out-of-band)
What KB5074976 does
KB5074976 is an out-of-band cumulative update for Windows 10 versions 21H2 and 22H2 specifically designed to remediate the MSMQ permissions regression introduced by earlier December updates (notably the KB5071546 rollup from December 9, 2025). The update restores expected MSMQ behavior in affected environments and addresses the incompatible permission change that prevented normal queue write operations.
Microsoft’s update metadata lists the OS build revisions fixed by the package (builds in the 19044/19045 series) and explicitly states the MSMQ issue is fixed. The company also notes the problem primarily affects enterprise and managed IT environments; consumer-grade Home and Pro installs are
very unlikely to be impacted.
How Microsoft is distributing the update
Unlike standard monthly cumulative updates that flow through Windows Update or update management systems automatically,
KB5074976 is being distributed exclusively via the Microsoft Update Catalog. That means:
- Windows Update will not automatically download or install this package for most machines.
- Administrators and individual users who believe they are affected must manually download the appropriate CAB/MSU package from the Update Catalog and deploy it.
- Managed-update systems (WSUS, Microsoft Endpoint Configuration Manager, Intune) can ingest the package from the Update Catalog and distribute it internally once imported.
Microsoft’s support article and update notes make clear the package is available only from the Update Catalog and also call out the need for the latest Servicing Stack Update (SSU) in some installation scenarios.
Why this distribution approach matters
Pros of the manual/catalog-only approach
- Precision: Microsoft can target a fix to those who need it without risking a broad push to millions of unaffected consumer devices.
- Reduced collateral risk: The company avoids a mass deployment that could inadvertently cause regressions on Home/Pro PCs where the issue is unlikely.
- Faster delivery for administrators: Admins who discover the problem can quickly fetch a definitive fix rather than waiting for the next scheduled push.
Cons and operational friction
- Added workload for administrators: Manual download and testing introduce friction at a time when many organizations are already stretched.
- Risk of missed deployments: Teams that rely on automated patching may not notice there’s a catalog-only package and can leave vulnerable or broken systems unremediated.
- Transparency and communication: Microsoft did not issue a broad automatic deployment or an immediate advisory email to affected customers explaining the catalog-only choice, leaving some organizations with uncertain incident response workflows.
- Potential for inconsistent patch states: Environments that pull patches differently (some via Windows Update, some via manual import) can end up in mixed states — complicating troubleshooting.
What IT admins should do now — step-by-step
- Confirm whether your environment is impacted
- Look for MSMQ-related errors in Event Viewer, especially messages about storage*.mq creation failures or “insufficient resources to perform operation.”
- Check whether message queues are inactive or applications using MSMQ are failing.
- Focus on servers and clustered nodes that handle queued workload or high throughput.
- Review the Windows build and update levels
- Verify device build numbers (for the KB5074976 target builds: 19044.6693 / 19045.6693).
- Confirm you installed the December 9 ESU rollup (the change that triggered the regression).
- Prepare prerequisites
- Ensure the latest Servicing Stack Update (SSU) appropriate to your OS image is installed; missing SSUs can prevent LCU/combined packages from installing correctly.
- Take snapshots/backups of critical VMs and backup MSMQ configuration where possible.
- Download KB5074976 from the Microsoft Update Catalog
- Use the Microsoft Update Catalog to locate the correct package for your system architecture and OS version.
- For managed environments, import the package into WSUS or your patch-management tool so you can distribute it centrally and test before broad rollout.
- Test in a lab or staging environment
- Validate that the update resolves the MSMQ issues and does not introduce new behavior for your specific MSMQ configurations, clustering setups, or third-party MSMQ consumers.
- Deploy with rollout controls
- Roll out to a pilot group first, then broaden if results are positive.
- Monitor Event Viewer and application telemetry for residual errors.
- If you cannot install immediately
- As a temporary mitigation, validate and adjust NTFS permissions carefully on C:\Windows\System32\MSMQ\storage to ensure MSMQ service accounts and application identities have the proper write access — but tread carefully: this can weaken security if done improperly.
- Engage Microsoft support if you have ESU coverage and the environment is critical.
- Post-install validation and cleanup
- Confirm queues resume processing and that queued messages are not lost.
- Use DISM or package inventory commands to verify package installation and, if necessary, prepare an uninstall plan (be aware that combined SSU/LCU packages may not be removable by standard wusa.exe uninstall switches).
Practical guidance for different audience types
Enterprise IT (Domain-joined servers, clustered MSMQ)
- Treat KB5074976 as a high-priority remediation. Test in lab, import into WSUS or ConfigMgr, and schedule a controlled rollout.
- Validate cluster behavior under simulated load to ensure the fix holds under production conditions.
- Avoid ad-hoc permissions changes to MSMQ storage in production unless thoroughly validated.
Managed service providers (MSPs)
- Communicate proactively with customers: outline the issue, confirm which customers are likely affected, and describe your plan to deploy KB5074976.
- Use automation where possible to import the MSU/CAB into centralized patch tooling and create remediation playbooks.
Small business and individual users
- Most consumer Home/Pro machines are unlikely to be affected. If you don’t run server workloads or m-queuing apps, you probably can wait for guidance.
- If you run a small server or self-host services that rely on MSMQ, follow the admin steps above and download the appropriate package from the Update Catalog.
Why Microsoft might have chosen a catalog-only release (analysis)
Several plausible operational and policy motives explain the catalog-only distribution:
- Targeting precision: Microsoft can limit deployment to administrators who know MSMQ is used and are prepared to test a fix. Broad automatic rollout could affect devices unnecessarily.
- Post-EOL caution: Windows 10 reached end of support on October 14, 2025; many remaining updates are being distributed under the Extended Security Updates (ESU) program. Microsoft is balancing the need to provide fixes for ESU customers against the risks of mass updates for consumer devices no longer in mainstream support.
- Complexity of environment: MSMQ is largely an enterprise integration feature. The company likely judged home and personal devices as low risk and did not want to risk destabilizing non-server endpoints.
- Speed and control: A catalog release allows Microsoft to get a fix out fast without the full telemetry and compatibility gating that accompanies a Windows Update push.
None of these justifications are wrong, but the decision shifts the burden of discovery and deployment onto IT professionals and may conflict with the expectations of organizations that rely on automated patch pipelines.
Risks, edge cases, and residual concerns
- Manual distribution increases the chance of patch drift and inconsistent patch levels across a fleet, complicating compliance reporting.
- Teams that do not monitor update history or Microsoft support posts may miss the catalog-only release entirely.
- Some environments may have custom MSMQ ACLs or third-party integrations that react differently to the fix; thorough testing is essential.
- The presence of a permissions-related regression raises concern about future hardening updates that change ACLs or security models — administrators should beef up their pre-deployment testing around permission changes.
- If administrators attempt a quick permissions-based mitigation (granting broad write rights to the storage folder), they may unwittingly expose the system to privilege escalation or unauthorized access. Any permission adjustments should be as narrow and audited as possible.
Recommended policy changes for organizations going forward
- Expand update monitoring: Add Microsoft Support release-notes feeds and the Update Catalog to routine patch-monitoring dashboards.
- Harden test automation: Build lightweight pre-release smoke tests for critical subsystems (including MSMQ where used) so that a single cumulative update doesn’t require lengthy manual QA.
- Enforce controlled pilot rings: Maintain a pilot ring for updates even after product EOL to catch regressions quickly.
- Maintain a rapid catalog import workflow: Ensure WSUS/ConfigMgr/Intune operators know how to ingest and approve Update Catalog packages so catalog-only releases can be deployed centrally.
- Review permissions baselines: Establish an audited baseline for critical service folders like MSMQ storage so any unexpected ACL changes are detected immediately.
What this episode means for Windows 10 post-EOL and the ESU program
The KB5074976 release illustrates the operational reality of maintaining an OS beyond mainstream support. Microsoft continues to produce critical updates under ESU, but the distribution model and controls are more selective. Organizations that chose to stay on Windows 10 with ESU must therefore accept a greater role in patch discovery and deployment.
This incident also underscores that hardening and security changes — even when well-intentioned — can create unexpected breakage in legacy-dependent enterprise stacks. The interplay between tighter security postures and backward compatibility will remain a management challenge for teams that have not yet migrated to newer platforms.
Final verdict: measured praise with caveats
Microsoft shipped a necessary, targeted fix quickly after the MSMQ regression surfaced. The out-of-band KB5074976 release resolved a real enterprise-impacting problem without a broad, potentially disruptive rollback. That is a pragmatic and arguably responsible approach.
However, placing the onus on administrators to discover and manually install the patch — especially for systems that depend on automated update channels — introduces operational risk and friction. The catalog-only distribution and lack of a broad, proactive communications push to impacted customers is a shortfall in incident communications for enterprise users relying on Microsoft for guidance.
For IT teams, the practical takeaway is straightforward: treat KB5074976 as a high-priority patch if you run MSMQ-dependent workloads, import the package into your management tooling, test carefully, and deploy promptly. For organizations still operating Windows 10 under ESU, the episode is a reminder that staying on a legacy OS increases operational responsibilities — and that robust update monitoring and staged deployment policies have never been more important.
This fix is available now from the Microsoft Update Catalog; administrators should verify prerequisites (SSU), test in staging, and deploy in controlled rings to restore MSMQ functionality and protect m-driven applications.
Source: BetaNews
Microsoft releases emergency patch for Windows 10 to fix Message Queuing problems