MSMQ Breaks After December 2025 Patch — OOB Fix and Mitigation

Microsoft’s December patch cycle produced a compatibility regression that left Message Queuing (MSMQ) queues inactive, IIS sites throwing opaque “insufficient resources” errors, and enterprise message-driven applications unable to write messages — a problem Microsoft has confirmed and patched with an out‑of‑band update available from the Microsoft Update Catalog.

Background​

MSMQ (Microsoft Message Queuing) is an optional Windows component that provides durable, on‑disk, asynchronous messaging for applications and middleware. It persists messages as files under the system folder C:\Windows\System32\MSMQ\storage; because of that on‑disk persistence, MSMQ behavior is tightly coupled to NTFS permissions and the effective rights of the identities (service accounts, IIS app pools, system accounts) that create and write .mq files. Many enterprise line‑of‑business systems, integration layers, and IIS‑hosted components still rely on MSMQ for reliability and decoupling.
On December 9, 2025 Microsoft shipped its monthly security rollups that targeted multiple Windows SKUs. Within days, administrators began reporting consistent failures tied to MSMQ: queues becoming inactive, applications and IIS sites failing to enqueue messages, and confusing diagnostic logs that claimed disk or memory shortages despite plenty of free resources. Microsoft updated the relevant KB articles to list a known issue and later published an out‑of‑band (OOB) cumulative update to remediate the regression.

What happened (short summary)​

• The December 9, 2025 cumulative updates (tracked for affected SKUs as KB5071546, KB5071544, KB5071543 and companion rollups) included changes that tightened MSMQ’s security model.
• Those changes altered NTFS permissions on the folder C:\Windows\System32\MSMQ\storage, effectively requiring non‑administrator MSMQ users to have explicit write access where they historically did not.
• When identities lacking that access attempted to create or append .mq files, MSMQ surface errors were mapped to generic resource errors such as “Insufficient resources to perform operation” or misleading “There is insufficient disk space or memory” messages.
• Microsoft acknowledged the problem in its KB documentation and later released an out‑of‑band fix (for impacted Windows 10 / ESU builds the OOB appears as KB5074976), distributed via the Microsoft Update Catalog.

---

Technical analysis: root cause and why diagnostics were misleading​

The NTFS ACL change and MSMQ semantics​

At the heart of the regression is a change to the MSMQ security model and the NTFS discretionary access control list (DACL) on the MSMQ storage folder. The December updates hardened the storage folder’s security descriptor and altered inheritance semantics; in doing so, they removed or blocked previously effective write privileges for a set of non‑administrator service identities (IIS app pool identities, LocalService, NetworkService, and certain named service accounts). When MSMQ tried to create or grow .mq files and the filesystem denied the operation, the MSMQ stack reported failures as low‑level resource errors rather than clear access‑denied messages. That translation is why many administrators started on a false diagnostic path — checking disk space or memory instead of ACLs.
The practical result: a correctly functioning system from a resource standpoint could nonetheless fail message writes because the process account did not have the requisite write ACL on the storage folder. Clustered MSMQ deployments or high‑throughput scenarios amplified the problem; simultaneous write denials across nodes can make queues appear inactive and cause cascading application failures.

Why the change likely occurred​

The December updates bundled MSRC security fixes intended to harden MSMQ and close privilege escalation or input‑validation vulnerabilities (mapped publicly to fixes in the December LCUs). Tightening the security descriptor and resetting ACL inheritance is a classic hardening action. However, in legacy environments where service identities relied on implicit or inherited write privileges, the change was incompatible. Microsoft’s KB text explicitly links the symptom set to the new MSMQ security model and NTFS permissions on the storage folder.

What made triage slow​

• Error translation: filesystem access denial became logged or returned as resource exhaustion, leading to costly misdirection.
• Silent failure modes: queues often marked as “inactive” with no obvious remediation other than testing writes or inspecting ACLs.
• Mixed environment risk: some systems where users run with administrative privileges were not affected, which complicated pattern detection (admin‑logged systems worked, non‑admin systems failed).

---

Platforms and scope: which systems were affected​

Microsoft’s KB updates and community reporting indicate affected SKUs included a broad set of Windows 10 ESU and older server branches patched during the December 2025 wave:

• Windows 10 (ESU) — tracked as KB5071546 for builds 19045/19044 (22H2/21H2 ESU variants).
• Windows Server 2019 — KB5071544 updated to document the MSMQ known issue.
• Windows Server 2016 — KB5071543 updated to document the MSMQ known issue.
• Some monthly rollups for older server SKUs also listed MSMQ as a known issue and later included the resolution in subsequent OOB packages.

Important operational note: Microsoft stated that consumer devices (Windows Home or standard Pro installs where MSMQ is typically not present) are very unlikely to experience the issue; the regression primarily affected enterprise and managed IT environments where MSMQ is actively used.

---

Impact: real‑world consequences and reported incidents​

The regression produced multiple failure patterns in production environments:

• Persistent queues shown as inactive and refusing messages.
• IIS‑hosted applications and middleware throwing System.Messaging.MessageQueueException with “Insufficient resources to perform operation.”
• Event log entries stating The message file 'C:\Windows\System32\MSMQ\storage*.mq' cannot be created.
• Misleading logs about disk or memory exhaustion, despite ample capacity.
• Clustered MSMQ nodes failing under load, propagating application outages or message loss scenarios.

Organizations in finance, healthcare, logistics, and other sectors that still rely on MSMQ for transactional feed handling and legacy integration reported the fastest, most visible impact — message processing pipelines stalled, queue backlogs formed, and user‑facing application errors appeared where queueing was synchronous with request processing. Some teams mitigated by rolling back the December LCU, while others applied narrowly scoped ACL changes to restore functionality temporarily.

---

Microsoft’s response and the out‑of‑band fix​

Microsoft added a known issue note to the December KB articles and advised affected customers to contact Microsoft Support for Business for validated mitigations. That advisory acknowledged the cause — the change to the MSMQ security model and NTFS permissions — and warned that clustered environments under load were impacted. On December 18, 2025 Microsoft released an out‑of‑band cumulative update that explicitly lists the MSMQ regression as fixed for affected Windows 10 builds; the package for Windows 10 ESU clients is published as KB5074976 and is only available via the Microsoft Update Catalog (not delivered automatically through Windows Update or WSUS in many channels). Administrators must download and deploy the OOB package themselves (or import it into WSUS / Configuration Manager) to remediate affected hosts.

---

Practical mitigation runbook (triage and remediation)​

The incident forced administrators into a short list of pragmatic options. The appropriate choice depends on business risk, regulatory posture, and the feasibility of taking systems offline for rollback or targeted ACL changes.

Immediate triage checklist​

• Identify hosts with MSMQ installed:
• Use Get‑WindowsOptionalFeature -Online -FeatureName MSMQ‑* or DISM to enumerate MSMQ presence.
• Confirm symptoms:
• Check application logs and Event Viewer for MessageQueueException and storage file creation errors.
• Test a simple producer:
• Run a controlled enqueue test as the identity the application uses to confirm a filesystem write failure.
• If the test fails but resources are sufficient, suspect an ACL denial on C:\Windows\System32\MSMQ\storage.

Short‑term remediation options​

• Option A — Apply Microsoft’s out‑of‑band update (recommended if available):
• Download the OOB package (for your SKU and build) from the Microsoft Update Catalog.
• Stage the update in a test ring and validate MSMQ writes under load.
• Deploy broadly once validated.
• Option B — Roll back the December LCU (if immediate OOB deployment is infeasible and rollback is acceptable):
• Follow Microsoft’s KB guidance for LCU removal (use DISM /online /get-packages and DISM /online /remove-package with care).
• Validate the broader effect of rollback — other security fixes included in the LCU will also be removed and must be tracked.
• Option C — Narrowly scoped ACL workaround (highest operational risk):
• Identify the specific service account or app‑pool identity that writes to MSMQ.
• Grant write/modify permissions only to that principal on C:\Windows\System32\MSMQ\storage.
• Log and audit the change, and plan to revert once Microsoft’s official fix is applied.
• Caution: this weakens the hardening intent of the December update and increases the attack surface if an attacker can impersonate that principal. Use this only as a short‑term emergency measure.

Validation and monitoring​

• After remediation, validate by running real application workloads and monitoring queue throughput and error events.
• Monitor Microsoft’s KB pages and the Windows release health dashboard for updated guidance and additional OOB packages for other SKUs.

---

Security trade‑offs and operational risk​

This incident is a textbook tension between security hardening and backward compatibility.

• Strength: The December changes attempted to tighten MSMQ’s security posture and reduce attack surface by making previously implicit write access explicit and auditable. The security intent aligns with responsible operations; Google‑able CVE mappings show that MSMQ fixes were part of the December security wave.
• Risk: Hardening without a compatibility shim or a documented migration path for widely deployed low‑privilege service identities breaks operational expectations for legacy middleware. Granting broad write access to C:\Windows\System32\MSMQ\storage as a quick fix undermines the security control the update sought to enforce. Rolling back security updates preserves availability at the expense of leaving systems exposed to the vulnerabilities those updates addressed.

Enterprises must weigh these trade‑offs based on business impact, threat model, and compliance constraints. The least‑bad path is to deploy Microsoft’s vendor‑sanctioned OOB fix as soon as it can be validated in a staging ring.

---

Why this matters for patch management and change control​

A few broader lessons from the MSMQ regression:

• Test low‑level security changes in production‑like labs that include legacy middleware and non‑standard service identities.
• Maintain a fast‑path rollback and an emergency update channel (staged WSUS / ConfigMgr catalogs or documented manual deployment steps) for situations where security changes break critical flows.
• Prefer explicit, documented mitigations from the vendor rather than community-sourced wide ACL scripts; if a temporary ACL is required, restrict it to the minimum principal and revert once the vendor fix is applied.

---

What administrators should do now (concise checklist)​

• Inventory: Find all systems with MSMQ installed and mark which are patched with the December LCUs.
• Triage: For affected systems, confirm whether the MSMQ writes fail and whether the service account lacks explicit write ACLs on C:\Windows\System32\MSMQ\storage.
• Apply OOB: Prioritize installing the vendor OOB KB5074976 (or the SKU‑appropriate OOB) from the Update Catalog after test validation.
• Contingency: If OOB deployment must wait and availability is critical, either rollback the LCU (under change control) or apply a tightly scoped ACL temporary fix with full auditing and a reversal plan.
• Monitor and report: Watch Microsoft KB updates and contact Microsoft Support for Business if remediation guidance is required for complex cluster or service‑account scenarios.

---

Strengths and weaknesses of Microsoft’s handling​

• Strengths:
• Microsoft quickly added a known‑issue note to the affected KBs and publicly acknowledged the problem, which allowed enterprises to triage with clearer hypotheses.
• An out‑of‑band fix was produced within a predictable window (released December 18, 2025 for Windows 10 ESU builds), showing responsiveness to enterprise impact.
• Weaknesses:
• The initial updates lacked a compatibility shim or a clear mitigation path in the release notes, leaving many ops teams to choose between rollback and insecure ACL workarounds.
• The OOB fix distribution via the Microsoft Update Catalog (not always automatically available in WSUS or normal Windows Update channels) forced extra operational work for large fleets.

---

Final assessment and recommendations​

The December 2025 MSMQ incident is a sober reminder that OS‑level security improvements can have disruptive compatibility consequences, particularly when they touch filesystem ACLs used by legacy middleware. The correct operational response is pragmatic and layered:

• Prioritize Microsoft’s out‑of‑band fix for affected SKUs, validate in test rings, and then deploy to production.
• Where the OOB cannot be immediately applied, prefer controlled rollback or a minimal, auditable ACL change rather than broad permission grants.
• Treat this incident as a case study: extend patch testing orchards to include legacy middleware, document service‑account requirements explicitly, and automate inventory for optional Windows components like MSMQ.

Administrators should also use the episode to reduce reliance on decade‑old middleware where practical: consider migration paths to modern message brokers (Azure Service Bus, RabbitMQ, Kafka) where operational control and vendor support models better match modern patching cadence. That is a multi‑quarter program but lessens the long‑term fragility that surfaced here.

---

This issue has been verified in Microsoft’s KB documentation for the December 9, 2025 cumulative updates and the subsequent out‑of‑band KB5074976 release; independent reporting and community triage corroborate the symptoms, root cause, and the operational mitigations employers and administrators used while waiting for vendor remediation. Conclusion: apply the vendor OOB as soon as it safely fits change control windows; if emergency uptime demands otherwise, use the least‑privilege, auditable workaround possible and revert when the official fix is in place. The core security objective — preventing privilege misuse in MSMQ storage — is valid, but compatibility must be preserved or explicitly documented when security descriptors change for components still widely in use.

---

Source: Techzine Global Microsoft patches bug causing multiple Message Queuing errors