STATUS_MORE_ENTRIES (0x00000105) – Fix for Enumeration API Errors

1. Buffer Too Small for Enumeration Results

This is the culprit in about 80% of cases. Your app called an enumeration API—like NetShareEnum, RegEnumKeyEx, or FindFirstFile—but the buffer you allocated wasn't big enough. The API returns STATUS_MORE_ENTRIES (0x00000105) to tell you there's more data waiting.

The fix is dead simple: loop the call. Don't allocate a huge buffer upfront—that's wasteful. Instead, call the function with a buffer that's reasonable (say 4096 bytes for 64 entries), then keep calling it until it stops returning STATUS_MORE_ENTRIES. Each call should start where the last one left off, using the returned context handle or index.

Here's the pattern for C++ using Win32 API:

DWORD entriesRead = 0;
DWORD totalEntries = 0;
DWORD resumeHandle = 0;
LPSHARE_INFO_502 buf = NULL;
DWORD bufsize = 4096;
DWORD ret;

do {
    ret = NetShareEnum(NULL, 502, (LPBYTE*)&buf, bufsize, &entriesRead, &totalEntries, &resumeHandle);
    if (ret == ERROR_MORE_DATA || ret == NERR_Success) {
        // Process entries in buf
        for (DWORD i = 0; i < entriesRead; i++) {
            wprintf(L"Share: %s\n", buf[i].shi502_netname);
        }
        NetApiBufferFree(buf);
        buf = NULL;
    }
} while (ret == ERROR_MORE_DATA);

Notice I'm using ERROR_MORE_DATA—that's the same as STATUS_MORE_ENTRIES but for the NetApi layer. On the registry side, you'd use ERROR_MORE_DATA as well with RegEnumKeyEx. Always check the return, then continue.

One real-world trigger: you're enumerating shared folders on a file server with 200+ shares via NetShareEnum. The default buffer of 4096 bytes fits maybe 50-60 entries. Your code throws STATUS_MORE_ENTRIES and stops. Loop it, and you're golden.

2. Corrupted Enumeration Handle or Context

Less common but nasty. If you're using an API that returns a handle or context (like FindFirstFile/FindNextFile), a corrupted handle can make the system think there's more data when there isn't—or send you into an infinite loop.

The usual cause: you closed the handle early, or you're sharing it across threads without synchronization. On Windows 10/11, I've seen this with antivirus hooks that intercept file enumeration and mangle the handle. The API then returns STATUS_MORE_ENTRIES on every call, never reaching ERROR_NO_MORE_FILES.

Fix: check the handle after every call. If FindNextFile returns STATUS_MORE_ENTRIES but GetLastError is still ERROR_SUCCESS? That's suspicious. Realistically, you should also validate the handle isn't invalid before the loop starts. Add a simple guard:

HANDLE hFind = FindFirstFile(L"C:\\*", &ffd);
if (hFind == INVALID_HANDLE_VALUE) {
    // Handle error
    return;
}
BOOL more = TRUE;
while (more) {
    // Process ffd
    more = FindNextFile(hFind, &ffd);
    if (!more) {
        DWORD err = GetLastError();
        if (err == ERROR_NO_MORE_FILES) {
            break;
        } else if (err == ERROR_MORE_DATA) {
            // Unusual but possible with corrupt handle
            // Reset and try again? Or abort.
            break;
        } else {
            // Real error
            break;
        }
    }
}
FindClose(hFind);

I've also seen this pop up in PowerShell scripts using Get-ChildItem against DFS shares on Server 2019. The underlying handle gets stale. The fix there is to use -ErrorAction Stop and catch the exception, or switch to [System.IO.Directory]::EnumerateDirectories which doesn't use the same old handle mechanism.

3. Third-Party Filter Drivers Interfering with Enumeration

This one's a pain because it's not your code—it's the system. Filter drivers (antivirus, backup agents, encryption software) hook into the same APIs you're calling. If they return STATUS_MORE_ENTRIES incorrectly, your application sees phantom data.

Real scenario: a company used Symantec Endpoint Protection on Windows Server 2016. When a user enumerated their mapped drives, Explorer would show 10 shares, then the dialog would hang. Process Monitor revealed an extra STATUS_MORE_ENTRIES from the Symantec driver's filter. The fix? Update the driver or disable real-time scanning on the SMB port.

How to diagnose: run fltmc instances from an admin command prompt. You'll see all loaded filter drivers. If you see something like SymEFS or FileCrypt, that's your suspect. Disable it temporarily (after coordinating with security team, obviously) and test.

fltmc instances
fltmc detach SymEFS C:   # But don't run this without understanding the consequences

For a permanent fix, work with the vendor to get a compatible version. I've also seen this with older versions of Carbon Black and CrowdStrike. Updating to current builds (2022+) usually resolves it.

Quick-Reference Summary

Start with cause 1. It's the most common by a mile. If that doesn't work, move to cause 2. Cause 3 is a last resort—but I've seen it enough to include it.