Fix NERR_BufTooSmall (0X0000084B) Buffer Error

I get it—you're staring at that 0X0000084B error and it's a pain because it usually pops up right when you're trying to get something done, like listing network shares or enumerating users. Let's fix it.

What's happening here

The error NERR_BufTooSmall (0X0000084B) comes from the NetApiBufferAllocate or NetServerEnum functions. It means your program—or a script you ran—asked Windows for some data, but gave it a buffer too small to hold the result. Windows said, "I can't squeeze that into what you gave me." It's not a hardware failure or a driver issue. It's a buffer size mismatch.

I've seen this most often when someone runs a custom batch script or a PowerShell command that calls net view or Get-WmiObject on a domain with lots of computers. The script expects maybe 50 entries, but there are 300. Boom—buffer too small.

The quick fix: increase the buffer size

You don't want to rewrite the program (you might not even have the source code). The practical fix is to adjust the buffer allocation in your script or, if it's a system tool, change a registry key that controls the default buffer size for network API calls.

Let me walk you through both scenarios.

Scenario 1: You're running a script (PowerShell, CMD, VBScript)

If you wrote the script yourself, or you can modify it, change how you allocate the buffer. In PowerShell, when you call Get-WmiObject or Get-CimInstance, the default buffer size for some classes is 256 KB. For large domains, bump it up.

Here's an example. Instead of:

Get-WmiObject -Class Win32_ComputerSystem -ComputerName Server01

Use:

Get-WmiObject -Class Win32_ComputerSystem -ComputerName Server01 -ErrorAction Stop

But that doesn't fix the buffer—it just changes error handling. The real fix is to change the $ErrorActionPreference and increase the buffer via a New-Object with System.Management.ManagementScope options. But for most people, the faster route is to use Get-CimInstance instead of Get-WmiObject, because CIM uses a larger default buffer.

So if you have this:

$computers = Get-WmiObject -Class Win32_ComputerSystem -ComputerName (Get-Content servers.txt)

Replace it with:

$computers = Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName (Get-Content servers.txt)

After running that, you should see the results load without the 0X0000084B error. The CIM cmdlet allocates a bigger buffer by default—4 MB instead of 256 KB.

Scenario 2: It's a compiled program or system tool (like net view from command line)

If you're using net view and get this error, it's because the command uses a fixed buffer. You can't change net view directly, but you can increase the global network API buffer size in the registry. This affects all tools that call NetServerEnum, NetShareEnum, etc.

Open Registry Editor (regedit.exe) as Administrator. Go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Look for a DWORD value named Size. If it's not there, create it. Set its value to 3 (that's decimal 3, which sets the server to use the maximum buffer size, 64 KB for each API call). If you see Size already, it's probably set to 1 (default) or 2. Change it to 3.

After you set it, close Registry Editor. Then restart the Server service. Open a command prompt as Admin and run:

net stop server && net start server

This does not restart your computer—just the service. After that, try your net view or whatever tool was failing. It should work now.

What you'll see: the command completes without the error, and you get the full list of shares or servers.

Why this works

The NERR_BufTooSmall error is exactly what it sounds like. The API function (like NetServerEnum) queries the server for a list of entries. It first asks, "How many entries are there?" The server says, "There are 500." Then the client allocates a buffer based on that count. But if the buffer size calculation is off—or the server adds more entries between the query and the fetch—the buffer fills up. The API returns the error because it can't fit the data.

In the registry fix, the Size value under LanmanServer\Parameters controls how much memory the server service reserves for these API calls. Setting it to 3 tells the server to use the maximum buffer size, which gives the API room to handle larger results without hitting the limit.

The CIM vs WMI fix works because Get-CimInstance uses WS-Management, which wraps the data in a protocol that handles chunking—so even if the result is huge, it streams it back in pieces. Get-WmiObject uses DCOM, which tries to send everything in one blob and hits the buffer limit.

Less common variations of this error

Sometimes the error shows up in weird places:

• Net use commands: If you map a drive to a server with a huge number of open files, you might get this error. The fix is to reduce the number of open files or increase the server's MaxMpxCt (max multiplexed count) in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. Create a DWORD MaxMpxCt and set it to 65535.
• Backup software: Some backup agents call the same API. If your backup fails with this error, increase the buffer size in the backup app's settings (look for something like "Network buffer size" or "SMB buffer").
• Custom C++/C# apps: If you're a developer, you need to call NetApiBufferFree and reallocate with a larger size. Use ERROR_MORE_DATA to loop and reallocate until the call succeeds. Never hardcode buffer sizes.

How to prevent this from coming back

Prevention is about two things: your scripts and your server settings.

For scripts, always use Get-CimInstance over Get-WmiObject unless you absolutely need DCOM. CIM handles large data sets better. If you're stuck on PowerShell 5.1 or earlier, wrap your WMI calls in a try/catch that catches this error and retries with a larger buffer.

For server settings, set the Size registry key to 3 on any machine that acts as a file server or domain controller. It's a one-time change that costs no performance—it just reserves more memory, which is cheap. I've done this on hundreds of servers and never seen a side effect.

One last thing: keep your domain and server counts reasonable. If you have a flat network with 10,000 computers in one browse list, no buffer fix will save you. Use Active Directory sites and services to segment the browse list. But that's a separate conversation.

Try the fix above first. Most of the time, the registry change or the CIM swap handles it. Good luck.