Object Table#

The Object Table (roots #0 and #5, schema 0xe030) is the master OID-to-table mapping. Every persistent directory and system object has exactly one entry, so it is the pivot of the namespace. A file has no Object-Table entry of its own — it is a set of rows inside its home directory’s tree, reached through that directory’s OID plus the file’s per-directory child ordinal.

Key Format – 16 bytes#

The on-disk B+-tree leaf-row key is 16 bytes (the key type is SmsBigIdentifier, the 128-bit identifier):

Value Format – Compact (v3.10+)#

80 bytes (system objects) / 88 bytes (file objects):

Value Format – Legacy (pre-v3.10)#

A legacy Object-Table row value has three distinct sizes:

1. B+-tree value_length — the full value-buffer size: 240 bytes for objects with no 8-byte trailing field (upcase 0x7/0x8, logfile 0x9/0xa, trash 0xd, volume-info 0x500/0x501, security 0x530, reparse 0x540/0x541) and 248 bytes for the root directory 0x600, 0x520, and every file / directory (which carry an 8-byte trailing field).
2. value+0x10 — a payload offset, constant for every legacy object: 200 (0xC8). value+0x14 — the trailing-payload length, 0 or 8. Their sum (200 / 208) is the driver’s copyable payload extent.
3. The driver reads exactly those two fields: CmsObjectTable::GetObjectRecordPayload (win11 @140118c14) computes src = value + u32@0x10 and copies u32@0x14 bytes.

On compact (v3.10+) volumes the value shrinks and value_length tracks the checksum size (independent of cluster size): 80 / 88 bytes by default, 104 / 112 bytes under SHA-256. Here value+0x10 = 80 / 104 flat, so it equals value_length only for the no-trailer (system) objects, not for files.

A forensic parser keyed on the B+-tree value_length should expect 240 / 248 (legacy), 80 / 88 (compact), or 104 / 112 (compact SHA-256).

Important: Upgraded volumes show mixed format. Pre-existing objects retain legacy size; objects created after upgrade use compact size. A forensic parser must handle both sizes within the same Object Table.

OID Allocation#

• 64-bit, monotonically increasing, never reused after deletion
• Counter maintained at CmsObjectTable+0x18; atomically incremented (LOCK prefix)
• On mount, derived from the rightmost (largest) Object-Table B+-tree key. Win11/Insider use the _CmsKey::RightMost sentinel with CmsTable::FindRow (present in the decompiled win11 driver, 12 occurrences; Insider 11); the Win10 (v3.4) driver has no such symbol and uses PinInIndexRightMost / MsFindRightmostNodeAvlFull instead
• System OIDs: below 0x700 (except 0x600 which is the root directory)
• User OIDs: start at 0x701 (hardcoded via MsSetMinimumNewObjectId)
• RefsIsSystemObjectId returns true when OID <= 0x6FF AND OID != 0x600

See System OIDs for the 13 known system OIDs and their roles.

Forensic Properties#

• Lower OID = earlier creation – reliable chronological indicator
• Gaps in sequence = evidence of past deletions
• Volume activity estimation: max_OID - 0x700 = upper bound on total files ever created
• OID density: present_OIDs / (max_OID - min_OID + 1) – fresh volumes are 100%; worked volumes show 55-79%

NTFS vs ReFS Chronology Comparison#

Failover#

The Object Table has a failover pair: root #0 (table ID 0x02) and root #5 (table ID 0x04). If one copy is corrupted, the driver falls back to the duplicate.

Driver functions#

Cross-references#

• Checkpoint (CHKP) – roots #0 and #5 point to the Object Table
• Object IDs – what the OID is, why its order is chronological evidence, and why a directory keeps its OID when moved
• File IDs – how a file (which has no OID) is identified; its home half is a directory OID from this table
• Schema Table – schema 0xe030 defines key comparison for this table
• Parent-Child Table – encodes directory hierarchy relationships
• System OIDs – the 13 known system OIDs and their roles
• Container Table – needed to translate virtual LCNs in the LCN slots

Evidence#

The key/value layout, the compact-versus-legacy formats, and the failover pair are decompiled from the driver and decoded on raw disk across the corpus. The record-header decode (format=2, key/value offsets, generation and dirty-generation counters) and the four-slot LCN tuple are read by CmsObjectTable::GetObjectRecordOfIdentifier / MsGetObjectRecordPayload. The OID-allocation behaviour (monotonic, never-reused, 0x701 user floor, 0x600 root exception) is proven both statically — CmsObjectTable::GenerateIdentifier (atomic increment), DeleteIdentifier (never decrements), MsSetMinimumNewObjectId, RefsIsSystemObjectId — and on disk via the observed no-reuse / gaps-equal-deletions behaviour. > Where this is checked. forefst.py <image> integrity --fullchecksums crosses the Object Table’s leaf

rows into every object B+-tree and verifies each page against the digest recorded here — so a stale or corrupt object root is detected, by the command whose job that is. Ordinary commands do not verify it: doing so would mean re-reading and re-checksumming every object’s root page on every run, measured at about 40 seconds on a volume with ~27,000 objects. If you need the assurance, run integrity.

0x20–0x50 is a complete page reference — the same structure used everywhere else — of which 0x40 is the checksum descriptor and 0x48 the digest of the object’s root page. This is raw-disk confirmed rather than inferred: the digest recomputes over the referenced page on 34,108 of 34,108 rows corpus-wide (the 20 exceptions are all on one known-damaged volume family). It follows that a stale or corrupt object root is detectable at no cost, and that the compact 80-byte row (0x20 + 0x30) and the 104-byte SHA-256 row (0x20 + 0x48) are exactly a header plus one page reference. The remaining field-level statements on this page are registered as — each with its own evidence tier and witness in the claim register.