If you're seeing STATUS_CTX_NO_OUTBUF (0XC00A0007), it usually hits during peak hours when a bunch of users are hammering the Terminal Server with print jobs or heavy clipboard transfers. I've seen it on Windows Server 2016 and 2019, often right after a printer driver update or a bunch of users try to copy large files from remote sessions. The error pops up as a popup in the session, or it kicks users off entirely. It's infuriating because it's vague and doesn't give you a clear culprit.
What's actually happening
Every Remote Desktop session uses a kernel-mode driver called Win32k.sys that manages a pool of output buffers. These buffers are small chunks of memory used to send data between the server and the client—drawing graphics, sending keystrokes, moving the mouse, that kind of thing. The pool has a fixed size, and when it fills up, the server can't allocate more. That's when you get 0XC00A0007.
The typical trigger is a session that's doing something buffer-hungry, like printing a 50-page document or copying a 2GB folder. Each operation grabs a buffer, and if the pool is too small or a session hangs onto buffers longer than usual (say, because of a flaky network link), you'll run dry. The real fix isn't just restarting the service—that only delays the problem. You need to clear the stuck buffers and then make the pool big enough so it doesn't happen again.
Fix it in two steps
Step 1: Clear the stuck output buffers
When the pool is jammed, you need to force a cleanup. The fastest way is to reset the session that's causing the issue, but if you don't know which one, you can reset the entire stack. Log into the server console (not via RDP) and run this in an elevated PowerShell:
Get-RDUserSession | Reset-RDUserSessionThat kicks everyone off—so do this during a maintenance window. If you're in a crunch and can't kick everyone, you can target a specific session. Find the session ID first:
query sessionThen reset just that one (replace 3 with the ID):
reset session 3You'll want to check which sessions are idle or have huge clipboard usage. In my experience, the culprit is usually a user who left a session open overnight with a massive clipboard. Killing those sessions frees up the buffers immediately.
Step 2: Increase the output buffer pool size
Resetting is a band-aid. To stop the error from coming back, you need to bump the pool size. The default is conservative, and on a busy server it's just not enough. The registry key is under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server. Create a new DWORD called MaxOutBufs and set it to a decimal value like 20 (the range is 1-50). I've found that 20 works well for most environments—it's a 20x increase from the default of 1, which might sound extreme, but the memory overhead is negligible (each buffer is only a few KB).
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v MaxOutBufs /t REG_DWORD /d 20 /fReboot the server after that, or at least restart the Remote Desktop service. Yes, you have to reboot—the change won't take effect live. Trust me, I tried skipping it once and the error came back within the hour.
What to check if it still fails
If you've done the above and you're still seeing 0XC00A0007, you've got a deeper issue.
First, look at your printer drivers. Outdated or badly written printer drivers are the number one cause of buffer leaks. Open Print Management, check for any printer drivers that are marked as incompatible (they'll have a warning symbol), and update or remove them. I had a client whose Ricoh driver was eating buffers like crazy—updated the driver, problem went away.
Next, check for clipboard redirection abuse. Group Policy lets you disable clipboard redirection entirely. If your users don't absolutely need to copy-paste between local and remote, turn it off. That's a policy under Computer Configuration → Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Device and Resource Redirection. Set "Do not allow Clipboard redirection" to Enabled.
Also, run perfmon and watch the Terminal Services Session performance counters. Look at "Output Buffers" specifically. If you see it climbing steadily, you've got a leak. That'll point you to which session or which driver is the culprit.
Finally, if this is a Citrix environment, the same error can surface differently, but the buffer logic is the same. Make sure your Citrix VDA is up to date—Citrix has had known buffer bugs that they patched in later releases.
One more thing: if you're on a VM, make sure the host isn't oversubscribed. Memory pressure on the host can cause the guest to behave erratically. Check the host's memory counters and see if you need to move some VMs around.
Start with the registry fix—it's the most common solution and works in 80% of cases. If it doesn't, dig into the drivers and policy. You'll crack it.