Fixing ERROR_MORE_DATA (0x000000EA) on Windows
This error means a system call returned more data than the buffer could hold. Usually a driver or API bug, not your fault.
Quick answer
Don't panic. This isn't a hardware failure. The error means a program called a Windows function—usually something like RegQueryValueEx, DevCfg, or WMI—and the function is trying to return data that won't fit into the allocated buffer. The fix is to update the offending driver or application, or increase the buffer size in code if you wrote the software.
What's actually happening here
Windows error code 0x000000EA is defined as ERROR_MORE_DATA in winerror.h. It's a status code, not a crash. The OS is saying: "I have more info to give you, but you didn't give me a big enough container." This usually surfaces in three real-world scenarios:
- A driver returning registry data that exceeds the pre-allocated buffer (common with buggy NIC drivers or USB controllers)
- A custom application using an API like
WNetGetUniversalNameorDeviceIoControlwithout proper length negotiation - A system tool (like
sfc /scannoworchkdsk) that can't process a corrupt file because the read size is too small
I've seen this most often on Windows 10 21H2 with Realtek network drivers. The driver tries to read a registry value larger than 1024 bytes, the buffer stays at default size, and boom—you get 0x000000EA in the Application Event Log.
Fix steps
- Identify the culprit. Open Event Viewer (
eventvwr.msc). Go to Windows Logs > Application. Look for an Error event with sourceApplication Erroror.NET Runtime(if it's a .NET app). The event details will usually show the faulting module path. Write down that path. - Update the driver or software. If the faulting module is a
.sysfile (likert640x64.sys), that's a driver. Go to Device Manager, find that driver (often under Network adapters or System devices), right-click > Update driver > Search automatically. If that finds nothing, go to the hardware vendor's site and grab their latest driver for your exact Windows version. Don't use Windows Update for this—it's often behind. - If it's a .exe or .dll, uninstall the associated program via Settings > Apps > Apps & features. Reinstall the latest version from the developer's site. Don't use a 'repair' option—those rarely touch buffers.
- If you can't update (maybe it's legacy software that's no longer supported), try running the program as administrator. Some APIs need elevated privileges to allocate larger buffers. Right-click the .exe > Properties > Compatibility > Run this program as an administrator.
- Last resort: Increase the default registry buffer size. Open Registry Editor (
regedit). Go toHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters. Create a DWORD (32-bit) value namedMaxCmdsand set it to50(decimal). Reboot. This isn't a real fix—it's a band-aid for a misbehaving network driver, but it works often enough.
Alternative fixes if the main one fails
- Run SFC and DISM—though I'm skeptical this helps for buffer errors. Open cmd as admin and run
sfc /scannow, thenDISM /Online /Cleanup-Image /RestoreHealth. If your system image is corrupt, it can cause APIs to return unexpected data sizes. It's a hail mary. - Check your code if you're a developer. You're calling something like
RegQueryValueExwithNULLfor the size parameter, or you're not looping to handleERROR_MORE_DATA. The correct pattern is to call the function once with a 0 buffer to get the required size, then allocate, then call again. Google for the exact API pattern.
Prevention tip
Keep drivers updated. That's the number one cause. Set Windows Update to automatically install driver updates (Settings > Windows Update > Advanced options > Optional updates). Also, if you're writing software that uses Windows API calls, always use the two-call pattern: first call with NULL/0 to query the needed size, then allocate, then call again. Don't assume a buffer size.
One more thing: if you see this error in a backup tool or a file copy operation, the source file might be corrupt or the file path too long. Try copying to a shorter path first. I've seen
0x000000EApop up whenCopyFilehits a file with a path longer than 260 characters—Windows still doesn't handle long paths gracefully in all APIs.
Was this solution helpful?