If you receive RPC server is unavailable message, then this post shows how to troubleshoot Remote Procedure Call failed errors & problems on Windows 10. RPC or Remote Procedure Call is a network-based programming model which allows point-to-point communications between software applications. In this guide, we will share how to troubleshoot Remote Procedure Call errors. The errors can happen while connecting to Windows Management Instrumentation (WMI), SQL Server, during a remote connection, or for some Microsoft Management Console (MMC) snap-ins.
Troubleshoot Remote Procedure Call errors
“RPC server is unavailable” is one of the most common issues that occur. It could be a simple network issue, or the server is not up to respond. Let’s take a look at the list of tools which we can use to troubleshoot remote procedure call errors. You can either use PowerShell or Command Prompt with admin privileges to run these commands.
You will have to use Microsoft Network Monitor or Microsoft Message Analyzer to analyze logs.
PortQuery
This tool helps you figure out the problem with the port you are trying to connect. It can determine if your application or computer can connect to the server.
Portqry.exe -n <ServerIP> -e 135
The above command tries to query TCP port 25 on the give Server IP. If you use a website here, it will translate to the IP address internally. In the output, look for *ip_tcp, and port number. If the connection fails, you should see a failed response in return. If everything looks fine, look for a port number (marked in bold) at the end which should look like
….Server’s response: UUID: d95afe70-a6d5-4259-822e-2c84da1ddb0d ncacn_ip_tcp:169.254.0.10[49664]
If you don’t see any port number, it means something is wrong on the server end, and the port is not listening.
Netsh
Next, you can use the Netsh command to collect simultaneous trace data. TRACE here means path from one point to another on a network. If there is anything that is causing a problem in between, you will know.
On the client run:
Netsh trace start scenario=netconnection capture=yes tracefile=c:client_nettrace.etl maxsize=512 overwrite=yes report=yes
On the Server run:
Netsh trace start scenario=netconnection capture=yes tracefile=c:server_nettrace.etl maxsize=512 overwrite=yes report=yes
The above command keeps a log in a tracefile(.etl). Keep this window of Command Prompt ready.
Now try to reproduce the issue you had been facing on the client machine. You may have to press some buttons on the software or anything that was causing a problem for you. As soon as you see the issue, run Netsh trace stop on the Command Prompt of the client machine.
Now use the analyser tool and filter the trace for
- Ipv4.address== and ipv4.address== and tcp.port==135 or just tcp.port==135.
- Also, look for the “EPM” Protocol Under the “Protocol” column.
Now check if you get a response from the server. If you get a response, note the dynamic port number that you have been allocated to use.
- Check if you can connect successfully to this Dynamic port successfully.
- The filter should be something like this: tcp.port== and ipv4.address==
It should help you verify the connectivity and isolate if any network issues there.
Port not reachable
The most common reason why we would see the RPC server unavailable is when the dynamic port that the client tries to connect is not reachable. If you see trace breaking in between, returning with the port not found an error, and so on, then it could be because of following possible reasons
- The Firewall has blocked the dynamic port range.
- A router or a network device in the middle is dropping the packet; the response is not coming back.
- The destination server is dropping the packets (WFP drop / NIC drop/ Filter driver etc.).
The best practice for Post not reachable issue is using dynamic allocation. The registry allows admins to configure RPC dynamic port allocation.
These tools and tips help you analyze and figure out the problem. The solution will depend on what exactly is the problem and will depend on the software and the server.