The Depths of Windows I/O (Part 1) — Every Read and Write Becomes an IRP: The Big Picture of the I/O System

A single line of File.ReadAllText, or one call to ReadFile. What happens inside Windows between the moment you call the function and the moment it returns?

Open Process Monitor to chase down a bug and unfamiliar terms like IRP_MJ_READ and FASTIO_READ line up in front of you. Track down a handle leak and a file you were sure CloseHandle had dealt with is still alive. “It behaves differently on a network drive.” “It’s only slow on machines with antivirus software installed.” These phenomena, which come up again and again on the front lines of business applications, all happen on the same ground: the Windows I/O system.

This article opens a series, “The Depths of Windows I/O”, that digs into that ground from the bottom up. Just as the celebrated book Windows Internals (the Japanese edition is titled Inside Windows) goes all the way down to the kernel’s design to explain it, this series is not about “how to use the API” but about “why it behaves the way it does”.¹ Here is the planned line-up:

1. The Big Picture of the I/O System — Every Read and Write Becomes an IRP (this article)
2. Synchronous and Asynchronous I/O — What OVERLAPPED Really Means
3. I/O Completion Ports (IOCP) and the .NET Thread Pool — The Basement Under async/await
4. The Cache Manager — When Does Your WriteFile Actually Reach Disk?
5. Inside NTFS — Understanding the File System Through the MFT
6. Filter Drivers and Minifilters — Why Procmon and Antivirus Scanners Can Intercept Your I/O

This first instalment lays out, with diagrams, the cast of characters and the flow of a request that every later instalment builds on. It is not an article about writing drivers. It is an article for letting application developers follow the API call they just made all the way to its destination.

Prerequisites: you can follow this article if you have used FileStream in C#, or called CreateFile/ReadFile in C/C++. No driver-development experience is required, and kernel-side code appears only as conceptual illustration. As a rough reading time, budget about 25 minutes to go through it in full while looking at the diagrams, or 2–3 minutes if you only want the bottom line of Section 1.

A guide for skipping ahead: this is long, so here are entry points by purpose.

• Just want the big picture → Section 1 (the bottom line) → Section 2 (name resolution) → Section 5 (one round trip of ReadFile)
• Want the terminology sorted out (driver/device/file object, IRP) → Sections 3 and 4
• Want to understand how things break in practice (handle leaks, “file in use”) → Section 6
• Want to try it yourself → Section 7

1. The Bottom Line First

• Windows I/O is packet-driven. Most requests sent to a device driver are packed into a packet called an IRP (I/O Request Packet) and flow from top to bottom down a stack of drivers (the device stack).²³
• CreateFile doesn’t necessarily open a “file”. Name resolution happens in the Object Manager namespace, and C: is, underneath, a symbolic link to an NT device name such as \Device\HarddiskVolume3 (Section 2).⁴⁵
• There are three characters in this story. The driver object, which holds a table of handler functions; the device object, which is the destination of a request; and the file object, which holds the state of one particular open. The HANDLE you hold is a reference to a file object (Section 3).⁶⁷⁸⁹
• Each driver has only three choices. Complete the IRP itself, pass it down to the driver below, or hold it pending and complete it later. This combination of three choices explains filter drivers, caching, and asynchronous I/O all at once (Section 4).³¹⁰
• There is no separate mechanism called “synchronous I/O” down at the bottom of the kernel. Synchronous I/O is really just the guarantee “the call does not return before completion”; waiting only happens when a request goes pending. This is where the doors to Part 2 and Part 3 open (Section 5).¹¹
• CloseHandle doesn’t mean “close” — it means “return one handle”. There are two stages: cleanup, when the last handle closes, and close, when every reference inside the kernel has also vanished. That gap is exactly why a file can say “in use” after you thought you had closed it (Section 6).¹²¹³
• You can observe this layer yourself. WinObj shows you the namespace, and Process Monitor shows you the flow of IRPs. Procmon’s own vocabulary is the vocabulary of this article (Section 7).¹⁴

2. What “Everything Looks Like a File” Really Means

2.1. Where Does the Name You Pass to CreateFile Go?

Every Win32 file API begins with a “name”. A path like C:\project\report.csv, a UNC path like \\server\share\data.csv, a device designation like \\.\COM3 — all of these can be passed to the very same CreateFile.¹⁵

Behind this consistency lies a single namespace managed by the kernel’s Object Manager. Inside the kernel, devices, events, and shared-memory sections alike are all registered as “objects” in this tree-shaped namespace. Sysinternals’ WinObj lets you look straight into this namespace.¹⁴

flowchart TB
    ROOT["\ - root of the namespace"]
    DEV["\Device<br/>device objects created by drivers"]
    GLB["\GLOBAL??<br/>where the globally visible names Win32 sees live"]
    BNO["\BaseNamedObjects<br/>named mutexes and the like"]
    ROOT --> DEV
    ROOT --> GLB
    ROOT --> BNO
    DEV --> D1["HarddiskVolume3"]
    DEV --> D2["Serial0"]
    DEV --> D3["Mup - network redirector"]
    GLB --> L1["C: -> \Device\HarddiskVolume3"]
    GLB --> L2["COM1 -> \Device\Serial0"]
    GLB --> L3["PhysicalDrive0 -> \Device\Harddisk0\DR0"]

Figure 1: The Object Manager namespace (excerpt). What lives under \GLOBAL?? are symbolic links; the real objects live under \Device

The key point is that the names a Win32 application uses (drive letters, COM port names) and the names the kernel uses (NT device names) live in different tiers. Symbolic links are what connect the two.

2.2. A Drive Letter Is a Symbolic Link

When a driver wants its device to be visible from Win32 applications, it calls IoCreateSymbolicLink to create a symbolic link from an MS-DOS device name, such as \DosDevices\COM1, to an NT device name.⁴ C: works the same way — underneath, it is a link to a volume device such as \Device\HarddiskVolume3.

So name resolution for CreateFile("C:\project\report.csv") proceeds like this:

flowchart TB
    A["Name passed by the app<br/>C:\project\report.csv"]
    B["Win32 layer converts it to NT form<br/>\??\C:\project\report.csv"]
    C["Object Manager searches the namespace<br/>and finds \??\C: is a symbolic link"]
    D["Follows the link and substitutes it<br/>\Device\HarddiskVolume3\project\report.csv"]
    E["\Device\HarddiskVolume3<br/>reaches the volume's device object"]
    F["Resolving the remaining \project\report.csv is left<br/>to the file system driver, NTFS -<br/>the I/O manager issues IRP_MJ_CREATE"]
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

Figure 2: Name resolution for CreateFile. The first half is the Object Manager’s job; once a device is reached, the second half becomes the file system’s job

This picture answers a few questions that come up all the time.

• What the \\.\ prefix means. The \\.\ in \\.\PhysicalDrive0 or \\.\COM10 is notation for pointing directly at the Win32 device namespace (roughly the \?? directory). It skips the drive letter and names the location of the link directly.⁵¹⁵
• Why CON and NUL can’t be used as file names. They are reserved as MS-DOS device names, and wherever they appear in a path they can be resolved to the device side instead.⁵ The practical pitfalls around this are collected in “MAX_PATH and Windows Path/Filename Pitfalls”.
• UNC paths aren’t a special case either. \\server\share resolves to the network redirector’s device (\Device\Mup), and from there the SMB client carries the request across the network. The root cause of behaviour differing between local paths and UNC paths is that the device it resolves to is different (see “Pitfalls of Network Drives and UNC Paths”).

To be precise, \?? is not really an alias for one physical directory — it is a virtual entry point representing a lookup order: “first check the per-logon-session local DOS device map, and if it isn’t there, fall through to \GLOBAL??”. Drive letters created with net use or subst land in that local side, which is why the same PC can show different drives to different users (logon sessions), and why a service cannot see a user’s mapped network drives. Figure 1 above shows only the global side (\GLOBAL??).

In other words, the precise way to say “on Windows, everything looks like a file” is this: every name is ultimately resolved to a device object, and every request from that point on is unified into the same format — the IRP. So what exactly is that device object? Let’s sort out the cast of characters.

3. The Cast Is Three Objects

The structure of the Windows I/O system can be drawn as a relationship among three kinds of kernel objects.

Technical terms are about to pile up. So that you don’t get lost, here is a translation table up front, mapping “what you see in the code you normally write” to “what the kernel calls it”. Sections 3 and 4 are written in the vocabulary of the right-hand column.

3.1. The Driver Object — A Table of Handler Functions

When a driver is loaded, the I/O manager creates a driver object (DRIVER_OBJECT) to represent it.⁶ From an application developer’s point of view, the most important member is the MajorFunction array — a table mapping “request type” to “handler function”, where the request type is expressed by a major function code such as IRP_MJ_CREATE (open), IRP_MJ_READ (read), IRP_MJ_WRITE (write), IRP_MJ_CLEANUP, or IRP_MJ_CLOSE.¹⁶

Forcing it into C#, the picture looks roughly like this:

// Conceptual illustration. In reality this is a C struct inside the kernel
class DriverObject
{
    // Indexed by IRP_MJ_XXX. 28 kinds in total
    public DispatchRoutine[] MajorFunction = new DispatchRoutine[28];
}
// For ntfs.sys, MajorFunction[IRP_MJ_READ] holds "NTFS's read handler"

3.2. The Device Object — The Destination of a Request

For every device it looks after, a driver creates a device object (DEVICE_OBJECT).⁷ This is the destination of an I/O request. It isn’t necessarily one-to-one with a physical device — it can be a logical entity such as a volume (HarddiskVolume3), or a “device that exists only to intercept traffic” created by a filter driver. A device object points back to the driver object that created it, so once you know the destination, you also know the table of handler functions.

3.3. The File Object — The State of “One Open”

Every time CreateFile succeeds, the kernel creates one file object. This isn’t “the file on disk” itself — it represents one session of having opened that file (or device).⁸ Open the same file twice and you get two file objects. The current file pointer (for a synchronous handle), and the sharing mode and flags used when it was opened, all live here.

And the HANDLE your application receives is a reference to a file object, reached through the process’s own handle table.⁹

flowchart LR
    subgraph P["Process - user mode"]
        H1["HANDLE 0x1A4"]
        H2["HANDLE 0x1B8"]
    end
    subgraph K["Kernel space"]
        FO1["File object 1<br/>report.csv opened for reading<br/>current offset: 4096"]
        FO2["File object 2<br/>report.csv opened for append<br/>current offset: 65536"]
        DO["Device object<br/>equivalent to HarddiskVolume3"]
        DR["Driver object NTFS<br/>MajorFunction = table of handlers"]
    end
    H1 --> FO1
    H2 --> FO2
    FO1 --> DO
    FO2 --> DO
    DO --> DR

Figure 3: The relationship among the three objects. A handle points, via the handle table, at a file object; a file object points at a device; a device points at a driver

With this picture in mind, a few pieces of hands-on knowledge stop being things you memorise and start being things that are simply obvious.

• What a handle leak really is: a pile of file objects (and the resources chained behind them) that keep being referenced and can never be freed. What you’re counting is entries in the handle table — exactly what Process Explorer and handle.exe show you (see “Process Explorer / Handle / VMMap in Practice”, and as an investigation write-up, “Investigating Long-Run Crashes of an Industrial Camera App — The Handle Leak”).
• Why two handles opened on the same file have independent file pointers: the pointer lives on the file object side. Conversely, a handle duplicated with DuplicateHandle points at the same file object, so the two handles share the pointer.
• A sharing violation is the kernel checking the sharing modes of the existing group of file objects against the new CreateFile request. We covered the practical side of mutual exclusion in “Mutual Exclusion Fundamentals for File-Based Integration”.

4. The IRP — An I/O Request Becomes a Parcel

4.1. Why Turn It Into a Packet?

When the I/O manager receives a request from an application — open, read, write, and so on — it packs it into a packet called an IRP (I/O Request Packet) and hands it to a driver. Most requests to a device driver arrive as IRPs.³ Devices don’t run at the same speed as the OS (a disk is orders of magnitude slower than the CPU), so requests are turned into “parcels” rather than “calls”, in a form that lets issuing and completion be separated.²

Alongside a header carrying the overall request information, an IRP has an area called an I/O stack location — one for each driver it is expected to pass through. Each driver reads “its own instructions” (the major function code and its parameters) from its own stack location.¹⁷

4.2. Going Down the Device Stack

Device objects stack up to form a device stack.¹⁸ A read from a file on a local disk, for example, roughly follows this path:

flowchart TB
    IOM["The I/O manager assembles the IRP<br/>(IRP_MJ_READ + stack locations)"]
    subgraph FSSTACK["File system side of the stack"]
        FLT["File system filters<br/>(antivirus, encryption, Procmon, etc.)"]
        NTFS["NTFS<br/>converts the in-file offset into a position on the volume"]
    end
    subgraph STSTACK["Storage side of the stack"]
        VOL["Volume / partition management<br/>(volmgr, etc.)"]
        DISK["Disk class driver<br/>(disk.sys)"]
        PORT["Storage port / miniport<br/>(storport, etc.)"]
    end
    HW[("Disk hardware")]
    IOM --> FLT
    FLT --> NTFS
    NTFS --> VOL
    VOL --> DISK
    DISK --> PORT
    PORT --> HW

Figure 4: The path a read request takes. The file system side and the storage side are separate device stacks; NTFS issues a new lower IRP addressed to the storage side to get its work done

Two things are worth remembering from this picture.

1. Filters are legitimate residents. The reason antivirus software can inspect every piece of file I/O is not a hack — it is because this “insert yourself in the middle” mechanism is an official extension point of the OS.¹⁹ Process Monitor stands in the same spot and records every I/O request. It is also the first place to suspect when investigating “file access is slow only in this particular environment” (more in Part 6).
2. The meaning of a request gets translated at every layer. The application says “8 KB starting at offset 4096 of this file”; NTFS translates that into “this cluster on this volume”; the storage stack translates it further into “this sector on this disk”. Each upper layer knows nothing about the layer below it. There’s one important qualification here: a single IRP does not travel from the application straight through to the disk unchanged. The file system side and the storage side are separate stacks, and as part of handling the IRP addressed to the file, NTFS creates and issues a new, lower-level IRP addressed to the volume (the storage stack). For a fragmented file, a single read can even split into multiple lower IRPs — the granularity and lifetime of a request change at every layer.

4.3. Each Driver’s Three Choices

There are, fundamentally, only three things a driver that receives an IRP can do.³¹⁰

flowchart TB
    RECV["A driver receives the IRP"]
    Q{"How does it handle this request?"}
    DONE["(1) Complete it itself<br/>call IoCompleteRequest<br/>e.g. answer immediately from data in the cache"]
    PASS["(2) Pass it to the device below<br/>call IoCallDriver<br/>e.g. a filter inspects it, then passes it straight through"]
    PEND["(3) Hold it pending<br/>return STATUS_PENDING and queue the IRP<br/>e.g. waiting on hardware to respond"]
    LATER["Call IoCompleteRequest later<br/>triggered by an interrupt or similar"]
    UP["Completion processing runs back up the stack<br/>in reverse order (each layer's completion routine is called)"]
    RECV --> Q
    Q --> DONE
    Q --> PASS
    Q --> PEND
    PASS -->|"the layer below completed it on the spot"| UP
    PASS -->|"the layer below held it pending<br/>(the pending status propagates back to the caller)"| LATER
    PEND --> LATER
    DONE --> UP
    LATER --> UP

Figure 5: The three choices a driver has on receiving an IRP. These three are not mutually exclusive — the most common path is “pending happens further down after being passed on” — and every path ends in completion via IoCompleteRequest

These three are not mutually exclusive choices. The most ordinary path is “(2) pass it down, and some layer further down chooses (3), pending”, in which case STATUS_PENDING propagates unchanged, both to the intervening drivers and to the original caller. When a lower layer completes it later, each layer that registered a completion routine when it passed the IRP down is called back, in reverse order — in other words, “passing on” and “pending” happen layered on top of the very same single IRP.

This three-way choice is the wellspring of Windows I/O’s flexibility.

• A cache hit lets it complete immediately, which is fast (the Cache Manager, in Part 4).
• Any number of filters can insert themselves and pass the request straight through (minifilters, in Part 6).
• Because a request can be held pending, a thread doesn’t have to freeze up while waiting on a slow device (asynchronous I/O, in Parts 2 and 3).

The rest of this series, really, is just a set of footnotes to this one diagram.

5. Following One Round Trip of ReadFile

Now that the cast and the props are in place, let’s follow one full round trip of ReadFile, in the case where it misses the cache and goes all the way to disk (we’ll cover the cached case in Part 4).

sequenceDiagram
    participant App as Application thread
    participant IOM as I/O manager
    participant FS as Filter + NTFS
    participant ST as Storage stack
    participant HW as Disk hardware

    App->>IOM: ReadFile -> NtReadFile (system call)
    Note over IOM: Resolves the file object from the handle<br/>and assembles the IRP (IRP_MJ_READ)
    IOM->>FS: IoCallDriver (to the top of the stack)
    FS->>ST: Translates the position onto the volume<br/>and issues a lower IRP addressed to the storage stack
    ST->>HW: Issues the read command
    ST-->>FS: STATUS_PENDING (the lower IRP is pending)
    FS-->>IOM: The original IRP also returns pending<br/>(the outbound leg ends here)
    Note over App: Synchronous I/O: the thread sleeps here waiting for completion<br/>Asynchronous I/O: control returns and other work can proceed
    HW-->>ST: Interrupt - "data has been read"
    Note over ST: Continues completion processing<br/>via a DPC, triggered from the ISR
    ST->>FS: Completes the lower IRP (IoCompleteRequest)<br/>received by NTFS's completion routine
    Note over FS: Once all the lower IRPs<br/>it needed have completed
    FS->>IOM: Completes the original IRP (IRP_MJ_READ)
    Note over IOM: Runs each layer's completion routine in reverse order,<br/>and settles the result via an APC to the requesting thread
    IOM->>App: Status and byte count are settled (e.g. an event is signalled)

Figure 6: One round trip of ReadFile when it misses the cache. Completion of the lower IRP and completion of the original IRP are separate steps, and the “outbound” and “return” legs proceed as separate events too

5.1. The Outbound Leg and the Return Leg Are Separate Events

The critical line in this diagram is STATUS_PENDING. The storage driver lets go once it has issued a command to the hardware, and the “outbound” processing ends right there. The fact that data has finished being read is announced later, through a completely separate event — an interrupt — and that is what kicks off the “return” completion processing.¹⁰

In other words, inside the kernel, issuing an I/O request and completing it are built so they can be separated. There is no separate plumbing called “synchronous I/O” — the precise meaning of synchronous I/O is simply the guarantee that the call does not return before completion. Waiting only happens when a request goes pending; for a request a driver can complete on the spot (the “complete” path in Figure 5), the thread returns with its result without ever sleeping, even for synchronous I/O. The reason Win32 switches between synchronous and asynchronous by how the handle is opened (FILE_FLAG_OVERLAPPED) is precisely because asynchronous isn’t “a special extra feature” — it’s a difference in how you wait.¹¹

Once you hold this view, the questions Part 2 tackles — why whether a call is asynchronous is decided when the handle is opened, not per call (even though the OVERLAPPED structure itself is needed for every individual operation in flight), and what it means for “something that should be asynchronous” to “complete synchronously” — start to look like the natural consequence of how the mechanism is built, rather than arbitrary facts. The reason .NET’s async/await doesn’t consume a thread while waiting on I/O (a story we covered from the practical side in “A Practical Decision Table for C# async/await”) is grounded in this very diagram, too.

5.2. There’s an Exception Too — a Shortcut That Skips the IRP

To be honest, not all I/O becomes an IRP. For synchronous reads and writes to a file that’s sitting in the cache, the file system offers a shortcut called fast I/O — copying directly out of the cache without assembling an IRP at all. In Procmon’s Operation column, these are the lines that start with FASTIO_. We’ll cover the conditions under which this shortcut can’t be used, and its relationship with the Cache Manager, in Part 4.

6. Behind CloseHandle — Cleanup and Close Are Different Things

Finally, how to close what you’ve opened. This connects directly to handle-leak investigations and “file in use” problems.

What CloseHandle does is remove one entry from the process’s handle table. A file object carries a handle count (the number of handles) and a reference count (the number of references held from inside the kernel), and the two go down independently.

sequenceDiagram
    participant App as Application
    participant OB as Object Manager
    participant IOM as I/O manager
    participant FS as File system

    App->>OB: CloseHandle(h)
    Note over OB: Removes the entry from the handle table<br/>and decrements the handle count
    alt that was the last handle
        IOM->>FS: IRP_MJ_CLEANUP
        Note over FS: Cancels outstanding I/O on that file object<br/>and releases locks
    end
    Note over OB: But if kernel-internal references remain -<br/>outstanding I/O, a memory-mapped section, etc. -<br/>the file object is still alive
    alt the reference count has also reached zero
        IOM->>FS: IRP_MJ_CLOSE
        Note over FS: The file object's teardown finishes -<br/>only now is it truly "closed"
    end

Figure 7: The two stages — cleanup (the last handle closed) and close (every reference is also gone)

• IRP_MJ_CLEANUP announces “the last handle has been closed”. But the documentation itself notes that release of the file object may still be pending if outstanding I/O remains.¹²
• IRP_MJ_CLOSE announces “the reference count has reached zero”. There is a gap between cleanup and close, and one does not necessarily follow the other immediately.¹³

Knowing these two stages explains a number of mysteries from the field.

• A memory-mapped file isn’t released even after you close it. A mapped section keeps holding a reference to the file object, so close doesn’t arrive until the view has been unmapped and the section has been closed. We covered the practical side of shared memory in “Shared Memory Pitfalls and Practical Best Practices”.
• Hunting down the culprit behind a “file in use” doesn’t end with handles alone. Even with every handle closed, a kernel-internal reference — a mapped image, for instance — can still be gripping the file. This is exactly why Process Explorer’s search covers both handles and DLLs (mapped files).
• You should never rely on .NET’s SafeFileHandle or a finalizer to “eventually” close things for you, precisely because a forgotten, unclosed handle delays cleanup and drags out sharing violations and held locks.

7. See It for Yourself

Everything up to this point can be observed with nothing more than one Windows PC with administrator rights.

You only need three things.

• Administrator rights. Process Monitor loads a kernel driver, so it has to run as administrator. WinObj also hides some objects from anyone who isn’t.
• The Sysinternals tools. WinObj and Process Monitor are distributed free of charge by Microsoft. Get them individually from their download pages (WinObj, Process Monitor), or grab the whole set with the Sysinternals Suite. There’s no installer — just unzip and run the exe.
• Something small to do while you watch. Saving one file from Notepad, or copying one small file, is plenty. Try it on your local disk, not a shared business folder or a production machine.

Look at the namespace with WinObj. Launch Sysinternals’ WinObj and open the GLOBAL?? directory, and you’ll see, right there, that C: is a symbolic link to \Device\HarddiskVolumeN (Figure 1). Under \Device, you can see the real names of the device objects the drivers have created.¹⁴

Read the vocabulary of IRPs in Procmon. Turn on Filter > Enable Advanced Output in Process Monitor’s menu, and the Operation column switches from ReadFile to the kernel-side vocabulary: IRP_MJ_READ, FASTIO_READ, and so on. Just watching one file copy, you’ll see the very flow this article describes play out for real: IRP_MJ_CREATE → FASTIO_READ/IRP_MJ_READ → IRP_MJ_WRITE → IRP_MJ_CLEANUP → IRP_MJ_CLOSE. We’ve put together the practical side of using Procmon in “A Practical Guide to Process Monitor (ProcMon)”.

Stay aware of the bottom layer from .NET. C#’s FileStream calls CreateFileW internally and holds the handle as a SafeFileHandle. The FileOptions passed to its constructor map almost directly onto Win32 flags.

From .NET 6 onward, File.OpenHandle together with the RandomAccess class also lets you write in a style much closer to Win32’s raw form — “handle plus offset-specified I/O” — without going through the FileStream abstraction. Once you understand what the right-hand column of this table means, the choices on the left stop being things you memorise.

8. Summary

• Windows I/O is built on a single, consistent design: decide the destination (a device object) in the Object Manager’s namespace, pack the request into an IRP, and flow it down the device stack.²³¹⁸
• C: is a symbolic link, \\.\ directly names where a link lives, and a UNC path resolves to a redirector. The real secret behind “everything looks like a file” is the consistency of name resolution.⁴⁵
• There are three characters in the cast: the driver object (a table of handler functions), the device object (the destination), and the file object (the state of one open). A HANDLE is a reference to a file object.⁶⁷⁸⁹
• A driver’s choices come down to three: complete, pass through, or hold pending. Filter interception, immediate answers from the cache, and asynchronous I/O are all applications of this one three-way choice.³¹⁰
• Issuing and completing a request are built to be separable, and synchronous I/O is the guarantee that “the call does not return before completion”. For a request that goes pending, the outbound leg (issuing) and the return leg (interrupt then completion) proceed as separate events.¹¹¹⁰
• CloseHandle only “returns a handle”. Once you know the two stages — cleanup (the last handle) and close (the last reference) — “closed, but still in use” stops being a mystery.¹²¹³

Next up is Part 2, “Synchronous and Asynchronous I/O — What OVERLAPPED Really Means”. We dig into the mechanism that lets an application actually use the “separation of issuing and completion” we saw in this article — FILE_FLAG_OVERLAPPED, the four ways to be notified of completion, cancellation, and the trap where something “supposed to be asynchronous” comes back synchronously.

Related Articles

• A Practical Guide to Process Monitor (ProcMon) — Pinpointing “Settings Not Applied” and “ACCESS DENIED” in 10 Minutes
• Process Explorer / Handle / VMMap in Practice — Chasing Hangs, Leaks, and “File in Use” from the State Right Now
• Investigating Long-Run Crashes of an Industrial Camera App - The Handle Leak (Part 1)
• Mutual Exclusion Fundamentals for File-Based Integration - Best Practices for File Locks and Atomic Claims
• Shared Memory Pitfalls and Practical Best Practices
• A Practical Decision Table for C# async/await - Task.Run and ConfigureAwait
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• MAX_PATH and Windows Path/Filename Pitfalls — the 260-Character Limit, Reserved Names, Trailing Dots, and Case Sensitivity

Related Consulting Areas

KomuraSoft LLC handles design and bug investigation around file I/O in Windows business applications — handle leaks, “file in use” errors, I/O slowdowns confined to specific environments, and more.

• Windows Application Development
• Bug Investigation and Root Cause Analysis
• Legacy Asset Utilization and Migration Support
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What is an IRP?

An IRP (I/O Request Packet) is the packet the Windows kernel's I/O manager uses to bundle up an application's read, write, and other requests and hand them to device drivers. Microsoft's driver development documentation explains that most requests sent to device drivers are packaged as IRPs. An IRP carries a major function code that indicates the kind of request (create, read, write, cleanup, and so on) and a stack location for each driver it passes through, and it is processed as it flows down the device stack from top to bottom. Each driver chooses whether to complete the IRP itself, pass it to the driver below, or hold it pending and complete it later. Application developers never touch an IRP directly, but notations such as IRP_MJ_READ that appear in Process Monitor's Operation column are this very mechanism made visible.

Why can Windows open a file, a serial port, and a printer with the same CreateFile call?

Because whatever name you pass to CreateFile is ultimately resolved, through the Object Manager namespace, to a device object, and the I/O manager then creates a file object tied to that device and hands back a handle — the same path every time. A drive letter such as C: is, underneath, a symbolic link to an NT device name such as \Device\HarddiskVolume3, and a designation like \\.\COM1 likewise resolves to the serial port's device object. Whatever device the name resolves to, every subsequent request is packaged into the same IRP format and delivered to a driver, which is why files and devices alike can be opened and read or written through the same API. UNC paths follow the identical mechanism — they simply resolve to the network redirector's device. This combination of "namespace plus packet" is the real source of Windows I/O's consistency.

Why doesn't a file get released immediately after CloseHandle is called?

Because what CloseHandle does is "return one handle", not "close the file". A file object inside the kernel carries two separate counts: a handle count (the number of open handles) and a reference count (the number of references held by kernel components). IRP_MJ_CLEANUP is sent to the file system once the last handle is closed, but as long as kernel-internal references remain — outstanding I/O, a memory-mapped file section, and so on — the file object itself stays alive, and IRP_MJ_CLOSE is sent only once the reference count reaches zero. Many of the phenomena where a file cannot be deleted after being memory-mapped, or an application reports a file as "in use" after it has already closed it, are explained by this two-stage mechanism.

What use is knowledge of IRPs and device stacks to an application developer?

Even if you never write an IRP yourself, it pays off in both investigation and design. First, Process Monitor's Operation column (with advanced output enabled) displays exactly the vocabulary of IRPs, such as IRP_MJ_CREATE and IRP_MJ_READ, so knowing the terms at this layer lets you actually read the log. Second, once you know that filter drivers, such as antivirus software, sit across every path that file I/O takes, you have a lead when investigating a problem like "file access is slow only in this particular environment". And once you understand that Windows I/O is built so issuing and completing a request can be separated, and that synchronous I/O is merely a guarantee that "the call does not return before completion", asynchronous I/O, I/O completion ports, and .NET's async/await behaviour all make sense from first principles rather than as memorised facts.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.