Advanced Local Procedure Call, commonly abbreviated ALPC, is the internal interprocess communication facility that the Windows kernel has provided since Windows Vista and Windows Server 2008. It replaced the older Local Procedure Call mechanism that dated back to the earliest releases of Windows NT, and it serves as the low level transport on which nearly every local conversation between Windows components ultimately rides. When the Local Security Authority Subsystem Service validates a credential, when the Desktop Window Manager receives redraw instructions, when the Service Control Manager starts a background service, or when a Win32 application talks to the Client Server Runtime Subsystem, the bytes cross process boundaries through ALPC ports. Although Microsoft never documented ALPC as a public programming interface, its design shapes the performance and security posture of the entire operating system, and a large body of independent research, most notably the reverse engineering work published in Windows Internals and by kernel researchers, has made its behavior well understood.
Origins and the Transition From LPC to ALPC
The original Local Procedure Call facility was a message passing system built around ports, sections, and a small set of native system calls. It worked, but it suffered from real limitations that became more visible as Windows grew. LPC copied message data through a fixed pattern of port messages and shared memory windows, and large transfers required careful manual choreography between client and server. More importantly, LPC offered little in the way of garbage collection for orphaned resources, and its synchronous call model meant that a blocked or hung client could stall threads inside critical system processes. Security researchers also found that the LPC connection handshake, which relied on object handles being passed in loosely structured ways, created opportunities for impersonation confusion and spoofing of server identities.
Microsoft addressed these problems in the Windows Vista release by rewriting the mechanism and renaming it ALPC. The redesign was not merely cosmetic. ALPC introduced a proper message queuing model, kernel managed message attributes, reference counted buffer tracking, and an asynchronous completion model integrated with I/O completion ports. The port object itself became a fully featured executive object type with fine grained access rights. The goals of the rewrite, as described by Microsoft engineers in books and conference material from that period, were higher throughput, better scalability on multiprocessor machines, tighter control over who may connect to whom, and cleaner cleanup when a side of a conversation disappears unexpectedly.
The transition was transparent to application programmers because both LPC and ALPC sit beneath higher level abstractions. Remote Procedure Call over local transport, documented Win32 APIs that communicate with services, and undocumented subsystem calls all continued to function, internally rebound to the new primitives. By the time Windows 7 shipped, ALPC had become firmly established, and every subsequent release, including Windows 8, Windows 10, Windows 11, and the corresponding server editions, has continued to rely on it.
Port Objects, Connection Semantics, and Message Structure
ALPC is organized around port objects of three kinds. A connection port is created by a server with NtAlpcCreatePort and given an object manager name, which places it in the kernel object namespace where clients can find it. A client connects with NtAlpcConnectPort, optionally passing connection attributes and a short initial message, and receives a handle to a client communication port. After the handshake completes, both the client port and the server side communication port can exchange messages in either direction, so ALPC conversations are inherently bidirectional once established.
Each message consists of a fixed header followed by an optional data payload. The header carries the message type, such as request, reply, connection request, or datagram, plus length fields and port message bookkeeping inherited in spirit from the LPC design. Payload data up to a moderate threshold can travel inline through the port queue, where the kernel copies it between address spaces on behalf of the participants. Above that threshold, ALPC uses its view and section machinery, described in the next section, so that large payloads bypass repeated copying entirely.
Messages also carry typed attributes, a feature that did not exist in the old LPC world. Attribute blocks can convey context information, views, handles, security information, and continuation data, each flagged with a known type identifier. The kernel validates attribute layouts and enforces which attributes a sender is permitted to supply, which closes entire categories of confusion attacks that plagued earlier local communication. This attribute system also gives the mechanism extensibility: newer Windows releases have added attributes without changing the fundamental port contract.
Shared Sections and Efficient Large Data Transfer
When a conversation needs to move more data than fits comfortably in an inline port message, ALPC falls back on a section based transfer scheme that closely resembles shared memory. The server or the client creates a section object backed by the paging file and then registers it with the port as a port section using NtAlpcCreatePortSection. Both sides map views of that section into their address spaces with NtAlpcCreateSectionView, after which either party can write large buffers into the shared region and signal message identifiers through the port queue. The kernel only moves the small headers; the bulk data stays resident in the shared mapping.
This division of labor is the reason ALPC scales from tiny control messages to multi megabyte payloads without architectural strain. The port queue provides ordering, synchronization, and delivery guarantees, while the section provides raw capacity. The design also avoids the repeated double copying that naive message systems perform, because the shared memory pages are mapped into both processes simultaneously and require no intermediate kernel buffer for the payload itself.
Resource discipline matters here, and ALPC enforces it through the same object lifetime rules that govern the rest of the executive. Sections and views are reference counted, and closing the last handle releases the underlying memory. When a process exits or crashes, the kernel rundown routine for the port dissolves pending messages, cancels outstanding waits, and frees associated allocations, so a malfunctioning client cannot permanently pin memory owned by a server such as LSASS. This automatic rundown behavior, which the old LPC model handled less rigorously, is one of the quiet reliability improvements that the Vista era rewrite delivered.
Synchronous and Asynchronous Operation
ALPC supports both blocking call semantics and fully asynchronous message processing, and the choice between them is made per message rather than per port. A synchronous request blocks the calling thread until the server replies, which suits simple request response exchanges such as an authentication query. An asynchronous message is posted to the port queue and completed later, either through an explicit wait on a different call or, more powerfully, through integration with I/O completion ports created by NtAlpcCreateResourceReserve compatible workflows and the NtAlpcSetInformation function that binds a port to a completion context.
The asynchronous path matters enormously for system services that must handle thousands of concurrent clients without dedicating a thread to each one. The Desktop Window Manager, for instance, receives a continuous stream of window composition updates from every graphical process on the machine. Handling those updates through completion ports lets DWM use a small pool of worker threads that pull finished requests from the queue in order of completion, which keeps latency low and prevents any single misbehaving application from monopolizing server threads.
Thread pool and waiting infrastructure in user mode understands ALPC completion as a first class event source. Together these facilities give ALPC throughput characteristics that compare favorably with sockets or named pipes for local traffic, which explains why Microsoft chose it as the substrate for its most latency sensitive internal channels.
Security Model, Impersonation, and Connection Guarding
Because ALPC links processes that often run at different privilege levels, its security model had to be designed from the foundation. Every connection request is subject to a discretionary access check against the security descriptor on the connection port, and servers can further inspect prospective clients by examining the process identifier and the client security context delivered in the connection message. A server may accept or reject each connection individually with NtAlpcAcceptConnectPort, and it can refuse based on any criterion it can evaluate, including the client image path or signature.
Impersonation is handled with explicit impersonation messages that propagate a copy of the client token to the server thread handling the request, much as named pipes do at the Win32 layer. The quality of service settings attached to the port constrain what level of impersonation the client permits, so a careful client can prevent a server from using its identity beyond simple identification. This protects against a malicious server escalating borrowed credentials, a scenario that was a recurring source of elevation of privilege findings in earlier Windows versions.
Tight access control on ALPC ports also turned out to be a genuine security battleground after Vista shipped. Vulnerability research repeatedly found system services that created connection ports with overly permissive security descriptors, letting unprivileged processes invoke powerful server functions. Several known local privilege escalation techniques exploited exactly this weakness, which pushed Microsoft to audit named ports across Windows. The lesson generalizes to anyone designing an ALPC based service: the port is a security boundary and must be treated like a network listener.
ALPC in Core Windows Services
The practical importance of ALPC is easiest to appreciate through the services that depend on it. LSASS, the Local Security Authority Subsystem Service, exposes well known ALPC ports through which logon packages, authentication protocols, and client applications negotiate credentials and tokens. When an application calls LogonUser or requests a Kerberos ticket, the request crosses into LSASS through an ALPC exchange, and the asynchronous machinery keeps the security process responsive even under heavy authentication load. Because LSASS holds secrets, the access checks on its ports are among the most restrictive in the system.
The Desktop Window Manager maintains ALPC conversations with every process that owns visible windows. Composition data, redraw scheduling, and certain input routing notifications flow across these ports. The Service Control Manager similarly relies on ALPC for its command channel: when an administrator or a tool issues StartService, the SCM receives the control message through its RPC interface, but its internal coordination with service host processes and status reporting lean on local kernel messaging of this family. The Win32 subsystem communication between applications and the Client Server Runtime Subsystem process, where console handling and legacy subsystem work still live, also travels over ALPC endpoints created at session initialization.
Beyond these headline consumers, RPC itself maps its local protocol sequence onto ALPC, meaning that countless components that think of themselves as RPC clients are in fact ALPC users underneath. Debugging tools such as Process Explorer and Process Monitor can reveal port objects, and the Windows Driver Kit documentation for kernel filter components references ALPC as the approved channel for communication between kernel minifilters and user mode services. From the first boot of the wininit and smss startup chain through the steady state of a busy desktop session, ALPC traffic never stops, which is why understanding it is essential for anyone studying Windows internals, diagnosing system performance, or auditing the attack surface of local services.