Microsoft’s December Patchday produced an unexpected operational hazard for Message Queuing (MSMQ): a change to the MSMQ security model and NTFS permissions introduced with the December 9, 2025 cumulative updates can prevent applications and IIS sites from writing to message queues, causing queues to become inactive and services to fail. Microsoft has confirmed the issue in the Windows update support articles for the December packages and says it is investigating; administrators are already reporting service interruptions and community-sourced workarounds that carry trade-offs.
Background
What is MSMQ and why it matters
Microsoft Message Queuing (MSMQ) is a core Windows messaging subsystem that provides durable, asynchronous message delivery between applications and services. It is frequently used in legacy enterprise applications, integration layers, and in scenarios where guaranteed delivery and durable storage are required. Because MSMQ persists messages on disk and mediates communication between processes and machines, failures in MSMQ can quickly cascade into application outages and data-processing backlogs.
MSMQ remains present in many enterprise estates—often as part of older distributed applications—so operational problems with MSMQ are not theoretical edge cases; they affect production workloads. Community troubleshooting and enterprise advisories reflect real-world incidents where MSMQ failure has produced cascading downtime for services that depend on queued delivery.
The December update wave that triggered this
The issue surfaced after Microsoft’s December 9, 2025 cumulative updates (for example, KB5071546 for Windows 10 22H2 builds 19045.6691/19044.6691), which include security fixes and servicing stack updates. Microsoft’s support articles for the affected KBs now list a confirmed known issue: MSMQ functionality may be disrupted after installation. The vendor’s article describes the symptoms, root cause (a change to the MSMQ security model and NTFS permissions on the MSMQ storage folder), and notes that the issue is under investigation.
Symptoms and operational impact
How the failure looks in the wild
Administrators and application owners have observed a consistent set of symptoms after applying the December updates:
- MSMQ queues become “inactive” and stop accepting messages.
- IIS-hosted pages or services fail with exceptions such as “Insufficient resources to perform operation,” often surfaced as System.Messaging.MessageQueueException in .NET applications.
- Applications cannot write to queues, raising errors or returning failures when calling MSMQ APIs.
- Error events referencing storage file creation failures, for example: “The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created.”
- Misleading log entries claiming “There is insufficient disk space or memory” despite ample disk space and RAM, obfuscating the real permission-related root cause.
These symptoms have been reported on Windows 10 (22H2) and on Windows Server 2016 and 2019, including clustered MSMQ deployments under load, amplifying the operational risk for enterprise environments. Administrators in public forums and support threads corroborate Microsoft’s symptom list and add real-world details on impact and attempted remediations.
Why the damage is outsized
MSMQ is often embedded in critical workflows—order processing, payment systems, archival pipelines, integration adapters, and similar middleware. When queueing stalls, messages accumulate, processing pipelines halt, and retries or outages ripple across services. Clusters under load can exacerbate the problem and make recovery harder, because multiple nodes may simultaneously fail to write to storage and leave disparate components in inconsistent states.
Root cause — what changed and why it matters
The permissions change at the center
Microsoft’s investigation traces the problem to changes introduced in the MSMQ security model and to NTFS permission adjustments on the folder:
C:\Windows\System32\MSMQ\storage
After the December updates,
MSMQ users (the identities used by services/app pools that write to MSMQ) require explicit write access to the MSMQ storage folder, whereas historically that folder’s write permissions were restricted to administrative accounts and the operating system. When a non-privileged process attempts to create or append message files under the new permission model, the write operation can fail and MSMQ surfaces resource-style errors rather than obvious access-denied messages. Microsoft’s update notes describe this root cause and list the affected operating system SKUs.
Why the error messages are confusing
Because MSMQ operations involve internal file creation and storage allocation, a
permission failure inside the MSMQ storage layer manifests as an inability to create the message file. Internally these failures might be reported in code paths that translate to "insufficient resources" or other generic messages. That makes the problem harder to diagnose: admins see resource exhaustion errors and may chase disk quotas or memory tuning rather than file ACLs.
Who is affected
- Windows 10, version 22H2 (and associated LTSC / ESU SKUs where the update was applied)
- Windows Server 2016
- Windows Server 2019
Microsoft’s published notes list those platforms as affected by the MSMQ known issue in the December cumulative updates. Community reports also show incidents on Server 2016 and Server 2019 hosts and fewer or no reports on Server 2022 in the same timeframe.
Immediate mitigation options — safe and risky approaches
Microsoft states the issue is under investigation and has not published an official workaround at the time of the advisory. In production environments, administrators have two practical courses of action: revert the patch or apply a targeted permissions change as a temporary workaround. Each option carries operational and security trade-offs.
Option A — uninstall the December LCU (rollback)
- Remove the problematic cumulative update from affected hosts (for example, uninstall KB5071546 on Windows 10 22H2 or the matching KB on Server 2016/2019).
- Reboot if required and validate MSMQ/IIS functionality is restored.
Notes and caveats:
- Some cumulative updates are combined packages that include servicing stack updates (SSUs); Microsoft’s KB guidance explains that removing the SSU is not straightforward, and removing the LCU may require using DISM /online /get-packages and Remove-Package if the package was installed as a combined SSU+LCU bundle. Consult the specific KB for removal instructions before attempting to uninstall. Rolling back eliminates the regression but re-exposes the system to the security fixes and stability improvements included in the cumulative update—so treat this as a stopgap while monitoring vendor guidance.
Option B — targeted NTFS permission adjustments (community workaround)
A number of administrators have restored MSMQ functionality by granting
write/modify permissions on C:\Windows\System32\MSMQ\storage to the service identities that must write to queues (for example, application pool identities, localservice/networkservice, or a specific service account). The change is usually limited to the storage folder and can be applied with inheritance carefully managed so only the necessary accounts receive write access.
Practical steps (example):
- Identify the process identity that needs access (e.g., the IIS application pool identity, service account, or SYSTEM-local service).
- Apply a least-privilege ACL that grants the minimal required access (Write/Create) to that account on the storage folder.
- Restart the MSMQ service (and Net.MsmqActivator / dependent services) and validate queueing resumes.
- Revoke or tighten permissions after vendor guidance or a fixed update is available.
Community reports show this approach often restores functionality faster than rolling back the KB, but it is a deviation from the standard permission model and therefore should be treated as a temporary mitigation only. Granting write access under C:\Windows\System32 has security implications—an attacker or misbehaving process granted write access to that folder could attempt to manipulate MSMQ storage. Document the change, restrict it to only required identities, and ensure auditing is enabled while the workaround is in effect.
Which mitigation is “safer”?
- Rolling back the update: Safer from an ACL/security model point of view, but reintroduces any fixes in the cumulative update that the organization may need.
- Granting write access: Faster operational fix, but increases the attack surface and deviates from baseline security settings. Use only when rollback is impractical and protect the change with monitoring, limited scope, and a fast expiry plan.
Practical detection and triage checklist
- Inventory hosts with MSMQ installed
- Use GUI: Control Panel → Programs and Features → Turn Windows features on or off → look for Microsoft Message Queuing.
- Use DISM/PowerShell:
- DISM: Dism /Online /Get-Features /Format:Table | FINDSTR "^MSMQ-"
- PowerShell: Get-WindowsOptionalFeature -Online | Where-Object { $_.FeatureName -like "MSMQ" }.
- For Windows Server: Get-WindowsFeature MSMQ (Server Manager module).
- Scan for symptoms
- Look for Event Log entries showing “Insufficient resources to perform operation,” message file creation errors under MSMQ, or application exceptions from System.Messaging.
- Check IIS sites and app logs for “System.Messaging.MessageQueueException” or 500 errors triggered when queue operations are expected.
- Confirm the KB and patch state
- Identify which December 2025 KB was installed; consult Settings → Update History or wusa /query to find installed updates. Cross-check against Microsoft’s December KB list for your SKU.
- Test replication in lab
- Reproduce in a lab before applying an ACL change. Add a test non-privileged account and validate whether creating message files in C:\Windows\System32\MSMQ\storage is denied.
- If the lab reproduces the issue, plan the mitigation and rollback sequence for production.
- Apply a temporary mitigation with a roll-forward plan
- If time-critical applications are blocked, consider the folder ACL workaround, document it centrally, and schedule a security review and reversion once Microsoft issues a fix.
Recommended long-term actions for administrators
- Treat MSMQ as critical infrastructure: include it in inventory, monitoring, and patch testing matrices.
- Maintain a staging ring for cumulative updates; deploy security updates to a small but representative set of hosts first and verify MSMQ-dependent applications.
- Harden MSMQ usage: minimize which identities can write to MSMQ, enforce least privilege for application pools and service accounts, and segment MSMQ hosts behind internal networks and firewalls where possible.
- Consider migration off legacy MSMQ where feasible. Modern managed message systems (Azure Service Bus, RabbitMQ, Kafka) reduce reliance on OS-level storage semantics and decouple application stacks from OS servicing changes—though migration carries its own cost and complexity.
- Keep an incident playbook for patch rollbacks that accounts for SSU/LCU packaging and the additional steps required to remove combined updates safely. Microsoft’s KBs include removal instructions that must be followed to avoid breaking servicing stacks.
Critical analysis — vendor response, engineering trade-offs, and risks
Microsoft response and transparency
Microsoft has acknowledged the regression in its December KB support articles and has updated those pages to warn customers of the MSMQ issues. That rapid acknowledgement helps administrators triage and reduces time spent chasing incorrect root causes. However, the vendor’s initial advisory stopped short of a recommended workaround or an immediate hotfix in the public KB text at the time of publication, leaving many enterprises to choose between rollback and risk-managed temporary fixes. The combination of vendor confirmation and community validation is valuable but incomplete until a documented mitigation or patch is released.
What went wrong architecturally
The incident highlights a hazardous interaction between
OS security hardening (adjusting access semantics for a system folder) and
compatibility expectations of legacy subsystems and applications. Tightening NTFS semantics can improve security, but changing those semantics without backward-compatible allowance for longstanding non-administrative MSMQ identities risks breaking established applications. That trade-off—security vs. compatibility—recurs across patch maintenance. Ideally, such permission model changes would be staged with clear opt-in behavior or accompanied by an immediate configured mitigation to preserve service continuity.
Security risk of the community workaround
Granting write access to a System32 subfolder, even in a limited scope,
increases the attack surface. An adversary who can run code as the same identity now trusted to write into system MSMQ storage could attempt to tamper with queue data or store payloads in a protected area. If a temporary ACL change is necessary, it must be extremely targeted, logged, and reversed as soon as a vendor fix is available.
Operational risk to production estates
- Clusters and load scenarios: the problem is reproducible under load and in clustered MSMQ environments; cluster-wide failures are thus plausible.
- False diagnostics: misleading error messages (insufficient memory/disk) can waste precious triage time.
- Patch rollback complexity: combined SSU+LCU packages complicate removal procedures; admins must follow KB-prescribed steps to safely remove fixes.
Cross-referenced verification and what is certain
- Microsoft’s support articles for the December 9, 2025 updates explicitly list an MSMQ known issue and describe the permission model change and symptomatic failures. That is the authoritative vendor statement.
- Multiple community sources and vulnerability databases map the MSMQ issue to CVE-2025-62455 (the vulnerability identifier associated with Message Queuing fixes) and list the KB mapping across affected SKUs; independent vulnerability trackers confirm the CVE and the packages that include the change. This cross-reference supports the conclusion that the December updates touched MSMQ in ways that materially changed behavior.
- Community posts and enterprise troubleshooting threads show that granting write permissions to the MSMQ storage folder has restored operations in many cases; these remedies are community-sourced and not Microsoft-endorsed at the time of writing, so they should be treated as temporary mitigations. Administrators must weigh the security trade-offs.
Where public documentation is incomplete—such as a fully detailed engineering root cause and an official, Microsoft-recommended mitigation—those gaps are noted. Any claim about exploitability or precise CVSS semantics beyond Microsoft and reputable trackers’ published details is flagged as speculative.
Step-by-step quick runbook (for emergency triage)
- Identify affected hosts:
- Use DISM /Online /Get-Features /Format:Table | FINDSTR MSMQ or Get-WindowsOptionalFeature -Online to enumerate MSMQ presence.
- Confirm symptom presence:
- Inspect Application/System logs for MessageQueue exceptions and storage file creation errors; test a simple producer application to validate queue writes.
- If MSMQ is broken and business impact is severe:
- Option 1 (preferred if acceptable): Uninstall the December LCU that introduced the change following Microsoft KB guidance and test. Validate consequences for other updated components.
- Option 2 (if rollback is not feasible): Apply a narrowly scoped ACL that grants write permissions to the specific service or app pool identity that needs to write to C:\Windows\System32\MSMQ\storage. Document the change and plan to revert. Monitor for malicious activity.
- Schedule patching cadence:
- Test updates in a staging ring and delay broad deployment of new cumulative updates until MSMQ-dependent apps and clusters are validated.
- Track Microsoft updates:
- Monitor the KB article and the Windows release health/message center for vendor advisories, hotfixes, or updated remediation guidance.
Conclusion
The December 2025 cumulative update regression that affects Message Queuing is a reminder that
privilege and filesystem semantics changes at the OS level can have outsized operational consequences, particularly for legacy middleware like MSMQ. Microsoft has confirmed the issue and is investigating; meanwhile, operators must choose between rollback and a temporary ACL-based workaround that restores service at the cost of a broader security posture change.
The right path depends on each organization’s risk tolerance, patch policy, and operational constraints: test the options in a lab, favor the least-permission exposure possible if opting for an ACL workaround, and prepare a staged remediation plan that reinstates secure defaults once an official fix is released. Administrators should prioritize inventory and monitoring of MSMQ hosts, validate the presence and identity of agents that write to queues, and treat this incident as a lesson for tighter coordination between security hardening and compatibility testing in patch rollouts.
Source: Heise Online
Patchday Problem: Message Queuing issues in Windows 10, Server 2016, and 2019