Driver Interface#

The on-disk structures only tell half the story; the other half is the code that writes them. This page is the static-analysis companion to the Driver Architecture model — it reads the refs.sys binary across three builds (Win10 v3.4, Win11 v3.14, Insider) and reports what the imports, embedded libraries, class tables, and IRP dispatch reveal about which features a given driver can produce. For an analyst this matters because the driver is the ground truth: a feature visible on disk has a code path that created it, and the presence or absence of that code path tells you what a volume could and could not contain. Function counts are non-external (defined) functions only, and every class name, method, and count below is verified against the function catalog.

What the binary reveals across builds#

The driver grows from 3,959 functions in v3.4 to 5,818 in v3.14 — a ~47% increase — while the count of functions that carry a PDB-resolved name stays nearly flat (2,553 in v3.4 vs 2,565 in v3.14), so PDB coverage falls from 64.5% to 44.1%. That combination is the signature of refactoring plus new subsystems: many old functions were replaced rather than extended, and the added bulk is whole new feature areas, not incremental edits to the storage core. The Insider build adds a further 612 functions on top of v3.14 (6,430 total; 2,878 PDB-named, 44.8% coverage). The practical reading is that v3.4 structural knowledge remains a valid baseline (the engine is stable) but each build can mint metadata the previous one could not.

Imports: the driver’s external dependencies#

The import table is the cleanest external evidence of what a driver build can do, because a feature that needs a kernel service must import the API that provides it. The v3.4 driver imports 415 functions from just two libraries — ntoskrnl.exe (core kernel services) and HAL.dll (one performance-counter call). The v3.14 driver imports 566 (+36%) from seven libraries — adding five — and each addition maps to a specific new capability:

The cng.sys import is the most forensically useful single fact here: it is the driver-level proof that the build supports EFS, because ReFS does not implement the RSA/AES crypto itself — it delegates the SHA-256 metadata and key operations to the cng.sys BCrypt* provider (the in-driver wrapper is CmsBCrypt). A v3.4 driver, lacking that import, cannot encrypt a stream.

Embedded libraries: compression evidence inside the binary#

The v3.14 driver also embeds two complete compression-library implementations directly in the binary, which accounts for part of its size growth and replaces the v3.4 LZX/XPRESS wrappers:

These embedded codecs are the driver-level counterpart to the compression features visible on disk: if the binary contains a ZSTD decompressor, the volume can hold ZSTD-compressed extents. Note that the v3.14 checksum consolidation does not rely on an embedded crypto library — CRC32-C/CRC64 are computed in-driver via ClMul intrinsics and XXH64 (the CmsChecksum class), with SHA-256 delegated to cng.sys/CmsBCrypt. The embedded SymCrypt library is an Insider-build addition tied to early-boot and attestation, not a v3.14 component.

Where the growth landed#

Counting functions per subsystem shows the engine is mature and the new code is concentrated in feature areas, not the storage core:

The storage core — the B+-tree node layer, integrity, checkpoint, and transactions — changed by less than 10%, which is why the on-disk layout of those structures is stable across versions. The explosive growth is in encryption (2 to 182 functions) and the heat engine (2 to 55), confirming that EFS and tiering are the headline v3.14 features and that their on-disk artifacts (the $EFS attribute, the heat-tracking tables) appear only from the builds that carry the code.

How requests enter: the IRP handler set#

Every file operation reaches the driver as an I/O Request Packet (IRP), tagged with a major function code. The set of codes a driver routes is itself a capability fingerprint. v3.4 handles 18 major functions; v3.14 adds two — IRP_MJ_QUERY_EA and IRP_MJ_SET_EA — and those two are the driver-level signature of WSL Extended Attribute support: the code that reads and writes the $LXUID/$LXGID/$LXMOD/$LXDEV attributes. A volume whose driver lacks the EA handlers cannot have produced WSL metadata.

The codes that are resolved to a single named handler in the PDB are the two control-path entries; the rest are dispatched internally through the lower layers (see Three-tier IRP dispatch) and have no single named entry point:

One forensic caveat: the Fast I/O path lets some cached operations bypass IRP creation entirely, so an IRP-level trace is not a complete record of activity — a read served from cache may leave no IRP at all.

Minstore class reference#

The lower-layer Minstore engine is organized as a set of C++ classes whose method counts can be read straight from the symbol tables. The tables below give method counts per class for Win10 v3.4 / Win11 v3.14 RTM / Insider; every class name, method ownership, and count is verified against the function catalog.

B+-tree infrastructure#

The split is worth internalising: the row primitives (FindRow / InsertRow / DeleteRow) live on the base class CmsTable, and CmsBPlusTable layers the tree-walk iteration on top. This is the code that reads and writes every B+-tree node on the volume.

Container and allocation classes#

CmsVolumeContainer is the class that performs the virtual-to-physical translation this corpus depends on. The allocator unification — two v3.4 classes collapsed into one CmsAllocator — is documented from the on-disk side on the Allocators page.

Checksum classes#

v3.14 consolidated dozens of per-page-type checksum templates plus the CmsChecksumNone stubs into one polymorphic CmsChecksum class. The existence of CmsChecksumNone in v3.4 — a VerifyChecksum that always returns TRUE — is the code-level explanation for why a v3.4 volume formatted without integrity does not detect metadata corruption. The full integrity picture is on checksum architecture.

Volume and checkpoint classes#

The checkpoint validation that selects which checkpoint to trust at mount lives on CmsVolume, and crash recovery (CmsRestarter replaying the log) plus the redo-queue classes (CmsLogRedoQueue / CmsTxMemLog) are the engine behind the transaction / crash-consistency model. The log-record layout they produce is on the MLog page.

Configuration registers on disk#

Several on-disk fields act as runtime configuration registers — the driver reads them at mount to decide which structures and behaviors are live. They are the bridge between the code above and the bytes on the platter:

The VBR format-time fields (0x2A, 0x2C, 0x48) are never modified during an upgrade — which is what makes them reliable version-detection markers even on a volume that has been upgraded in place. Full decode tables are on the VBR and Checkpoint pages.

Insider-only subsystems#

The Insider build adds subsystems that are genuinely absent from production Windows 11 24H2, and they signal the direction of ReFS development:

Two classes that look Insider-only are not, and getting this right matters for dating a volume: CmsRollbackProtection (NVRAM checkpoint-clock rollback detection) is present in v3.14 RTM (14 methods) and Insider (13), and CmsVolumeHeatEngine is v3.14 RTM (24) / Insider (20). Neither is exclusive to the Insider build. The embedded cryptographic libraries the Insider subsystems rely on (SymCrypt, MinCrypt) are present in the Insider binary.

Cross-references#

• Driver Architecture — the two-layer model and three-tier IRP dispatch this page measures
• Version Evolution — the per-version structural changes the subsystem growth produces
• Checksum Architecture — how the CmsChecksum consolidation appears on disk
• Allocators — the on-disk side of the CmsAllocatorBase → CmsAllocator unification
• MLog — the log records produced by CmsLogRedoQueue / CmsTxMemLog / CmsRestarter
• $EFS — the encryption metadata enabled by the cng.sys import
• WSL / Linux Metadata — the EA attributes gated by the IRP_MJ_*_EA handlers
• VBR and Checkpoint — the configuration registers the driver reads at mount

Evidence#

The binary inventory, import tables, embedded-library set, subsystem counts, IRP handler set, Minstore class tables, and Insider subsystems are all from static analysis of the three refs.sys builds with full PDB symbols. The Minstore class names, method ownership, and per-build method counts were rebuilt and catalog-verified against function_catalog.csv (audit 3); the named handlers (RefsCommonCreate, RefsCommonCleanup), the row primitives (FindRow / InsertRow / DeleteRow), the checkpoint ops (ValidateCheckpointRecord / ChooseCheckpointRecord), and the checksum stub (CmsChecksumNone::VerifyChecksum) are all catalog-verified. The configuration-register offsets are raw-disk corroborated. The “Insider-only” corrections to CmsRollbackProtection and CmsVolumeHeatEngine are catalog-verified (audit 3).