When “Insufficient Resources” Isn’t the Real Problem: A Hidden MSMQ (Microsoft Message Queuing) Issue that customers are reporting.

Every so often, a support ticket starts with a sentence like this:

“Nothing changed on our side, but suddenly queues stopped working.”

Plenty of space on the disk.
No memory issues in Windows Event Viewer.
No obvious configuration changes.

The logs show “insufficient resources” errors when attempting to use MSMQ as part of an application that converts documents to PDF.

After asking customers about any other changes they made since errors appeared, the common thread was a Windows update that changed the permissions on the MSMQ Windows feature.

The Symptoms Don’t Point Where You’d Expect

If you’re affected, the symptoms may look familiar:

• MSMQ queues suddenly becoming inactive
• Applications that use MSMQ unable to write to message queues
• Errors such as:
  “The message file ‘C:\Windows\System32\msmq\storage*.mq’ cannot be created” in Windows Event logs.
• Misleading log entries claiming there is insufficient disk space or memory — even when there is plenty of memory available.

At first glance, these issues look like classic infrastructure problems. The natural reaction is to investigate storage, memory, or system load.

But in these cases, that’s a dead end.

What Actually Changed (And Why It Matters)

The root cause turns out to be a change in the MSMQ security model introduced by a recent Windows update.

Specifically:

• NTFS permissions on
  C:\Windows\System32\MSMQ\storage
  were tightened
• MSMQ now requires explicit write access to this folder
• In many enterprise or managed IT environments, this folder is restricted to administrators

As a result, attempts to send messages via MSMQ APIs can fail with resource-related errors — even though system resources are perfectly healthy.

This is why the logs are so misleading: the failure has nothing to do with disk or memory availability.

This issue primarily affects enterprise and managed IT environments. Users on Windows Home or Pro editions are very unlikely to encounter it.

The Fix (And Why You Might Have Missed It)

Microsoft addressed this issue in an out-of-band Windows update released on or after December 18, 2025 (KB5074974). Installing this update will resolve the issue that was created by the regular December 2025 Windows update. The next regular Windows update in January will contain this fix.

Why We’re Sharing This

We’re not sharing this because it’s a Global Cents product issue — it isn’t.

We’re sharing it because:

• MSMQ is still deeply embedded in many enterprise architectures.
• Problems like this can quietly break processes far beyond one application.
• The error messages send teams in the wrong direction, costing hours (or days) of investigation.

We’ve seen how frustrating it is when systems fail for reasons that aren’t obvious — especially when everything appears healthy on the surface.

If this saves one team a few hours of troubleshooting, it’s worth writing.

A Final Thought

Issues like this are a good reminder of something we see often:

When infrastructure components change under the hood, the symptoms don’t always tell the real story.

If you’re running MSMQ in a production environment and suddenly hit unexplained resource errors, don’t assume your infrastructure is failing you. Sometimes, it’s just a permission change hiding in plain sight.