WSA_E_NO_MORE (0X0000277E) Fix – WSALookupServiceNext fails

Quick answer for advanced users

Call WSALookupServiceEnd after you finish iterating. The error means you kept calling WSALookupServiceNext after the handle had no more data. Also check that you handle the WSA_E_NO_MORE return correctly instead of treating it as a fatal error.

Context – why this happens

You're working with the Winsock 2 Service Provider Interface (SPI). You start a service query with WSALookupServiceBegin, which gives you a handle. Then you call WSALookupServiceNext to get results one by one. Each call returns a WSAQUERYSET structure. The problem shows up when you call WSALookupServiceNext again – but there are no more results left in the query.

What's actually happening here is: the handle still exists, but the service provider returns WSA_E_NO_MORE (value 10112, hex 0x0000277E) to signal the end. This is not a crash error. It's the Winsock equivalent of "end of file". The real issue is that your code doesn't stop calling WSALookupServiceNext when it sees this error. Or you forgot to call WSALookupServiceEnd to clean up the handle.

I've seen this on Windows Server 2022 and Windows 11 when a service discovery loop runs in a tight while loop without checking the return code. One developer I helped had a bug where they used SOCKET_ERROR check but didn't check for WSA_E_NO_MORE specifically – so the loop ran forever. The exact trigger: a network service discovery app that looked for printers on a domain. After finding the last printer, the next call threw this error.

Fix steps – numbered

1. Stop calling WSALookupServiceNext when you get WSA_E_NO_MORE. Check the return value. If it's SOCKET_ERROR, call WSAGetLastError(). If the last error equals WSA_E_NO_MORE, break out of your loop.
2. Call WSALookupServiceEnd after the loop. This releases the handle. Without it, you leak resources. The reason step 3 works is that WSALookupServiceEnd tells the service provider you're done. Then any future WSALookupServiceBegin will start fresh.
3. Reset the dwSize field in WSAQUERYSET before each WSALookupServiceNext call. The function needs the correct buffer size. Set dwSize to the size of your buffer before each call. Many devs set it once and reuse – that breaks the second call.
4. Handle WSAEFAULT separately. If the buffer is too small, WSALookupServiceNext returns WSAEFAULT and sets dwSize to the needed size. Allocate a bigger buffer and retry. Don't confuse this with WSA_E_NO_MORE.
5. Check your service class GUID. If you're looking for a service that doesn't exist on the network, WSALookupServiceBegin may succeed (returning a handle) but the first call to WSALookupServiceNext will return WSA_E_NO_MORE immediately. That's correct behavior – your query matched nothing.

Alternative fixes – if the main one fails

• Use WSALookupServiceBegin with LUP_RETURN_NAME and LUP_RETURN_ADDR flags only. If you request too many details (like LUP_RETURN_BLOB), some providers fail early. Remove unnecessary flags. Test with minimal flags first.
• Restart the Windows Sockets service. Open Command Prompt as admin and run:

  net stop winsock
  net start winsock

  Then restart your app. This resets the service provider state. Rarely needed, but works when a previous query left a corrupted handle.
• Switch to WSASetService for registration. If you're the one publishing the service, make sure you call WSASetService with RNRSERVICE_REGISTER. If the service isn't registered, WSALookupServiceNext will find nothing. Double-check your service name and GUID match on client and server.
• Upgrade your Winsock DLL. On older systems (Windows 7, Server 2008 R2), a bug in mswsock.dll can cause WSA_E_NO_MORE even with correct code. Install the latest Windows update or run sfc /scannow to repair system files.

Prevention tip

Always pair WSALookupServiceBegin with WSALookupServiceEnd. Write a helper function that loops safely: check the return code, break on WSA_E_NO_MORE, reset dwSize each iteration, and always call WSALookupServiceEnd on exit – even if an error happens. That single pattern prevents 90% of these errors.