The Windows Registry, End to End

Hey Investigator,

Almost every Windows forensic finding passes through the registry at some point: what ran, what persisted, which USB stick was plugged in, which network the machine joined. Yet most investigators meet it through a tool that shows a tree, and never see what is underneath.

This guide takes it apart completely. It starts with what the registry actually is and why Windows cannot function without it, then goes down to the bytes: hive files, the base block, cells, the records that are keys and values, and finally the transaction logs: the part almost every tool ignores, and the reason a hive on disk is often not the registry that was really running.

No prior knowledge assumed. Every byte shown below was read out of a real SYSTEM hive captured from a running machine, so you can follow along in a hex editor.

Where these figures come from. Every number, byte map and table on this page was measured from a live Windows 11 system, its hives and transaction logs captured together through a single Volume Shadow Copy. That system is called the reference system throughout. Identifying values are redacted; every offset, length, count and timestamp is the real measurement.

The consequence: the SYSTEM hive is loaded by the boot loader itself and handed to the kernel in memory. It is not a file the operating system opens once it is running . It is one of the things that makes it run. A corrupt SYSTEM hive is not a misconfigured machine; it is a machine that does not boot.

The catch this guide is really about

All of that assumes the hive file you are reading is the registry that was actually running. Very often it is not.

Windows does not finish a registry write in one go. It writes what it is about to do into a second file first, changes the hive, and only then marks the hive as settled. Copy a hive off a machine that is switched on and you will usually catch it mid-sentence: the file is complete and readable, but the most recent changes are not in it yet. They are in a file sitting right next to it, called SYSTEM.LOG1 or NTUSER.DAT.LOG1, which most tools do not open at all.

The practical result is that the newest registry activity, which is usually the activity closest to whatever you are investigating, is the part most likely to be missing. That is sections 15 to 17.

Two consequences that matter constantly in casework.

• HKEY_CURRENT_USER is not a file. It is whichever NTUSER.DAT belongs to the account you are running as, mounted under HKEY_USERS. A user who is logged off has no entry there: their hive is on disk, unmounted, and invisible to any live tool.
• HKLM\SAM and HKLM\SECURITY cannot be read in place even as Administrator; their own ACLs deny it. They must be extracted with backup privileges or read from an image.

Three things that exist only while Windows is running

HKLM\HARDWARE is volatile. It is built by the kernel at boot from what it finds on the bus, and written to no file. If you are working from an image, it is not missing, it never existed on disk. The same is true of HKLM\SYSTEM\CurrentControlSet, which is a link created at boot to whichever ControlSet00n was selected.

HKCR is a merge, not a hive. It presents HKLM\SOFTWARE\Classes overlaid with the user's UsrClass.dat, with the user's entries winning. A COM hijack that appears in HKCR live may live in either file, and only one of them is per-user. When you work offline you must decide which you are looking at.

WOW6432Node is a redirection, not a location. On a live 64-bit system a 32-bit process asking for HKLM\SOFTWARE\Classes\CLSID is quietly served ...\Classes\Wow6432Node\CLSID. In the file, only the second path exists. A query written against the live illusion returns nothing offline, with no error to say why.

Why the difference is the whole point

Regedit shows you a tidy tree because Windows builds one for it. On disk there is no tree: there are records scattered through the file, pointing at each other by position. The tree is something a program assembles by following those pointers.

That is why deleted keys can be recovered, why a half-written hive can look perfectly healthy, and why two tools can read the same file and disagree. All three are covered later, and all three come from the same fact: what Regedit shows you is a reconstruction, not a picture of the file.

The checksum, and why it bites

The last segment of the map is the checksum at 0x1FC: d4 41 93 6d, or 0x6D9341D4 in this hive. It is an XOR of the 127 32-bit words before it. That phrase is doing a lot of work, so unpacking it: everything from the start of the file up to the checksum is 508 bytes, and reading those 508 bytes four at a time gives 127 numbers, each 32 bits wide. XOR them all together and you should get the value stored here.

Why XOR and not a real checksum. XOR is about as cheap as an operation gets, and this value is recomputed every time the header is flushed to disk, which happens constantly. It is there to catch a storage fault: a bit that flipped on the way to the platter, a sector that came back wrong. It is not there to catch anyone. Two bits flipped in the same position of two different words cancel out exactly, so anybody editing a hive deliberately can keep the checksum valid without effort. Treat it as a signal that the header is undamaged, never as a signal that it is unaltered.

Two results are reserved: if the XOR comes out 0 it is stored as 1, and if it comes out 0xFFFFFFFF it is stored as 0xFFFFFFFE. Any tool that writes a hive back, including the log recovery in section 18, must recompute it, or every reader rejects the file. Note also what the map makes obvious: everything from 0xB0 to 0x1FB is reserved and empty, so the header is 4096 bytes of which fewer than two hundred carry anything.

Two timestamps, and only one you can lean on

The last-written FILETIME at 0x0C reads zero in this hive. Across all seven hives on the reference system it is zero on six, and populated on UsrClass.dat, which records 2026-02-05 17:27:47. So it is written sometimes and not others. Check it; never assume it.

The one populated everywhere is last-reorganised, at 0xA8: when Windows last compacted the hive, rewriting free space and reordering cells. On the reference system all seven land within the same fifteen minutes of 2026-08-12: what a single scheduled maintenance pass looks like from the inside.

Neither is the timestamp forensics leans on. That is the per-key one in section 9, maintained on every key, and the closest thing the registry has to a clock.

Why this is worth knowing

A hive carries a record of where it came from. An NTUSER.DAT pulled out of unallocated space, or renamed, or handed to you in a folder called evidence\hive3.dat, still says \??\C:\Users\Admin\ntuser.dat in its own header: naming the account it belonged to, without any external context.

Treat it as a strong lead rather than proof: it is written when the hive is created, so a profile renamed afterwards keeps the old path, and nothing prevents the field being edited. But it is checked far less often than it deserves.

Negative size = allocated. Positive size = free.

The root cell of this hive sits at file offset 0x1020 and its size field reads -88: 88 bytes, in use. Those four bytes are the reason the file can be read at all. There is no index of cells anywhere in a hive, and no table of contents. Every cell simply begins by stating its own length, so a program finds the next cell by reading the current one's size and stepping exactly that far forward. That is the entire navigation mechanism, and it is why one wrong size field makes everything after it in that bin unreadable: the program is no longer landing on cell boundaries.

On top of carrying the length, the sign carries the status. Negative means the cell is in use, positive means it is free. To work out how much space a cell actually gives you, take the absolute value and subtract the four bytes the size field itself occupies, so this 88-byte cell holds 84 bytes of record.

Freeing a cell therefore costs almost nothing: Windows flips the sign and moves on. It does not erase the contents, it does not shuffle anything up to close the gap, and it does not touch the bytes at all.

A trap worth naming

The subkey list offset is at 0x1C, not 0x18. 0x18 is the volatile subkey count. Reading the wrong one gets you a small integer where an offset should be, which then points somewhere meaningless inside the first bin, and a parser that does not validate will happily read garbage and report it as registry data. This exact mistake was made while writing this guide, and it was caught only because the resulting "subkey list" had a cell size of 7 235 938 bytes and a signature of \x00\x00. Validate signatures; do not trust offsets.

The inline-data trick

Normally a value's vk record does not contain its data. It contains a number saying where the data is, and the program reads that number and jumps to that position in the file to fetch it. That jump is what "following an offset" means, and it happens millions of times in a registry parse.

For very small values that is wasteful. Allocating a whole separate cell to hold four bytes costs more in bookkeeping than the four bytes are worth. So the format has a shortcut: if the top bit of the data-size field is set, the data is not somewhere else at all. It is sitting in the four bytes that would otherwise have held the position. The field that normally says "the data is over there" instead says "the data is right here, and it is this".

The trap is that nothing about the record looks different. A program that always treats that field as a position will, for a REG_DWORD whose value happens to be 1, jump to position 1 in the file, read whatever bytes are sitting in the header there, and report them as the value's data. The length will be right. The type will be right. The data will be nonsense, and no error will be raised anywhere, because from the program's point of view it did exactly what it was told.

The fix is one line and one branch: strip the top bit off before using the length, and use it to decide whether to read the field as data or as a position.

Types outside the twelve documented ones

… values on the reference system carry a type that is not one of the twelve. They are not corruption, and they are not spread at random: every one of them sits under a device or driver key, in Enum, DeviceClasses, DriverDatabase\DriverPackages or Setup\Upgrade\PnP.

The data itself says what they are. A value typed 0xFFFF0012 holds UTF-16 text; 0xFFFF0007 is always exactly four bytes; 0xFFFF0011 is one byte; 0xFFFF000D is sixteen, the size of a GUID; and 0xFFFF0010 is eight bytes that decode as a FILETIME. That is the device property type space, which Plug and Play stores in the same field.

What it means for a parser: a switch on the type field with twelve cases and no default will silently drop thousands of values on a normal Windows install, and every one of them is device history.

For anyone writing a parser: lf and lh have 8-byte entries, li has 4-byte entries, and ri entries point at further lists that must be walked recursively. Assuming an 8-byte stride for all of them reads every other entry as garbage on an li list, and produces a subkey count that looks plausible.

Two things worth noticing as you walk it.

• The cell wrapper is always there. Every record begins with four bytes that are not part of the record. They belong to the allocator. "Cell" and "nk" are not two words for the same thing; one contains the other.
• Nothing is nested in the file. A key's children are not stored inside it; they are somewhere else entirely and it holds their offset. The hierarchy you see in regedit is reconstructed by chasing those offsets, which is exactly why a single broken one makes a hive unreadable.

Why an examiner should care

A key whose permissions differ from its siblings has its own sk record, and that is visible structurally without reading a single ACL. Where thousands of keys share one descriptor, an outlier is worth a look: weakened permissions on a persistence key is a way to let a non-administrator write to it, and it leaves no trace anywhere else.

Note also what is not here. The sk record stores SIDs, not names. Resolving them against the machine you are sitting at is how an offline account gets confidently mislabelled as a local one.

Four of those five are the boot key

JD, Skew1, GBG and Data under ControlSet001\Control\Lsa each hold eight hexadecimal characters in their class name, and nothing in their values. Concatenated in a fixed order and then permuted, those thirty-two characters are the SysKey, the machine's boot key, which is the input to decrypting the password hashes in the SAM hive.

This is the reason the field is worth knowing about. Windows put a secret somewhere that most registry viewers do not render, and a tool that reads names and values and ignores class names cannot see it at all, while the bytes sit in plain text in the file.

The values are not printed on this page. Every other figure here comes from a real machine and is shown; these four are the exception, because together they are that machine's boot key. The lengths are shown instead, and they are the part that makes the point.

What a carved key is and is not

It is not proof of deletion by a person. Windows frees registry cells constantly by itself: uninstallers, driver updates, profile maintenance and the periodic reorganisation from section 7 all leave freed cells behind. A key in free space means it was removed, not that anyone removed it deliberately.

Its parent is a pointer, not a path. A recovered nk holds its parent's offset, and that cell may itself have been reused. Where the chain breaks, the key's full path is unknown, and inventing one is how a carved artefact turns into a wrong conclusion. Following those pointers is still worth doing, because it works more often than not: in the reference system's SOFTWARE hive, 941 of the 1,451 carved keys walk their parents all the way back to a key that is still live and get a full path out of it. The other 510 keep their name, their timestamp and their values and are recorded with no path at all, because a partial path reads exactly like a real one.

Free does not mean intact. The counts above are cells whose signature still reads nk or vk. Part of a record can be overwritten while its first two bytes survive, so every field has to be sanity-checked before it is believed: a name length of 60,000 or a timestamp in the year 30,000 means you are reading someone else's data.

Nothing in the record says it was deleted. A carved nk is byte for byte the same shape as a live one; the entire claim rests on where the reader found it. An allocator walk that miscounts a single cell size, or a pointer followed back into space that is still in use, produces a table of deleted keys that were never deleted, and no field anywhere in that output would look wrong. The claim has to be checked from outside itself: walk the tree separately, and require every carved offset to be absent from it.

So the registry does what databases and journalling filesystems do: it writes down what it is about to do, somewhere else, first. That somewhere else is the transaction log, and the flag that says whether it is needed is a pair of counters in the base block.

One comparison, and you know.

Sequence1 == Sequence2 → the hive was closed cleanly.
Sequence1 != Sequence2 → a write was in flight; the log holds the rest.

This is what every tool means when it says "dirty hive". It is not a heuristic . It is two integers and an equality test. A single counter could say how many writes had happened, but never whether the current one had finished.

For an examiner

On a live-acquired image, expect the interesting hives to be dirty. It is the normal condition, not damage, and not evidence of anti-forensics.

Note the base block copy at the front, and that it carries its own sequence number. That single detail is the crux of the investigation at the end of this section, and the difference between a working recovery and a corrupted hive.

These are page images, not deltas

Every offset is 4096-aligned and every size is a multiple of 4096. An entry does not say "change these bytes". It says "this page now looks exactly like this". Measured across the 53 entries of one real log: 620 page writes to only 149 distinct offsets, an average of 4.2 rewrites of the same page, with offset 0, the first bin, holding allocation bookkeeping, present in all 53.

So a later entry completely supersedes an earlier one for the same offset. That is why entries must be applied in sequence order, last write wins.

If you are implementing this: reproducing those two hashes is the best self-check available. If your Marvin32 and your header offsets are both right, the stored values come out exactly; if either is wrong, they do not. It validates the algorithm and the layout in one step, before you have written a single byte to a hive.

Which file comes first is not fixed

For UsrClass.dat on the same machine it was the other way round: LOG2 covered 251897–251915 and LOG1 continued 251916–251932. Order the pair by the sequence numbers inside them, never by filename. Assuming .LOG1 leads works on most hives and silently produces the wrong result on the rest.

The rule

Log entries chain from the log file's own base-block sequence number, not from the hive's. A log is eligible when its sequence is at or ahead of the hive's Sequence2; only a log older than the hive is refused.

For SYSTEM.LOG1 that number is 1,889,322, exactly its first entry. The log is self-describing. It was never claiming to continue from the hive; it states where it begins.

The gap was never a gap. It was a chain being measured from the wrong end.

What is still not known

Why does Windows leave the base block hundreds or thousands of sequences behind its log? Reading B is confirmed by behaviour, but the mechanism is still open. The candidates are that the log is reinitialised at a point which does not update the primary's header, or that the primary is flushed on a schedule independent of the base-block sequence. Nothing measured here distinguishes them, and one hypothesis in that family has already been tested and failed.

Settling it would need instrumented hive flushes on a live system, or kernel-side tracing of the registry writer. Neither is available from a snapshot. The recovery is verified; the explanation for one of its inputs is not, and saying so is more useful than a confident guess.

The door you come through decides what is in the file

The hives are locked while Windows runs, which is why everything on this page was collected from a shadow copy. It is worth being exact about what the alternative cannot do, because none of it is a matter of privilege. The registry API has no concept of a freed cell, so nothing in section 14 is reachable through it at any privilege level that exists. And some keys deny even an elevated administrator outright: the roots of SAM and SECURITY, and every device Properties subkey. An API walk of those simply returns a smaller tree, with no error anywhere in it. On the reference system an elevated walk of Enum\USB reaches 110 keys and is refused 21 subkeys; read as a file, the same hive gives 868.

So the answer is to stop asking the API and take the file instead, which three routes do: an existing Volume Shadow Copy, raw access to the disk underneath the lock, and a backup-privileged export, where you ask Windows itself to write the key out for you.

Those three are not equivalent, and the difference lands squarely on the two sections above. A shadow copy or a raw read hands you the hive as it sits on disk, allocated cells and freed cells alike. An export is a fresh file: Windows walks the live tree and writes out what it finds, and a freshly written hive has no free space in it at all. Carve an exported hive and you recover nothing, which is a true statement about that file and a false one about the machine it came from. Which door a hive arrived through is therefore part of what it is, and belongs recorded beside it, because it decides what an empty result means.

Reproduce all of it

Every byte on this page came from files any Windows machine has. The hives are locked while Windows runs, so they must be read through a Volume Shadow Copy or raw disk access. From there: the sequence numbers are two uint32 at 0x04 and 0x08; the first hive bin is at 0x1000; the root cell is at 0x1000 + the offset in 0x24; the log's first entry is at offset 512. A hex editor is enough to confirm every table here.

The two doors disagree, quietly

The library behind an offline read reports a key's unnamed value as the literal string (default), lowercase. The Windows API reports it as an empty name. Nothing errors either way, so the same key produces a different row depending on which door it was read through, and any comparison between the two silently never matches. That is the shape of nearly every live-versus-offline disagreement: not a crash, a difference.

The hives themselves

Every number, byte map and table on this page was measured from real hives captured from a running Windows 11 machine through Crow-Eye's own volume shadow copy path, alongside their .LOG1 and .LOG2 files. None of it is an illustrative example, and none of it was typed in by hand: a generator reads the hives and emits the data the page renders, and a separate script re-measures every published figure and fails if the page and the files disagree.

That is also the limitation. These are seven hives from one machine. Where a statement is true of these files rather than of all Windows systems, the page tries to say so, and where something was tested and turned out not to hold, it says that too.