When an application reads the same file twice in a row, the second read is almost always far faster than the first — yet nothing in the application changed. The reason lives in the kernel: the cache manager, a system-wide component that keeps recently used file data resident in memory so that repeat access never has to touch the disk. It sits between the file systems above it and the memory manager below it, and it is one of the biggest reasons a busy Windows system feels responsive. This article looks at how the cache manager actually works — how it caches by mapping rather than by copying into buffers, how it leans entirely on the memory manager, and why the file data it holds is of keen interest to memory forensics.
Virtual Block Caching and the System Cache
The most important design decision in the Windows cache manager is that it does not maintain a pool of fixed-size block buffers the way some operating systems do. Instead it caches file data by mapping views of files into a region of kernel virtual address space called the system cache. When a file’s data needs to be cached, the cache manager maps a window onto that file and lets ordinary memory-management machinery bring the bytes in.
These windows are tracked by Virtual Address Control Blocks (VACBs). Each VACB describes a 256 KB view of a file mapped into the system cache, recording which file offset the view covers and its address in the cache. The cache manager maintains an array of VACBs and reuses them: because address space and physical memory are finite, only a working set of views is mapped at any moment, and the least recently used views are unmapped to make room for new ones. Caching at the granularity of mapped 256 KB views — rather than individual disk blocks — is why Windows calls this a virtual block cache: the unit of caching is a region of a file’s virtual byte stream, not a physical disk sector.
Relationship with the Memory Manager
The cache manager is best understood as a client of the memory manager. When it maps a 256 KB view, it is really creating a mapped view of a section object backing the file. The cache manager never reads from disk itself; it simply touches the mapped addresses, and the resulting page faults are resolved by the memory manager, which issues the actual I/O to the file system and driver stack. Writes work the same way in reverse: modifying cached bytes dirties the underlying pages, and the memory manager’s modified page writer is ultimately responsible for getting them to disk.
This tight coupling explains one of the most misunderstood facts about Windows memory: the RAM shown as available is largely cache. Pages holding cached file data that no process currently has mapped are parked on the memory manager’s standby list — clean, still valid, and instantly reclaimable. If the same data is requested again, a cheap soft fault revives it with no disk access; if memory is needed elsewhere, the page is repurposed. In other words, “free” memory on a healthy Windows box is doing useful work as a file cache right up until the moment something else needs it.
Read-Ahead and Write-Behind
Two asynchronous behaviors make the cache feel fast. Read-ahead (also called prefetching) watches a file object’s access pattern and, when it detects sequential reads, proactively maps and faults in the next region of the file before the application asks for it. By the time the program issues its next read, the data is often already resident. The cache manager also supports intelligent read-ahead that can recognize some strided and repeating patterns, not only strictly sequential ones.
Write-behind (lazy writing) is the mirror image. When an application writes to a cached file, the write normally completes as soon as the bytes land in the cached pages in memory — the data is marked dirty but not yet on disk. A system worker thread, the lazy writer, periodically flushes dirty cached pages in the background, smoothing bursts of writes into steady disk activity and letting the application continue without blocking on I/O. Applications that need durability guarantees bypass this by requesting write-through or by explicitly calling FlushFileBuffers, which forces the dirty pages out immediately.
Cache Coherency
A single file can be accessed several ways at once: through normal cached ReadFile/WriteFile calls, through a memory-mapped view created by an application with MapViewOfFile, and through non-cached I/O that deliberately bypasses the cache. Keeping all of these consistent is the cache manager’s coherency problem, and Windows solves it elegantly: because both the cache manager’s views and an application’s mapped view are ultimately backed by the same section object and therefore the same physical pages, a write through one path is naturally visible through the other. There are not two copies to reconcile — there is one set of pages.
The cache manager tracks caching state per file through two structures hung off the file object. The shared cache map describes the cached state of the file as a whole — its VACB mappings, its valid data length, and its dirty ranges — and is shared by every handle to that file. Each individual file object additionally has a private cache map that records that opener’s own read-ahead history and position, so read-ahead prediction is tracked per handle rather than globally.
Fast I/O
For the common case of a cached read or write that hits data already in memory, building a full I/O request packet and sending it down the device stack (as described in the I/O manager article) would be wasteful overhead. Windows provides a shortcut: the fast I/O path. A file system driver exposes a table of fast I/O callbacks, and when a request can be satisfied straight from the cache, the I/O manager calls directly into the file system’s fast I/O routine, which in turn copies data to or from the cached pages via the cache manager — no IRP is ever allocated. If the data is not resident or the operation is too complex for the fast path, fast I/O declines and the request falls back to the normal IRP-based path. This is a major reason cached reads are so cheap.
Inspecting the Cache
The cache is observable both in a debugger and with live tools:
# WinDbg (kernel): summarize the system file cache
!filecache
# Inspect the VACBs / shared cache map for a file object
dt nt!_SHARED_CACHE_MAP <shared-cache-map-addr>
# Memory manager view: the standby list is where reclaimable
# cached pages live (ties the cache to physical memory state)
!memusageOn a live system, RAMMap from Sysinternals is the clearest window into the cache: its “File Summary” tab lists exactly which files are resident and how many pages each occupies, and its use-by-category view shows how much RAM is on the standby (cache) list versus in active process working sets. Performance Monitor exposes cache counters (copy read hits/sec, data map hits, lazy write flushes) under the Cache object for watching hit rates over time.
Security Relevance
The cache manager matters to defenders and forensic analysts for one blunt reason: file contents linger in RAM long after you would expect them to be gone. Because cached pages migrate to the standby list rather than being wiped, the bytes of a file that a program opened — a configuration file, a document, a script, a decrypted secret written to a temp file — can remain physically present in memory well after the file handle is closed, and even after the file is deleted from disk. Memory-forensics frameworks exploit exactly this: by walking the memory manager’s page lists and the cache manager’s file mappings, they can carve cached file data out of a memory image, sometimes recovering artifacts that no longer exist on the filesystem.
Two practical implications follow. For incident responders, the standby list is a valuable evidence source — capture memory before it is overwritten, because reboots and heavy memory pressure erode it. For anyone handling sensitive data, remember that ordinary file APIs route through the cache, so writing a secret to a temporary file, even briefly, can leave it recoverable in RAM; deleting the file does not scrub the cached pages. Understanding that the cache is really just mapped, reclaimable memory — not a separate wiped buffer — is what makes both of these consequences obvious rather than surprising.
Conclusion
The cache manager delivers system-wide file caching not by hoarding copies in private buffers but by mapping 256 KB file views into the system cache and delegating every hard question — faulting, eviction, dirty-page writeback — to the memory manager. Read-ahead and lazy write-behind hide latency, fast I/O skips the IRP path entirely on cache hits, and shared section backing keeps every view of a file coherent for free. The same design that makes it fast also makes cached data persist in physical memory, which is why the cache is a recurring theme in memory forensics. Having followed file data from the I/O stack into the cache, the next article looks at the primitive underneath both the cache and application memory mappings: the section object and memory-mapped files.
You Might Also Like
This article is part of the Windows Internals series. These related deep-dives cover adjacent parts of the system:
Comments