MSMQ breakage after December 2025 patch: diagnose, rollback, and workarounds

Microsoft’s December security rollup has disabled Message Queuing (MSMQ) on a subset of legacy and enterprise Windows systems, leaving queues inactive, IIS sites throwing “Insufficient resources to perform operation” errors, and critical message pipelines broken until organizations choose between rolling back the patch or applying high‑risk file‑system workarounds.

Background / Overview​

Message Queuing (MSMQ) is a decades‑old Windows component that provides durable, on‑disk messaging for asynchronous, reliable communications between processes and systems. It stores messages as files under C:\Windows\System32\MSMQ\storage and is commonly embedded in legacy IIS sites, integration middleware, and enterprise line‑of‑business systems. Because MSMQ relies on file creation and append operations in a protected system folder, its behavior is tightly coupled to NTFS permission semantics and service identity privileges.
On December 9, 2025 Microsoft shipped cumulative security updates (the December LCU wave) for a range of Windows SKUs — packaged under KB5071546 for Windows 10 ESU builds and companion KBs for older Server branches. Within days, the vendor updated those KB articles to add a known‑issue entry: the updates introduced changes to MSMQ’s security model and NTFS permissions on the MSMQ storage folder, which can break queue creation and writes under non‑admin service identities. Microsoft’s advisory is explicit about the observable symptoms (inactive queues, misleading resource errors, and failed .mq file creation) and acknowledges that clustered MSMQ deployments and heavily loaded environments are particularly vulnerable. The company is investigating and recommends that affected organizations contact Microsoft Support for mitigation assistance rather than applying a one‑size‑fits‑all fix.

---

What exactly broke: symptoms and diagnostic fingerprints​

The symptom set administrators are seeing​

• MSMQ queues show as inactive and stop accepting new messages.
• IIS‑hosted applications that attempt to enqueue messages fail with System.Messaging.MessageQueueException — typically logged as “Insufficient resources to perform operation.”
• Event logs report errors like: “The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created.”
• Diagnostic logs can misleadingly state “There is insufficient disk space or memory” even when capacity is plentiful, because the underlying error is a permission denial rather than resource exhaustion.

These symptoms are consistent across single‑server and clustered MSMQ installations, and they tend to appear under load — precisely when message storage operations are most frequent. The misleading nature of the error strings is a key operational trap; teams chasing storage or memory problems will waste valuable time before the ACL root cause becomes visible.

How to reproduce the failure in a diagnostic environment​

• Confirm MSMQ is installed and configured on the host.
• Apply the December LCU (for example, KB5071546) to a test host that mirrors production.
• Under the identity used by the application (IIS app‑pool identity, LocalService, NetworkService, or a locked‑down service account), issue a small queue write. If the identity lacks explicit write access to C:\Windows\System32\MSMQ\storage, the write will fail and a MessageQueueException is logged.

This reproducible pattern has been documented by multiple administrators and corroborated by Microsoft’s own KB updates.

---

Technical root cause — the permission hardening that backfired​

The December updates altered the NTFS security descriptor and how MSMQ enforces access to its storage folder (C:\Windows\System32\MSMQ\storage). Historically, MSMQ relied on a combination of system privileges and inherited ACLs that allowed service identities to create and append .mq files even when explicit write rights were not present. The patch changes the subsystem’s effective access expectations: non‑administrator MSMQ users now require explicit write access to the storage folder. When those identities lack it, file creation fails and the MSMQ stack surfaces generic resource errors. At an implementation level the update appears to have modified ACL inheritance flags or altered ACEs in the folder's security descriptor (SDDL). Administrators who captured SDDL diffs reported additional Auto‑Inherited flags and missing previously implicit write entries for accounts such as IIS_IUSRS, LocalService, and NetworkService. Because MSMQ’s internal error mapping converts a failed file create into a resource‑style exception, logs and application exceptions are noisy and misleading.
Microsoft indicates the permission change was part of a security hardening related to resolving an MSMQ elevation‑of‑privilege class vulnerability in the December patch cycle (the fixes are mapped to CVE activity in public trackers). The security intent appears sound; the compatibility testing and rollout, however, failed to account for real‑world operational deployments that rely on previous implicit access semantics.

---

Affected platforms, scope and who should be worried​

Confirmed affected SKUs (published vendor lists)​

• Windows 10 (ESU) — notably Windows 10, version 22H2 / 21H2 via KB5071546.
• Windows Server 2019 — listed in KB5071544.
• Windows Server 2016 and earlier server branches — listed in December server rollups such as KB5071543 and KB5071505.

Microsoft explicitly notes that Windows 10 Home and Pro consumer devices are very unlikely to be affected, because MSMQ is typically not installed on those editions. The incident disproportionately impacts managed, enterprise, and clustered environments where MSMQ remains a core middleware piece.

Practical scope and real‑world impact​

Enterprises running legacy integration software, IIS web apps that enqueue messages locally, or clustered MSMQ services are at highest risk. Real incidents documented by IT teams include broken order processing, stalled telemetry ingestion, and HTTP 500 errors in customer‑facing applications when requests attempted MSMQ writes. While public reporting includes sector anecdotes from finance, healthcare, and logistics, these remain operational reports rather than vendor‑quantified incident tallies. Treat those accounts as credible field reports but not company‑level statistics.

---

Triage and mitigation: pragmatic runbook for administrators​

Microsoft’s official guidance at the time of the advisory is to contact Support for business customers, and the vendor has not published a single, universal workaround in the KB beyond that investigative note. Community triage has produced two practical, widely used mitigations — each with trade‑offs.

Option A — Roll back the December LCU (fastest path to restoring behavior)​

• Identify the installed package:
• DISM /Online /Get-Packages or wusa /query to locate the KB package.
• Uninstall the LCU using DISM or the Control Panel update history removal path:
• Example: DISM /Online /Remove‑Package /PackageNameackage_for_KB5071546~31bf...
• Reboot and validate MSMQ writes and IIS behavior.

Pros:

• Restores previous, operational ACL semantics with high probability of immediate recovery.

Cons:

• Removes the security fixes that the update delivered (reintroduces the original CVE exposure).
• Depending on how the update was installed (combined SSU+LCU), removal can be complex and may require servicing‑stack considerations.

This approach is the right call for systems that must be restored to service immediately and where deferring the security changes is an acceptable business risk on a short, documented timeline.

Option B — Apply a narrowly scoped NTFS ACL workaround (keeps security updates in place)​

• Determine the exact identity used for MSMQ writes (IIS app‑pool identity, LocalService, NetworkService, or a named service account).
• Grant the minimum required write permission on the MSMQ storage folder:
• Example (replace identity as needed):
  icacls "C:\Windows\System32\MSMQ\storage" /grant "NT AUTHORITY\NETWORK SERVICEOI)(CI)(M)" /T
• Or use PowerShell Get‑Acl / Set‑Acl to apply and script exact SDDL adjustments.
• Audit and log the change; schedule an automatic rollback once Microsoft publishes an official patch.

Pros:

• Restores functionality without removing the security update.
• Can be targeted to only the identities that require write access.

Cons:

• Granting write/modify to a System32 folder increases attack surface; if left permanently it may permit privilege escalation from a compromised low‑privilege process.
• Requires careful change control, monitoring, and expiration of the workaround.

If choosing this path, make the ACL change as narrowly scoped as possible, audit access attempts, and limit network exposure to the host until a vendor‑approved fix is applied.

Option C — Move MSMQ storage (advanced, environment dependent)​

Some teams have considered relocating MSMQ storage to a non‑system partition or dedicated data volume where ACLs can be managed without touching System32. This is an invasive change, requires downtime, and is only feasible for environments where application and MSMQ configuration can be modified safely. It is a strategic option for larger migrations away from OS‑protected paths, but not a quick fix.

---

Step‑by‑step diagnostics checklist (concise)​

• Confirm MSMQ is installed: Get‑WindowsOptionalFeature -Online | Where FeatureName -like "MSMQ*".
• Check updates: DISM /Online /Get-Packages or Settings → Update history for KB5071546/KB5071544/KB5071543.
• Inspect ACLs: Get‑Acl -Path 'C:\Windows\System32\MSMQ\storage' | Format‑List and compare to a known‑good baseline. Look for missing Write/Modify ACEs for the running service identity.
• Reproduce a queue write under the app‑pool/service identity to capture the exact error and correlate with Event Viewer entries referencing message file creation failures.
• If urgent, apply a targeted ACL grant and test; otherwise plan for a controlled rollback of the LCU in a maintenance window.

---

Security trade‑offs, risk assessment and enterprise policy implications​

This incident is a pragmatic illustration of the perennial tension in enterprise patching: security hardening vs compatibility. The December rollout clearly aimed to close an MSMQ elevation‑of‑privilege or related vulnerability, but the breadth of ACL change produced operational regressions on systems that rely on historical, implicit ACL behavior. Administrators now face three uncomfortable choices:

• Accept temporary exposure and roll back the patch (restore availability at the expense of security).
• Accept increased attack surface by applying broad write ACLs to a system folder (restore availability without losing the security update).
• Isolate impacted hosts, apply compensating controls, and wait for Microsoft to deliver a targeted fix (slow and potentially risky for business continuity).

From a governance perspective, organizations should treat MSMQ hosts as high‑value assets: enforce least‑privilege network exposure (block MSMQ default port 1801 where appropriate), implement tight file integrity monitoring on the System32 MSMQ folder, and maintain a tested rollback/runbook for cumulative updates that touch low‑level subsystems. This event argues for more exhaustive compatibility testing of security changes across legacy middleware footprints in the enterprise.

---

Longer‑term considerations for IT teams​

1. Accelerate plans to retire or modernize MSMQ dependencies​

MSMQ is mature and reliable in many contexts, but it is also legacy. Enterprises that still depend on MSMQ for core workflows should prioritize a migration roadmap to modern, supported messaging platforms (Service Bus, AMQP brokers, cloud queueing services), or re‑architect applications to reduce dependence on OS‑level storage semantics. The incident underlines how low‑level OS hardening can cascade through legacy integration layers.

2. Improve pre‑production compatibility testing​

Security updates that touch kernel or system component behavior must be validated against a representative estate that includes legacy middleware. Organizations with long‑tail legacy stacks should maintain a staging ring that mirrors production as closely as possible — including MSMQ usage patterns and clustered configurations — to catch regressions before broad deployment.

3. Formalize emergency rollback and workaround policies​

Because removing cumulative updates can be operationally complex, enterprises benefit from playbooks that detail DISM removal steps, rollback validation steps, and temporary compensating controls. Ensure change control records and security review of any temporary ACL adjustments.

4. Consider Extended Security Update (ESU) program implications​

Windows 10 ESU customers receive patches for out‑of‑support SKUs; this incident shows both the value and the risk of extended patching: organizations pay to receive security updates but also inherit compatibility responsibilities. ESU budgets should account for increased testing and potential remediation costs.

---

What Microsoft has said and the vendor’s current posture​

Microsoft added a known issue note to the December KB articles on or around December 12, 2025, acknowledging that the updates modify MSMQ’s security model and NTFS permissions on the MSMQ storage folder — and that affected users might experience inactive queues and the resource‑style errors described above. The vendor’s public guidance directs affected enterprise customers to contact Microsoft Support for mitigation assistance while its engineering teams investigate. There was, at the time of reporting, no publicly stated ETA for a corrective hotfix. Independent reporting and community triage have converged on two takeaways: the regression is real and reproducible, and practical recovery in production has been achieved through either rollback of the December LCU or precise ACL changes — but both approaches carry meaningful trade‑offs.

---

Bottom line and recommended short‑term plan for affected organizations​

• Immediately inventory systems that host MSMQ and confirm whether KB5071546 (or the corresponding server rollups) is installed. Prioritize production messaging hosts and clustered nodes for triage.
• If a critical outage exists, prefer controlled rollback of the December LCU on affected hosts during an approved maintenance window. Document the security exposure and remediation plan, and only reapply the update once Microsoft issues a vendor‑approved fix.
• If rollback is not acceptable, apply a narrow, audited ACL grant to the exact service identity that writes to MSMQ storage, then monitor for lateral impacts and schedule the ACL change for reversion after the vendor fix is applied.
• Treat this incident as a prompt to accelerate testing and modernization plans for legacy middleware that depends on OS‑level semantics. Maintain aggressive monitoring, and keep Microsoft Support engaged for a formal remediation path.

---

This episode is a textbook example of how well‑intentioned security hardening can collide with operational reality in long‑running enterprise estates. The December updates addressed an MSMQ security concern, but the ACL change produced a compatibility regression with real business consequences. Administrators must act decisively to triage and restore service while managing the security risk of any temporary workarounds — and leaders should use the outage to reprioritize modernization and testing disciplines so the same trade‑off is not repeated.

---

Source: Petri IT Knowledgebase Latest Windows Update Breaks Message Queuing on Enterprise Systems