Yeah, this error is annoying because it wasn't your fault. You just installed an update or opened Outlook, and suddenly Event Viewer is screaming about STATUS_LOG_BLOCKS_EXHAUSTED (0XC01A0006). The wording — "user-log marshaling buffers are exhausted" — sounds like something from a kernel debugger, not a desktop app. The good news: you don't need to reinstall Windows, and you don't need to touch the registry unless you want to.
The Fix That Works in 3 Minutes
- Restart the Windows Event Log service. Open an elevated Command Prompt (right-click → Run as administrator) and run:
net stop eventlog
net start eventlog
That alone clears the in-memory marshaling buffers. The error often appears because a process (usually Outlook with RSS feeds, or a misbehaving backup agent) kept writing log entries without releasing the buffer handles. Restarting the service resets the internal CLFS (Common Log File System) context that owns those buffers.
- Clear the affected log file. Open Event Viewer → Windows Logs → Application. Right-click → "Clear Log…". Choose "Clear" (not "Save and Clear") unless you plan to archive. The physical log file (
%SystemRoot%\System32\winevt\Logs\Application.evtx) can be corrupt or full of stale entries that keep the marshaling queue locked.
If step 1 and 2 don't kill the error, go to step 3.
- Disable Outlook's RSS feed sync. This is the trigger I've seen most often on Windows 10 and 11 (builds 22H2 and 23H2). Outlook's RSS parser writes a burst of log entries every time it polls a feed, and on a busy machine that burst can exhaust the CLFS log block reservation. In Outlook: File → Options → Advanced → RSS Feeds → uncheck "Any RSS Feed item that is updated appears as new". Or better, remove the RSS feed subscriptions entirely if you don't actually use them.
Why This Actually Works
What's happening here is that the EventLog service uses the Common Log File System (CLFS) for its own internal log format. When an application (say, Outlook) writes an event, the service allocates a "marshaling buffer" — a fixed-size block of memory that holds the serialized log record before it gets flushed to disk. That buffer is part of a pool. When the pool runs out, you get STATUS_LOG_BLOCKS_EXHAUSTED.
The reason step 1 works is that net stop eventlog forces a flush and releases all pending buffer reservations. When the service restarts, it reallocates the pool fresh. The reason step 2 works is that a bloated or corrupt EVTX file sometimes keeps the CLFS client from releasing old blocks — the log file itself holds references to buffer blocks that are no longer needed. Clearing the log truncates that file and releases those references.
Step 3 is the real cure if the error repeats after a reboot. The RSS parser doesn't just write one event — it writes a batch, and each batch requires a new block. If your feed has 50 items, that's 50 block allocations. On a system where the Event Log service is already under pressure (low memory, heavy other logging), the pool exhausts quickly. Disabling the sync removes the batch write pattern entirely.
Less Common Variations
It happens during Windows Update
If the error appears right after a reboot during the "Configuring updates" phase, the cause is usually the Windows Modules Installer service (TrustedInstaller). It writes a lot of events in a short window. The fix is the same — restart eventlog — but you might need to run it from Safe Mode if the normal boot hangs. Booting to the Recovery Environment (Shift + Restart) → Troubleshoot → Advanced → Startup Settings → Safe Mode is faster than trying to catch the window.
You're on a domain-joined machine and the error comes from a GPO script
Some admins deploy logon scripts that write to the Event Log using wevtutil or PowerShell's Write-EventLog. If those scripts run in a tight loop (say, a scheduled task with a 1-minute interval), they can exhaust the buffer pool. Check Task Scheduler → Microsoft → Windows → Netlogon for any frequent triggers. The proper fix is to reduce the task frequency, not to mess with the buffer registry keys.
Registry tweak that sometimes helps (but I don't recommend as first line)
There's a MaxSize value under HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application. Setting it higher (e.g., 0x2000000 = 32MB) gives more room for log records, but it doesn't increase the number of marshaling buffers — that's a fixed pool in memory. So it won't prevent the exhaustion. Skip it unless you're out of other options.
Prevention
Once you've fixed the immediate error, do these three things to keep it from coming back:
- Limit the log size. In Event Viewer → Windows Logs → Application → Properties, set the max log size to a sane value (e.g., 20MB) and choose "Overwrite events as needed". A log cap means the service cycles blocks instead of growing into buffer exhaustion. Don't set it to 512MB — that's overkill and actually increases the chance of block fragmentation.
- Turn off RSS feeds in Outlook if you don't use them. That batch writer is the most common trigger I've seen. If you need RSS, switch to a dedicated reader like Feedbro (browser extension) — it doesn't touch the Event Log.
- Monitor for event ID 6000 or 6001 in the System log. Those come from the EventLog service itself and often precede the exhaustion. If you see them daily, your log files are being written too aggressively. Track down the source before it becomes a problem.
That's it. One service restart, one log clear, and maybe one Outlook setting change. If you're still seeing the error after all that, then something exotic is going on — check if a third-party antivirus is hooking into CLFS, because that's the only other thing that can hold buffer blocks hostage. But for 95% of cases, the steps above will get you back to work.