Skip to main content

Command Palette

Search for a command to run...

Windows Remote Procedure Calls (RPC): How Programs Communicate

Updated
7 min readView as Markdown
S
Computer Science student focused on systems programming, Linux, cybersecurity, and software development. I write technical articles and build projects to deepen my understanding of computer systems while documenting my learning journey.

Modern Windows systems are made up of many different processes and components.

These components often need to communicate with one another.

But how can one process request another process to perform an operation?

One important answer is Remote Procedure Call, or RPC.

What Is RPC?

Remote Procedure Call (RPC) is a communication mechanism that allows a program to request a function or operation from another process or system.

The important idea is:

A program can request an operation from another program without directly managing how that operation is performed.

The other program receives the request, performs the operation, and returns a result.

A simplified model is:

Client
  ↓
RPC Request
  ↓
RPC System
  ↓
Server
  ↓
Operation
  ↓
Response
  ↓
Client

Why Is RPC Useful?

Programs are often separated into different processes for security, reliability, or architectural reasons.

RPC provides a structured way for these components to communicate.

It can be used for:

  • Windows system services

  • Enterprise applications

  • Distributed applications

  • Network services

  • Administrative operations

  • Communication between Windows components

Local RPC vs Remote RPC

Despite its name, RPC does not necessarily mean communication across the Internet.

RPC can happen between processes on the same computer.

It can also happen between different computers over a network.

Local RPC:

Process A
   ↓
Process B

or:

Remote RPC:

Computer A
Process A
   ↓
 Network
   ↓
Computer B
Process B

Client and Server

RPC communication usually involves two sides.

Client

The client requests an operation.

Server

The server receives the request and performs the operation.

For example:

Client Process
      │
      │ Request
      ↓
Server Process
      │
      │ Result
      ↓
Client Process

The terms "client" and "server" describe their roles in the communication rather than necessarily referring to separate physical computers.

RPC Stubs

RPC frameworks commonly use stubs to help translate between normal function calls and messages sent between processes.

A simplified model is:

Client Application
       ↓
Client Stub
       ↓
RPC Runtime
       ↓
Network / IPC
       ↓
RPC Runtime
       ↓
Server Stub
       ↓
Server Application

The stubs help package the function arguments and interpret the returned data.

Marshalling and Unmarshalling

When information needs to cross a process or machine boundary, it needs to be represented in a form that can be transferred.

This process is commonly called marshalling.

The receiving side performs the reverse process, often called unmarshalling.

Conceptually:

Function Arguments
       ↓
   Marshalling
       ↓
Communication
       ↓
 Unmarshalling
       ↓
Server Function

This allows structured data to travel between the client and server.

RPC Runtime

The RPC runtime provides infrastructure that helps manage RPC communication.

It can handle tasks such as:

  • Communication

  • Data transfer

  • Endpoint handling

  • Serialization-related work

  • Request and response processing

Applications generally interact with RPC through APIs and generated interfaces rather than implementing all of this infrastructure themselves.

Microsoft RPC

Windows provides an implementation commonly known as Microsoft RPC (MSRPC).

It is widely used by Windows components and applications.

Windows RPC can operate through different communication mechanisms depending on the situation.

RPC and Windows Services

RPC is closely connected to many Windows services.

A service may expose functionality that other processes can request through RPC.

For example:

Application
      ↓
RPC Request
      ↓
Windows Service
      ↓
Operation
      ↓
Response

This architecture allows applications to interact with system services without directly accessing their internal implementation.

RPC Endpoints

An RPC server needs a way for clients to locate and communicate with it.

This involves an endpoint.

An endpoint identifies where RPC communication can be delivered.

Conceptually:

RPC Server
    ↓
Endpoint
    ↓
Client Connection

Depending on the RPC configuration, endpoints can involve mechanisms such as named pipes or network ports.

RPC Endpoint Mapper

Windows includes an RPC Endpoint Mapper that helps clients discover endpoints for RPC interfaces.

The general idea is:

Client
  ↓
Endpoint Mapper
  ↓
"Where is this RPC interface?"
  ↓
RPC Server Endpoint
  ↓
Communication

This becomes particularly important in distributed Windows environments.

RPC and Security

RPC communication needs to be protected.

Windows can use security mechanisms to control:

  • Who can connect

  • Which operations are allowed

  • How identities are authenticated

  • How communication is protected

A service should not assume that every client is trusted.

Security checks are therefore an important part of RPC-based architectures.

RPC and Authentication

Windows RPC can integrate with Windows authentication mechanisms.

The identity of the client can be available to the server, allowing the server to make authorization decisions.

A simplified flow is:

Client
  ↓
Authentication
  ↓
RPC Server
  ↓
Authorization
  ↓
Allow / Deny

This connects RPC with concepts such as access tokens, users, groups, and privileges.

RPC and Windows Internals

RPC connects several Windows concepts we've already studied:

User / Process
       ↓
Windows API
       ↓
RPC
       ↓
Service / Server Process
       ↓
Kernel / System Resources

Understanding RPC therefore helps explain how Windows components communicate without directly sharing their internal memory or implementation.

RPC in Malware Analysis

RPC is important during malware analysis because malicious programs may communicate with Windows services or other processes using legitimate Windows communication mechanisms.

An analyst may investigate:

  • Which RPC interfaces a process interacts with

  • Which services receive requests

  • Which endpoints are contacted

  • What security context is involved

  • Whether unusual RPC activity occurs

However, RPC usage by itself is not evidence of malware.

Windows relies heavily on RPC for legitimate system functionality.

RPC and Lateral Movement

RPC can also appear in network-based attacks because Windows systems commonly use RPC-related services for remote administration and management.

Security analysts therefore monitor unusual RPC activity across systems.

For example:

Computer A
    ↓
RPC Communication
    ↓
Computer B

Unexpected communication between systems can become an important investigation clue.

RPC vs Shared Memory

RPC and shared memory are both forms of inter-process communication, but they work differently.

Feature RPC Shared Memory
Basic idea Request an operation Share a memory region
Communication Messages / requests Common memory
Same computer Yes Yes
Network communication Yes Generally local
Synchronization Often handled through communication model Usually requires synchronization
Common use Services and distributed systems High-speed local data sharing

RPC vs Direct Function Calls

A normal function call might look like:

Function
   ↓
Same Process

RPC is different:

Client Process
      ↓
RPC
      ↓
Other Process

The function being requested belongs to another execution context.

A Simple Analogy

Imagine ordering food at a restaurant.

You don't enter the kitchen and prepare the food yourself.

Instead:

Customer
   ↓
Order
   ↓
Waiter
   ↓
Kitchen
   ↓
Food
   ↓
Customer

The customer is the client.

The kitchen is the server.

The order is the RPC request.

The completed food is the response.

Final Thoughts

Remote Procedure Calls provide a structured way for processes and systems to request operations from other processes or systems.

Remember:

Client → RPC Request → Server → Operation → Response

Important concepts include:

  • Client and server

  • RPC runtime

  • Stubs

  • Marshalling

  • Endpoints

  • Endpoint Mapper

  • Authentication

  • Authorization

RPC is deeply integrated into Windows and is an important part of understanding how Windows components communicate.

In the next article, we'll explore Windows APIs and System Calls and see how applications move from high-level programming interfaces toward the operating system itself.

Windows Internals: The Architecture Behind Windows

Part 12 of 16

Go beyond the graphical interface and explore what really happens inside the Windows operating system. This series dives into the internal architecture and mechanisms that make Windows work—from processes, threads, memory management, and system calls to Windows APIs, the Registry, access tokens, security mechanisms, objects, handles, drivers, and kernel components. Instead of treating Windows as a black box, we'll break down what happens underneath the surface and understand how different components interact with each other. Whether you're interested in operating systems, cybersecurity, malware analysis, reverse engineering, or low-level programming, this series provides a structured journey into the inner workings of Windows. Learn Windows. Understand the internals. See what happens beneath the surface.

Up next

Windows APIs and System Calls: How Applications Reach the Operating System

When a Windows application wants to perform an operation, it cannot simply control the operating system directly. For example, an application may want to: Create a process Open a file Allocate memo

Windows RPC Explained | Remote Procedure Calls in Windows