Why does an RPC event show a UUID instead of a name?

RPC identifies interfaces by a UUID and procedures by a number, not by name. Without a lookup database those identifiers cannot be mapped back to readable names. RpcViewer resolves them using an RPC interface database it can build from PE files on your system.

How do I build the RPC interface database?

In RpcViewer, use the RPC database manager to scan folders you specify. It extracts RPC interface definitions from PE files in those folders and saves them to a database stored alongside the executable. Captured events then show resolved service and procedure names.

Can I resolve names for my own RPC services?

Yes. Point the database scan at the folders that contain your own DLLs and executables. RpcViewer extracts their RPC interface definitions so your custom interfaces and procedures appear by name instead of as raw UUIDs.

Resolve RPC Interface UUIDs to Service and Procedure Names

RPC Interface Database

Turn interface UUIDs and procedure numbers into readable names.

RPC does not identify interfaces by name. On the wire an interface is a UUID and a procedure is a number, so a raw capture shows rows like a GUID and Proc# 7 with no hint of what they do. RpcViewer closes that gap with an RPC interface database that maps those identifiers back to human-readable service and procedure names.

Download RpcViewer (free)

How Resolution Works

When RpcViewer displays an event, it looks up the interface UUID and procedure number in its database and fills in the Service, Module, and Function columns. The more complete the database, the more of your capture reads as names instead of GUIDs, which makes filtering and highlighting far more useful because you can target a service by name.

RpcViewer scanning system folders to build the RPC interface database — Scanning folders to extract RPC interface definitions into the database.

Build or Update the Database

Open the RPC database manager and point it at the folders you want covered. RpcViewer scans the PE files in those folders, extracts the RPC interface definitions they contain, and saves the result to a database stored next to the executable. You can rescan whenever you add new binaries or want to widen coverage.

Good folders to scan include the Windows system directories for built-in services, plus the install or build output folders for any product whose RPC interfaces you want to read by name.

Resolve Your Own Services

The same scan works for code you build. Point it at the folders that hold your DLLs and executables and RpcViewer will extract their interface definitions, so your own RPC services show up with real interface and procedure names while you debug them. That is often the difference between guessing which call failed and seeing it directly.

Frequently Asked Questions

Why does an RPC event show a UUID instead of a name?: RPC identifies interfaces by a UUID and procedures by a number, not by name. Without a lookup database those identifiers cannot be mapped back to readable names. RpcViewer resolves them using an RPC interface database it can build from PE files on your system.
How do I build the RPC interface database?: In RpcViewer, use the RPC database manager to scan folders you specify. It extracts RPC interface definitions from PE files in those folders and saves them to a database stored alongside the executable. Captured events then show resolved service and procedure names.
Can I resolve names for my own RPC services?: Yes. Point the database scan at the folders that contain your own DLLs and executables. RpcViewer extracts their RPC interface definitions so your custom interfaces and procedures appear by name instead of as raw UUIDs.