Fix TYPE_E_BUFFERTOOSMALL (0X80028016) — Buffer too small

When This Error Hits

You'll see TYPE_E_BUFFERTOOSMALL (0x80028016) when your code tries to read a registry value, load a type library, or call a COM method that returns more data than the allocated buffer can hold. Classic triggers:

• Calling RegQueryValueEx on a registry key with a value longer than your buffer size.
• Using LoadTypeLib or QueryPathOfRegTypeLib with a fixed-size array that's too small.
• VBA or C++ automation that passes a BSTR or SAFEARRAY without checking required size.
• Any COM method returning a string that overflows the caller's buffer — common with older Windows APIs like GetWindowText or GetModuleFileName when called through COM wrappers.

Root Cause

The culprit here is almost always a hardcoded buffer size that's too small for the actual data. Windows APIs and COM interfaces usually return the required size in a separate parameter, but developers often skip that check. So the call fails with TYPE_E_BUFFERTOOSMALL instead of gracefully resizing. The error code itself is 0x80028016, which maps to "one of the parameters is invalid" in the COM error family — but in practice it's the buffer length parameter that's wrong.

The Fix

Don't bother with random registry tweaks or reinstalling the app. The fix is in your code or the calling environment. Here's the step-by-step.

Step 1: Identify the failing call

Check your code for any API or COM call that takes a buffer and a size parameter. Common suspects:

// C++ example — wrong way
TCHAR buffer[128];
DWORD size = 128;
RegQueryValueEx(hKey, _T("LongValue"), NULL, NULL, (LPBYTE)buffer, &size);
// If the value is over 128 chars, you get 0x80028016

Step 2: Use a dynamic buffer

Call the function twice. First call with NULL buffer and a pointer to receive the required size. Then allocate a buffer of that size, and call again.

// C++ — correct approach
DWORD size = 0;
RegQueryValueEx(hKey, _T("LongValue"), NULL, NULL, NULL, &size);
// size now holds the required buffer length in bytes
TCHAR* buffer = new TCHAR[size / sizeof(TCHAR)];
RegQueryValueEx(hKey, _T("LongValue"), NULL, NULL, (LPBYTE)buffer, &size);
// Use buffer
delete[] buffer;

In VBA or VB6, use String with Space$ to preallocate:

Dim buffer As String
Dim size As Long
size = 256
buffer = Space$(size)
Call SomeCOMObject.SomeMethod(buffer, size)
' If size returned > 256, resize and call again

Step 3: For type library loading specifically

If you're using LoadTypeLib or QueryPathOfRegTypeLib, the buffer for the path must be at least MAX_PATH (260 chars). But long paths can exceed that on Windows 10/11 with long path support enabled. Switch to LoadTypeLibEx with dynamic allocation, or use std::wstring with .c_str().

// Use a std::wstring for dynamic sizing
std::wstring path;
path.resize(MAX_PATH);
HRESULT hr = QueryPathOfRegTypeLib(...);
if (hr == TYPE_E_BUFFERTOOSMALL) {
    // Query again to get actual size, resize, retry
}

Step 4: Check for string termination

Sometimes the buffer size includes or excludes the null terminator. The API docs will say. RegQueryValueEx returns size including the null in bytes. GetWindowText returns characters excluding null. If you're one off, you'll hit this error on exact-size matches. Always add 1 to the returned size before allocating.

If It Still Fails

• Check the calling code's error handling. Some COM wrappers silently ignore the returned size and reuse a stale buffer. Add debug output of both the requested size and the returned size.
• Look for registry redirection. If you're on 64-bit Windows and the app is 32-bit, registry calls may be redirected to Wow6432Node. The path length can differ. Use KEY_WOW64_64KEY or KEY_WOW64_32KEY explicitly.
• Test with a massive buffer. Allocate 64KB and pass that. If it works, your original buffer was simply too small. If it still fails, the issue is something else — maybe a corrupt type library or a permissions problem.
• Reboot the machine. Yes, it's cliché, but if a type library handle is stale, a reboot clears it. Don't lean on this — find the real root cause.

Bottom line: TYPE_E_BUFFERTOOSMALL is almost never a configuration problem. It's a coding bug where you didn't account for variable-length data. Fix the buffer allocation, and the error disappears.