Fix RPC_S_NO_MORE_MEMBERS (0X000006DD) in 3 Steps
You see this error when Windows can't find more members in a group or domain. It's usually a DNS or LDAP lookup problem. Here's how to fix it fast.
What This Error Actually Means
You're trying to list or use members of a group (like a domain group or a local group) and Windows says RPC_S_NO_MORE_MEMBERS (0X000006DD). Translation: the system can't find any more members to return. This happens when a group lookup hits a dead end — maybe the group is empty, or more likely, the lookup failed partway through.
I see this most often on domain-joined machines when querying a domain group's members. The client sends an LDAP request to the domain controller, but the DC can't resolve the group's members because of a DNS problem or a stale member that points to a deleted object. Another scenario: you're running net localgroup Administrators and it throws this error.
Start with the quickest fix. If it doesn't work, move down the list.
Step 1 — The 30-Second Fix: Flush DNS and Clear Group Cache
This is stupid simple but fixes maybe 40% of cases. Open Command Prompt as Administrator and run:
ipconfig /flushdns
Then restart the service that's failing (like File Explorer or your app). If you're in PowerShell, you can also clear the Windows group membership cache with:
Clear-DnsClientCache
What's happening: Windows caches DNS lookups for domain controllers and group members. If that cache is stale — pointing to a DC that's down or a group that changed — the RPC call fails with this error. Flushing clears the bad data.
If the error came from a specific tool like dsquery or ADUC, close and reopen it. That forces a fresh LDAP bind. I've had this fix work on Windows Server 2016 and 2019 when the error popped up after a network change.
Still broken? Move to Step 2.
Step 2 — The 5-Minute Fix: Check Group Membership for Stale Objects
The error means the system ran out of members to return. But sometimes it runs out because it hit a dead member — an object that no longer exists in Active Directory or the local SAM. This is common with migrated domains or after cleaning up old accounts.
If you're working with a local group (like Administrators), run:
net localgroup Administrators
Look for any member that shows as S-1-5-21-... (a SID) instead of a name. That's a dead member pointing to an object that's been deleted. Remove it with:
net localgroup Administrators S-1-5-21-xxx /delete
Replace the SID with the one you see. Then try your operation again.
For domain groups, use Active Directory Users and Computers (ADUC). Open the group's properties, go to Members tab, look for any member with a red X or missing name. Remove it. If ADUC itself shows the error, use PowerShell instead:
Get-ADGroupMember "YourGroup" | ft name, objectClass
This command often returns partial results and shows you which member is causing the hang. The error might show for a specific member that's a foreign security principal from a trusted domain that's no longer reachable. Remove that member.
The reason step 2 works: The RPC call iterates through members until it finds one it can't resolve. Then it stops and throws 0X000006DD. By removing the dead member, the iteration completes successfully.
Still failing? Go to Step 3.
Step 3 — The 15+ Minute Fix: Fix DNS and LDAP Connectivity to Domain Controllers
If Steps 1 and 2 didn't help, the problem is almost certainly DNS or LDAP. The error code 0X000006DD is RPC's way of saying "I asked the DC for more members, but it gave me nothing." That nothing can be a timeout or a bad referral.
First, verify your DNS points to the right DC. On the affected machine, run:
nslookup yourdomain.local
If it returns multiple IPs, check that all are reachable. If any DC is offline, the client might try it and timeout, causing the error. Remove stale DNS records for dead DCs.
Next, test LDAP connectivity:
nltest /dsgetdc:yourdomain.local
This shows which DC the machine is actually talking to. If it's a DC far away or with high latency, that can cause the timeout. Force a specific DC with:
nltest /dsgetdc:yourdomain.local /force
If that fails, check your firewall. LDAP uses port 389 (636 for LDAPS), and RPC end point mapper uses port 135. But the real issue is often that the DC's RPC services aren't responding. Restart the Remote Procedure Call (RPC) service on the DC that's being contacted. But do this during a maintenance window — it'll disconnect some things briefly.
Also check if the group you're querying is a distribution group instead of a security group. Some tools (like net localgroup) can't enumerate distribution group members. If you're hitting a distribution group with a security group tool, the error makes sense. Check the group type in ADUC.
Finally, if you're on a Windows 10/11 machine trying to enumerate domain groups, make sure the machine can resolve the domain's Global Catalog (port 3268). LDAP queries for group membership sometimes go through GC. Run:
nltest /dsgetdc:yourdomain.local /gc
If that fails, your machine can't find a GC, and group enumeration will fail with this error. Configure DNS to point to a GC server (usually the same DCs).
When You Should Just Reboot
I know it's cliché, but if none of these steps work and the error is sporadic, reboot both the client and the DC. Sometimes the RPC subsystem gets into a weird state — especially after a security update. A clean start resets all RPC endpoints and clears any internal state that's stuck. I've seen this fix it on Server 2012 R2 after a patch Tuesday.
If the error happens constantly, check the DC's event log for Event ID 5719 or 5807. Those indicate authentication or DNS failures that cause this RPC error. Fix those root issues and the error goes away.
Was this solution helpful?