Does AmCache prove a program was executed?

Mostly no. AmCache is an inventory: it records programs and files that the Application Experience service catalogued, which happens on installation, on a scheduled scan and when a file is examined. Some entries do follow execution, but an entry on its own proves the file was PRESENT rather than that anybody ran it. Pair it with Prefetch, UserAssist or an event log before calling it execution.

What is the SHA-1 in AmCache, and why does it look wrong?

InventoryApplicationFile stores a file identifier that is the file's SHA-1 with four zeros prepended. Reading the field as a hash without stripping those gives a value that matches nothing, which is why a lookup against a hash set silently returns no hits. It is also only the first 30 MB of the file on some builds.

How is AmCache different from ShimCache?

They answer different questions and are written at different times. ShimCache is the compatibility engine's cache, flushed at shutdown, holding paths and file modification times with no hashes. AmCache is an inventory database written continuously, holding hashes, publishers, versions and install dates. When they disagree about a file, the disagreement is itself worth reading.

Where does AmCache live and is it a registry hive?

C:\Windows\AppCompat\Programs\Amcache.hve. It is a genuine registry hive in format - same base block, same cells, same transaction logs - but it is not mounted under any HKEY, so nothing in regedit shows it. It has to be read as a file, which also means it can be carved.

Why does AmCache have so many tables?

It grew. Early versions had a handful of keys under Root; the reference system's hive has 26, covering applications, files, shortcuts, drivers, driver packages, device containers, PnP devices, device interfaces and several inventory categories that have no documentation at all.

Eye Describe Anatomy

AmCache: structure, contents and evidential limits

A registry hive that no HKEY points at, holding an inventory of the software on the machine with hashes attached. What each field means, and the difference between having been catalogued and having been run.

What this page covers

An unmounted registry hive
The hive records that make up an AmCache entry
What the hive contains
A file entry, field by field
What an entry supports, and what it does not
How Crow-Eye reads the hive
Schema changes across Windows releases
Reference
Anti-forensic handling, and what survives it

An unmounted registry hive

Windows keeps an inventory of the software it has seen, with SHA-1 hashes attached, in a registry hive that nothing mounts.

C:\Windows\AppCompat\Programs\Amcache.hve the whole artifact, one file

It is a registry hive in every structural sense: a regf base block — the 64-byte header every hive file opens with — then hive bins, the 4 KB blocks a hive is allocated in, each holding cells, the variable-length records that everything else is made of. A cell tagged nk is a key node and one tagged vk is a value. Beside the file sit its own .LOG1 and .LOG2 transaction logs, which hold writes Windows has not yet merged into the hive itself. All six are the registry's own machinery, and are taken apart in Windows Registry Internals. What it is not is mounted. No HKEY points at it, regedit will not show it, and the registry API cannot reach it. The only way in is to read the file.

That single fact explains most of the artifact's forensic character. Nothing routinely inspects it, nothing cleans it, and most tooling that touches the registry never sees it at all — which is also why almost everything below had to be measured rather than looked up.

File format

regf

A registry hive like any other, so a reader that understands SYSTEM understands this. Only the contents differ.

Mounted under

no HKEY

Nothing points at it. Regedit cannot show it and the registry API cannot reach it — which is why nothing cleans it either.

Allocation unit

4,096

Bytes per hive bin, always. The hive grows by appending one rather than rewriting the file, which is what leaves deleted entries behind.

Bytes hashed

31,457,280

30 MiB and no more. A larger binary's FileId can never equal its published SHA-1, and a non-match there means nothing.

The hive records that make up an AmCache entry

AmCache keeps ordinary typed registry values rather than a packed binary structure, so the byte-level structure that applies is the hive's own - the base block, a hive bin, the nk key node that is an entry, and the vk values hanging off it - plus the one AmCache field with an encoding of its own, FileId. All of it read from Amcache.hve on the reference system.

Click any byte in a map below, or any row of the table beside it, to read the field that byte belongs to, what it decodes to and why it matters. The tabs switch between record types, and the map redraws for whichever one is selected.

Structure is real and measured. The hash shown for FileId is a placeholder of the same length, so every offset still adds up and nothing here identifies the machine it came from.

Figure 1

Where the records sit in the file

The base block, then the hive bins, then the first bin opened up. Every cell below is at its real offset and its real length; the six the map dissects are picked out. Every one of them can be hovered.

allocatedfreed - still holds its contentsdissected below, in its own colour

65 cells in that one bin. The whole hive is bins like it, appended rather than rewritten.

Figure 2

How the records reach each other

Every arrow is a pointer that was read and followed. Hover an arrow or a record to read what it is; click to open its bytes in the map below.

8 pointers, each re-read from the hive when this page was built - an arrow whose target does not carry the signature it claims fails the build rather than being drawn. The dashed links are not pointers: FileId is not a record, it is the content of a key name and of a value.

Figure 3

The records byte by byte

Live Byte Selection

Table 1

Every field of every record

The same fields as a table. Both are drawn from one definition, so the map and the table cannot disagree with each other. Every field has its own write-up: none is shared with another, which the generator now refuses to allow.

Offset	Size	Field	What it is

Table 2

Every key under `Root`, and where it lands

The categories the Appraiser catalogues, what Crow-Eye does with each, and - behind each row - what every one of that table's columns means. Ten keys are stored one row per registry value rather than as fixed columns: DeviceCensus, which carries a couple of hundred distinct value names and gains more every Windows release, and nine that were empty on every system available here. For those nine the columns could not be verified against real data, so none were invented - what the key is FOR is still worth stating, and is stated.

The From column is measured, not asserted, and every column in this table and the next says where it was read from. value ProgramId is a named registry value, spelled as the hive spells it rather than as the database column is named - those differ, because the column name is normalised. Every named value lives in a vk record: its name at vk +0x14, its data reached through vk +0x08, both dissected in Figure 3 above. That is true of all of them, so it is said here once instead of in every row. nk +0x04 and the like are not values at all: they are fields of the records themselves, cited at the offset the byte map gives. from x is normalised from another column in the same table. the carve is neither - it is where a recovered cell sat, or the fact that it was found in free space at all. bookkeeping is parsed_at, which has no origin in the hive and should not appear to have one. value, absent here is a value name the parser expects and this hive does not carry. Names and types only - no values from the reference system appear anywhere on this page.

Key under Root Crow-Eye table Stored as What it holds

DeviceCensus DeviceCensus one row per value Machine identity - Entra device id, activation channel, whether this is a VM. Hundreds of distinct value names, and more with every Windows release.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

DriverPackageExtended DriverPackageExtended one row per value Extended attributes of driver packages, beyond what InventoryDriverPackage records. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryAcpiPhatHealthRecord InventoryAcpiPhatHealthRecord one row per value Firmware component health, as ACPI's Platform Health Assessment Table reports it - a machine's own firmware saying whether a component is failing. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryAcpiPhatVersionElement InventoryAcpiPhatVersionElement one row per value Firmware component versions from the same ACPI table, which is how firmware-level change becomes visible at all. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryApplication InventoryApplication 26 columns Installed programs: install date and source, uninstall string, the Uninstall key, and sometimes the installing user's SID.

What its 26 columns hold

Column	From	Type	What it means
`program_id`	value `ProgramId`	REG_SZ	The identifier for this installed program, and the join key to `InventoryApplicationFile`. Derived by Windows from the name, version, publisher and language, so the same product installed on two machines gets the same one.
`name`	value `Name`	REG_SZ	The display name of the program, as an installer registered it.
`version`	value `Version`	REG_SZ	The program's version string, as its installer declared it.
`publisher`	value `Publisher`	REG_SZ	The publisher string from the installer - not a signature, and not verified by anything. It is whatever was typed.
`language`	value `Language`	REG_DWORD	The installer's language, as a Windows LCID. 65535 means language-neutral.
`source`	value `Source`	REG_SZ	Where Windows learned about this program - `Msi`, `AddRemoveProgram`, `AppxPackage` and others. The published enumerations of this field are incomplete: this hive also carries `AddRemoveProgramPerUser` and `Steam`.
`root_dir_path`	value `RootDirPath`	REG_SZ	The directory the program installed itself into.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`program_instance_id`	value `ProgramInstanceId`	REG_SZ	A per-installation identifier, distinct from `ProgramId`: the same product installed twice gets one ProgramId and two of these.
`store_app_type`	value `StoreAppType`	REG_SZ	For a Store application, which kind it is - `UWP`, `Centennial` and so on. Empty for a desktop installer.
`inbox_modern_app`	value `InboxModernApp`	REG_DWORD	1 when this Store app shipped with Windows rather than being installed. Separates what the image brought from what somebody added.
`manifest_path`	value `ManifestPath`	REG_SZ	Path to the app manifest, for a packaged application.
`package_full_name`	value `PackageFullName`	REG_SZ	The full package identity of a Store app - name, version, architecture and publisher hash in one string.
`install_date`	value `InstallDate`	REG_SZ	The install date as the program's own registration recorded it, as a LOCAL-TIME string in whatever format the installer chose. It is not normalised and not UTC - see `install_date_utc`.
`hidden_arp`	value `HiddenArp`	REG_DWORD	1 when the program hides itself from Add/Remove Programs. Legitimate for components; also exactly what something that does not want to be uninstalled does.
`uninstall_string`	value `UninstallString`	REG_SZ	The command Add/Remove Programs would run to remove it - which names the uninstaller binary, and therefore a path the installer wrote to.
`registry_key_path`	value `RegistryKeyPath`	REG_SZ	The `Uninstall` key this program was read from. It points at the registry evidence directly, so the claim can be checked in SOFTWARE or NTUSER.
`msi_package_code`	value `MsiPackageCode`	REG_SZ	For an MSI install, the package code GUID - it identifies the .msi file itself.
`msi_product_code`	value `MsiProductCode`	REG_SZ	For an MSI install, the product code GUID - it identifies the product, and stays the same across its minor updates.
`msi_install_date`	value `MsiInstallDate`	REG_SZ	The install date MSI recorded, as its own string. Normalised into `msi_install_date_utc` beside it.
`bundle_manifest_path`	value `BundleManifestPath`	REG_SZ	Path to the bundle manifest, for a packaged bundle.
`user_sid`	value `UserSid`	REG_SZ	The SID of the user this program was installed for, when the install was per-user. It attributes an installation to an account, which is why a per-user install is worth more here than a machine-wide one.
`install_date_utc`	from `install_date`	normalised	`install_date` parsed and normalised to UTC by Crow-Eye. The raw string is kept beside it and never overwritten, because the order of its month and day is ambiguous and the original is the only way to check the reading.
`msi_install_date_utc`	from `msi_install_date`	normalised	`msi_install_date` parsed and normalised to UTC. NULL when the string could not be read as a plausible date, rather than guessed at.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryApplicationAppV InventoryApplicationAppV one row per value App-V packages - applications delivered virtualised rather than installed, which leave a different trail from an ordinary install. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryApplicationDriver InventoryApplicationDriver one row per value Drivers shipped as part of an application rather than for a device. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryApplicationFile InventoryApplicationFile 25 columns Every executable the Appraiser has seen: path, SHA-1, size, publisher, and the ProgramId that links it to an installed program.

What its 25 columns hold

Column	From	Type	What it means
`program_id`	value `ProgramId`	REG_SZ	The installed program this file belongs to, or empty. Joins to `InventoryApplication`; when it joins to nothing the binary belonged to no installed program, which is what `program_association` records.
`file_id`	value `FileId`	REG_SZ	The 44-character FileId: four zeros then a SHA-1. The four zeros are not part of the hash - `substr(file_id, 5)` is. It hashes only the first 30 MiB of the file.
`lower_case_long_path`	value `LowerCaseLongPath`	REG_SZ	The full path of the binary, lower-cased. The path AmCache saw; the file itself may be long gone.
`name`	value `Name`	REG_SZ	The file name alone, without its directory.
`binary_type`	value `BinaryType`	REG_SZ	The image's architecture - `pe32`, `pe64_amd64`, `pe32_arm` and so on. A 32-bit binary in a 64-bit system directory is worth a look.
`link_date`	value `LinkDate`	REG_SZ	The PE link timestamp, as a string. It describes when the binary was COMPILED, not when it arrived or ran, and it is attacker-controlled - a value in the future or in 1970 means it was forged, not that a clock was wrong.
`size`	value `Size`	REG_QWORD	The file's size in bytes, as a 64-bit value, when AmCache saw it.
`language`	value `Language`	REG_DWORD	The binary's language resource, as a Windows LCID.
`usn`	value `Usn`	REG_QWORD	The USN journal sequence number of the change that brought this file to the Appraiser's attention. It orders file activity on the volume, and it is the join to the USN journal itself. Explained in full: the USN record
`bin_file_version`	value `BinFileVersion`	REG_SZ	The file version from the PE version resource, as the binary declares it.
`bin_product_version`	value `BinProductVersion`	REG_SZ	The product version from the PE version resource, as the binary declares it.
`product_version`	value `ProductVersion`	REG_SZ	The product version Windows resolved for this file, which can differ from the resource above.
`version`	value `Version`	REG_SZ	The file version Windows resolved for this file.
`product_name`	value `ProductName`	REG_SZ	The product name from the PE version resource. Freely settable by whoever built the binary.
`publisher`	value `Publisher`	REG_SZ	The company name from the PE version resource. It is metadata, not a signature - a binary claiming Microsoft here has proved nothing.
`original_file_name`	value `OriginalFileName`	REG_SZ	The name the binary was BUILT with, from its version resource. When it disagrees with `name` the file was renamed after it was compiled, and that disagreement is one of the cheapest renamed-tool detections there is.
`appx_package_full_name`	value `AppxPackageFullName`	REG_SZ	The Store package this file belongs to, when it belongs to one.
`is_os_component`	value `IsOsComponent`	REG_DWORD	1 when Windows considers this file part of the operating system. It is what separates the image's own binaries from everything added to it.
`appx_package_relative_id`	value `AppxPackageRelativeId`	REG_SZ	The application's identity within its Store package, for a package that ships more than one.
`link_date_utc`	from `link_date`	normalised	`link_date` normalised to UTC by Crow-Eye. Still a compile time - normalising it does not make it an execution time.
`file_id_is_partial`	from `file_id`	normalised	Crow-Eye's own flag: 1 when the file was larger than 30 MiB, so its FileId hashes only the first 31,457,280 bytes and can never equal a published SHA-1. Without it a non-match reads as "not this file". Decided from the cached `size`, so it works against an image with no filesystem; NULL when there is no size, rather than guessed.
`file_id_verified`	from `file_id`	normalised	Crow-Eye re-hashed the file on disk and compared. Only ever populated on a live parse, and only when asked - an offline parse has no filesystem to hash.
`program_association`	value, absent here	-	`associated` when this file's ProgramId resolves to an installed program, `unassociated` when it does not. Unassociated is where dropped and portable binaries live. Computed in one pass after both tables are written, because the files are parsed before the programs.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryApplicationFramework InventoryApplicationFramework one row per value Frameworks an application depends on - runtimes and framework packages that arrive with something else rather than on their own. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryApplicationShortcut InventoryApplicationShortcut 7 columns Shortcuts - a Start menu or desktop presence.

What its 7 columns hold

Column	From	Type	What it means
`shortcut_path`	value `ShortcutPath`	REG_SZ	Where the .lnk sits - a Start menu or desktop location. A shortcut is a presence, not an execution.
`shortcut_target_path`	value `ShortcutTargetPath`	REG_SZ	What the shortcut points at.
`shortcut_aumid`	value `ShortcutAumid`	REG_SZ	The Application User Model ID the shortcut launches, for a packaged or modern app. The same identity the Jump Lists and the taskbar use.
`shortcut_program_id`	value `ShortcutProgramId`	REG_SZ	The installed program this shortcut belongs to, joining back to `InventoryApplication`.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDeviceContainer InventoryDeviceContainer 18 columns Devices as containers, including things attached once.

What its 18 columns hold

Column	From	Type	What it means
`model_name`	value `ModelName`	REG_SZ	The device model as the device reports it.
`icon`	value `Icon`	REG_SZ	The icon resource Windows shows for the device.
`friendly_name`	value `FriendlyName`	REG_SZ	The name a user sees, and often one a user CHOSE - a phone or headset named after its owner attributes the device to a person.
`model_number`	value `ModelNumber`	REG_SZ	The manufacturer's model number for the device.
`manufacturer`	value `Manufacturer`	REG_SZ	The device's manufacturer string.
`model_id`	value `ModelId`	REG_SZ	A GUID identifying the device model.
`primary_category`	value `PrimaryCategory`	REG_SZ	The device's main category - audio, imaging, printer, phone.
`categories`	value `Categories`	REG_SZ	All categories the device claims, not only the primary one.
`is_machine_container`	value `IsMachineContainer`	REG_SZ	1 for the container that represents this computer itself, rather than something attached to it.
`discovery_method`	value `DiscoveryMethod`	REG_SZ	How Windows found the device - USB enumeration, network discovery, pairing.
`is_connected`	value `IsConnected`	REG_SZ	Whether the device was connected when the Appraiser last looked. A snapshot of that moment, not a history.
`is_active`	value `IsActive`	REG_SZ	Whether the device was active at that moment.
`is_paired`	value `IsPaired`	REG_SZ	Whether the device is paired - a Bluetooth device that was deliberately associated with this machine.
`is_networked`	value `IsNetworked`	REG_SZ	Whether the device is reached over the network.
`state`	value `State`	REG_DWORD	The container's state, as a numeric code.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDeviceInterface InventoryDeviceInterface 23 columns Sensor capabilities the machine reports.

What its 23 columns hold

Column	From	Type	What it means
`accelerometer3_d`	value `Accelerometer3D`	REG_SZ	Whether a three-axis accelerometer interface is present. Note the value name: `Accelerometer3D` defeats the obvious CamelCase rule, which is why the parser normalises both sides before matching.
`activity_detection`	value `ActivityDetection`	REG_SZ	Whether an activity-detection sensor is present.
`ambient_light`	value `AmbientLight`	REG_SZ	Whether an ambient light sensor is present - the one that drives automatic screen brightness.
`barometer`	value `Barometer`	REG_SZ	Whether a barometric pressure sensor is present.
`custom`	value `Custom`	REG_SZ	Whether a vendor-defined custom sensor interface is present.
`floor_elevation`	value `FloorElevation`	REG_SZ	Whether a floor-elevation sensor is present.
`geomagnetic_orientation`	value `GeomagneticOrientation`	REG_SZ	Whether a geomagnetic orientation sensor - a compass - is present.
`gravity_vector`	value `GravityVector`	REG_SZ	Whether a gravity-vector sensor is present.
`gyrometer3_d`	value `Gyrometer3D`	REG_SZ	Whether a three-axis gyrometer is present.
`humidity`	value `Humidity`	REG_SZ	Whether a humidity sensor is present.
`linear_accelerometer`	value `LinearAccelerometer`	REG_SZ	Whether a linear accelerometer, with gravity removed, is present.
`magnetometer3_d`	value `Magnetometer3D`	REG_SZ	Whether a three-axis magnetometer is present.
`orientation`	value `Orientation`	REG_SZ	Whether an absolute device-orientation sensor is present.
`pedometer`	value `Pedometer`	REG_SZ	Whether a step-counting sensor is present.
`proximity`	value `Proximity`	REG_SZ	Whether a proximity sensor is present - the one that detects a hand or a face near the device.
`relative_orientation`	value `RelativeOrientation`	REG_SZ	Whether a relative orientation sensor, measured from a starting position, is present.
`simple_device_orientation`	value `SimpleDeviceOrientation`	REG_SZ	Whether the coarse portrait/landscape orientation sensor is present.
`temperature`	value `Temperature`	REG_SZ	Whether a temperature sensor is present.
`energy_meter`	value `EnergyMeter`	REG_SZ	Whether an energy-metering interface is present.
`hinge_angle`	value `HingeAngle`	REG_SZ	Whether a hinge-angle sensor is present - a foldable or dual-screen machine.
`presence_capabilities`	value `PresenceCapabilities`	REG_DWORD	A bitmask of human-presence capabilities: what the machine can detect about somebody sitting in front of it.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDeviceMediaClass InventoryDeviceMediaClass 4 columns Audio render and capture drivers.

What its 4 columns hold

Column	From	Type	What it means
`audio_render_driver`	value `Audio_RenderDriver`	REG_SZ	The driver behind audio OUTPUT - the playback devices.
`audio_capture_driver`	value `Audio_CaptureDriver`	REG_SZ	The driver behind audio INPUT. It names what could record on this machine, which is the half of audio that matters in an investigation.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDevicePci InventoryDevicePci one row per value PCI devices in bus terms - what is physically in the slots. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDevicePnp InventoryDevicePnp 39 columns Devices with InstallDate and FirstInstallDate. Live device properties are denied to a running system, so for a device attached once this is often the only source.

What its 39 columns hold

Column	From	Type	What it means
`model`	value `Model`	REG_SZ	The device model string, as PnP reports it.
`manufacturer`	value `Manufacturer`	REG_SZ	The device manufacturer string, as PnP reports it.
`driver_name`	value `DriverName`	REG_SZ	The driver file serving this device - the join to `InventoryDriverBinary`.
`parent_id`	value `ParentId`	REG_SZ	The device instance this one hangs off. It rebuilds the PnP tree, which is how a USB device is tied to the port and hub it was plugged into.
`matching_id`	value `MatchingID`	REG_SZ	The hardware id the INF actually matched to pick this driver, out of everything the device advertised.
`class`	value `Class`	REG_SZ	The device setup class - `USB`, `DiskDrive`, `Net`, `Keyboard`.
`class_guid`	value `ClassGuid`	REG_SZ	The GUID of that setup class.
`description`	value `Description`	REG_SZ	The device description from its INF.
`enumerator`	value `Enumerator`	REG_SZ	Which bus enumerated it - `USB`, `PCI`, `SWD`, `BTH`. It says how the thing was attached.
`service`	value `Service`	REG_SZ	The kernel service or driver that owns the device, as named in `CurrentControlSet\Services`.
`install_state`	value `InstallState`	REG_SZ	Whether the device installed successfully.
`device_state`	value `DeviceState`	REG_SZ	A bitmask of the device's current PnP state.
`inf`	value `Inf`	REG_SZ	The INF file that installed the driver. An `oem*.inf` name means a third-party driver rather than an in-box one.
`driver_ver_date`	value `DriverVerDate`	REG_SZ	The driver's version date, as the string the INF carries.
`install_date`	value `InstallDate`	REG_SZ	When this device was first installed on this machine. Live device properties are denied even to an elevated process, so for a device attached once and never again this is often the only record that it was here at all.
`first_install_date`	value `FirstInstallDate`	REG_SZ	The first time a device of this kind was installed. It survives a reinstall of the same device, so this and `install_date` disagreeing means the device came back.
`driver_package_strong_name`	value `DriverPackageStrongName`	REG_SZ	The full identity of the driver package - the join to `InventoryDriverPackage`.
`driver_ver_version`	value `DriverVerVersion`	REG_SZ	The driver version the INF declares.
`container_id`	value `ContainerId`	REG_SZ	The container this device belongs to - the join to `InventoryDeviceContainer`. One physical thing shows up as several PnP devices sharing one container id.
`problem_code`	value `ProblemCode`	REG_SZ	The PnP problem code, when the device did not start cleanly. Non-zero is the Device Manager warning triangle.
`provider`	value `Provider`	REG_SZ	Who provided the driver, as the INF declares it.
`driver_id`	value `DriverId`	REG_SZ	The identifier of the driver serving this device.
`bus_reported_description`	value `BusReportedDescription`	REG_SZ	The description the DEVICE itself reported over the bus, rather than anything the INF said. For a USB stick it is often the only place its own product string is written down.
`hwid`	value `HWID`	REG_SZ	Every hardware id the device advertised, in priority order. For USB it carries the VID and PID, which identify the make and model of the actual thing.
`extended_infs`	value `ExtendedInfs`	REG_SZ	Any extension INFs layered on top of the base driver.
`compid`	value `COMPID`	REG_SZ	The compatible ids the device advertised - the looser match, used when no hardware id matches.
`stackid`	value `STACKID`	REG_SZ	The device stack identifiers.
`upper_class_filters`	value `UpperClassFilters`	REG_SZ	Filter drivers layered above every device of this class. A filter driver is a legitimate mechanism and a well-worn place to sit in the path of a device's data.
`lower_class_filters`	value `LowerClassFilters`	REG_SZ	Filter drivers layered below every device of this class.
`upper_filters`	value `UpperFilters`	REG_SZ	Filter drivers layered above this device specifically.
`lower_filters`	value `LowerFilters`	REG_SZ	Filter drivers layered below this device specifically.
`device_interface_classes`	value `DeviceInterfaceClasses`	REG_SZ	The interface classes this device exposes - what it lets software ask of it.
`location_paths`	value `LocationPaths`	REG_SZ	Where the device physically sits, as a path through the buses - which PCI slot, which USB port.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`install_date_utc`	from `install_date`	normalised	`install_date` normalised to UTC by Crow-Eye, with the raw string kept beside it.
`first_install_date_utc`	from `first_install_date`	normalised	`first_install_date` normalised to UTC by Crow-Eye.
`driver_ver_date_utc`	from `driver_ver_date`	normalised	`driver_ver_date` normalised to UTC. It dates the DRIVER, not the installation.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDeviceSensor InventoryDeviceSensor one row per value Sensors as devices, as opposed to InventoryDeviceInterface, which records only which sensor capabilities exist. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDeviceUsbHubClass InventoryDeviceUsbHubClass 4 columns How many user-connectable USB ports the machine has.

What its 4 columns hold

Column	From	Type	What it means
`total_user_connectable_ports`	value `TotalUserConnectablePorts`	REG_DWORD	How many USB ports a person can physically reach on this machine. It bounds how many things could have been plugged in at once.
`total_user_connectable_type_cports`	value `TotalUserConnectableTypeCPorts`	REG_DWORD	How many of those ports are Type-C. The value name is `TotalUserConnectableTypeCPorts`, which no CamelCase rule splits correctly - the second reason the parser normalises both sides.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDriverBinary InventoryDriverBinary 23 columns Drivers, with signing state. Where an unsigned driver shows up.

What its 23 columns hold

Column	From	Type	What it means
`driver_name`	value `DriverName`	REG_SZ	The driver file's path. This is the row a suspicious kernel driver appears in.
`inf`	value `Inf`	REG_SZ	The INF that installed it. An `oem*.inf` name means third-party.
`driver_version`	value `DriverVersion`	REG_SZ	The driver's version string.
`product`	value `Product`	REG_SZ	The product the driver belongs to.
`product_version`	value `ProductVersion`	REG_SZ	The product version from the driver's version resource.
`wdf_version`	value `WdfVersion`	REG_SZ	The Windows Driver Framework version it was built against, when it uses WDF at all.
`driver_company`	value `DriverCompany`	REG_SZ	The company named in the driver binary's version resource. Metadata, not a signature.
`driver_package_strong_name`	value `DriverPackageStrongName`	REG_SZ	The driver package this binary came from - the join to `InventoryDriverPackage`.
`service`	value `Service`	REG_SZ	The service name the driver runs under, in `CurrentControlSet\Services`.
`driver_in_box`	value `DriverInBox`	REG_SZ	1 when the driver shipped with Windows. Everything else was put here by somebody.
`driver_signed`	value `DriverSigned`	REG_SZ	Whether the driver is signed. This is where an unsigned kernel driver becomes visible - and note the name: several published references call this field `DigitalSignature`, which does not exist in the hive.
`driver_is_kernel_mode`	value `DriverIsKernelMode`	REG_SZ	1 for a kernel-mode driver. Kernel mode is the difference between a bad program and a bad machine.
`driver_id`	value `DriverId`	REG_SZ	The driver's identifier, joining back to the PnP devices.
`driver_last_write_time`	value `DriverLastWriteTime`	REG_SZ	The driver file's last write time, as a string. Published references call this field `LastModified`; the hive does not.
`driver_type`	value `DriverType`	REG_DWORD	A bitmask describing what kind of driver this is.
`driver_time_stamp`	value `DriverTimeStamp`	REG_DWORD	The driver's PE link timestamp, as a Unix epoch integer - not a FILETIME, and not the same encoding as the string dates elsewhere in this table.
`driver_check_sum`	value `DriverCheckSum`	REG_DWORD	The PE header checksum of the driver image.
`image_size`	value `ImageSize`	REG_DWORD	The size of the driver image in memory, in bytes.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`driver_last_write_time_utc`	from `driver_last_write_time`	normalised	`driver_last_write_time` normalised to UTC by Crow-Eye.
`driver_time_stamp_utc`	from `driver_time_stamp`	normalised	`driver_time_stamp` converted from its Unix epoch to UTC by Crow-Eye. Reading it as a FILETIME instead produces a plausible date in the wrong century, with no error.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryDriverPackage InventoryDriverPackage 17 columns Driver packages - INF, provider, hardware ids.

What its 17 columns hold

Column	From	Type	What it means
`class_guid`	value `ClassGuid`	REG_SZ	The setup class GUID the package installs into.
`class`	value `Class`	REG_SZ	The setup class name.
`directory`	value `Directory`	REG_SZ	The DriverStore directory the package was staged into. The package survives there after the device is gone.
`date`	value `Date`	REG_SZ	The package's date, as the string the INF carries.
`version`	value `Version`	REG_SZ	The driver package version.
`provider`	value `Provider`	REG_SZ	The provider named in the INF.
`submission_id`	value `SubmissionId`	REG_SZ	The Windows Hardware submission id, for a package that went through Microsoft's signing process. A third-party package with none did not.
`driver_in_box`	value `DriverInBox`	REG_SZ	1 when the package shipped with Windows.
`inf`	value `Inf`	REG_SZ	The INF file name of the package.
`flight_ids`	value `FlightIds`	REG_SZ	Flighting identifiers, when the package came through one.
`recovery_ids`	value `RecoveryIds`	REG_SZ	Recovery identifiers associated with the package.
`is_active`	value `IsActive`	REG_SZ	Whether this package is the one currently serving its devices. Superseded packages stay in the store.
`hwids`	value `Hwids`	REG_SZ	Every hardware id this package claims to drive.
`sysfile`	value `SYSFILE`	REG_SZ	The driver system file the package installs.
`date_utc`	from `date`	normalised	`date` normalised to UTC by Crow-Eye, with the raw string kept beside it.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryMiscellaneous InventoryMiscellaneous 4 columns Assorted per-machine flags.

What its 4 columns hold

Column	From	Type	What it means
`exists`	value `Exists`	REG_DWORD	Whether the thing this row is about is present. The row's key name says what that thing is; this is the answer.
`value`	value `Value`	REG_SZ	The measurement itself, for a row that carries one rather than a yes/no.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryMiscellaneousMemorySlotArrayInfo InventoryMiscellaneousMemorySlotArrayInfo 13 columns Physical memory slots.

What its 13 columns hold

Column	From	Type	What it means
`slot`	value `Slot`	REG_DWORD	Which physical memory slot this row describes.
`type`	value `Type`	REG_DWORD	The memory type, as an SMBIOS code - DDR4, DDR5 and so on.
`type_details`	value `TypeDetails`	REG_DWORD	SMBIOS type detail bits for the module.
`speed`	value `Speed`	REG_DWORD	The module's rated speed.
`capacity`	value `Capacity`	REG_QWORD	The module's capacity in bytes, as a 64-bit value.
`model`	value `Model`	REG_SZ	The memory module's model, as the module reports it.
`manufacturer`	value `Manufacturer`	REG_SZ	The memory module's manufacturer.
`total_width`	value `TotalWidth`	REG_DWORD	The module's total data width in bits, including ECC.
`data_width`	value `DataWidth`	REG_DWORD	The module's data width in bits, excluding ECC. Compared with the total width it says whether the module carries error correction.
`memory_error_correction`	value `MemoryErrorCorrection`	REG_DWORD	The error-correction scheme, as an SMBIOS code.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryMiscellaneousUser InventoryMiscellaneousUser 7 columns Per-user identifiers such as AdvertisingID.

What its 7 columns hold

Column	From	Type	What it means
`original_name`	value `OriginalName`	REG_SZ	What this per-user item is - the key's own subject, such as an advertising identifier.
`exists`	value `Exists`	REG_DWORD	Whether the item is present for this user.
`value`	value `Value`	REG_SZ	The identifier itself. This is where the AdvertisingID lands - a per-user value that follows the account rather than the machine.
`user_id`	value `UserId`	REG_DWORD	The local identifier of the user this row belongs to.
`standard_user_hash`	value `StandardUserHash`	REG_DWORD	A hash standing in for the user's identity, so the telemetry can be per-user without carrying a name.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryMiscellaneousUUPInfo InventoryMiscellaneousUupInfo 8 columns Update packages.

What its 8 columns hold

Column	From	Type	What it means
`identifier`	value, absent here	-	The update package's identifier.
`version`	value, absent here	-	The version this update package delivers.
`source`	value, absent here	-	Where the update came from - the servicing channel. Not an install source: the same column name in `InventoryApplication` means something else.
`previous_version`	value, absent here	-	The version being replaced. With `version` it gives the before and after of a servicing step, and dates when the image changed.
`last_activated_version`	value, absent here	-	The last version actually activated.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

InventoryMiscellaneousWAMAccounts InventoryMiscellaneousWAMAccounts one row per value Web Account Manager accounts - the Microsoft, work and school accounts this machine has signed in. Empty here, so its columns are stored one row per value.

What its 5 columns hold

Column	From	Type	What it means
`entry`	nk +0x4C	key name	The key this row came from - the subkey name under this Root key. Every row of one entry shares it, which is how the rows are grouped back into an entry.
`name`	vk +0x14	value name	The registry value's name, exactly as the hive spells it.
`value`	vk +0x08 → data	value data	The registry value's data, as text.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

Mare Mare 10 columns Compatibility entries. The real install directory is inside the restore value; sdbentryguid names the shim database entry.

What its 10 columns hold

Column	From	Type	What it means
`flags`	value `flags`	REG_DWORD	The compatibility flags applied to this entry.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`restore`	value `restore`	REG_SZ	A delimited blob, and the useful field is inside it - `RootDirPath\|C:\...;AddPlaceholderCustom\|...`. Kept whole, because a decode should be checkable against the original.
`root_dir_path`	value, absent here	-	The real install directory, decoded out of `restore` by Crow-Eye. A decode of a field that is present, not a reconstruction: it stays NULL when `restore` carries no RootDirPath. It replaced a path that was being built by hand, and the difference is measurable - 245 of 362 of these exist on disk, against 0 of 200 of the invented ones.
`sdbentryguid`	value `sdbentryguid`	REG_SZ	The shim database entry this compatibility fix comes from. It names the entry inside the SDB, which is where a custom shim database - an old and still-working persistence technique - would show up.
`path`	value `path`	REG_SZ	The path of the executable this compatibility entry is about.
`program_id`	value `programId`	REG_SZ	The installed program this entry belongs to, joining to `InventoryApplication`. Note the hive spells it `programId` here and `ProgramId` elsewhere - one of the reasons column matching is case-insensitive.
`far`	value `far`	REG_QWORD	A 64-bit value the compatibility layer keeps with the entry.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's key. In `Mare` specifically it orders nothing: on the reference system EVERY row shares one timestamp, because the Appraiser wrote them in a single batch.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

MareBackupApps MareBackupApps 5 columns Carries SidState, which contains a user SID.

What its 5 columns hold

Column	From	Type	What it means
`hash`	value `Hash`	REG_QWORD	A 64-bit hash identifying the backed-up application entry.
`sid_state`	value `SidState`	REG_SZ	Carries a user SID, which is what makes this small table worth reading: it attributes the entry to an account.
`default_value`	value (unnamed)	varies	The key's unnamed default value. Read because a value with no name is still a value, and most AmCache readers drop it silently.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

Table 3

Three tables that are not keys under `Root`

Crow-Eye writes these itself. They carry no value the Appraiser wrote, which is exactly why they are worth reading: two of them are entries somebody deleted, and the third is the evidence that nothing was quietly skipped. Every column below is read from the carved record itself, or from where it was found, and the From column names which.

Crow-Eye table Stored as What it holds

AmcacheCarvedKeys 9 columns Deleted entries recovered from freed cells. No reference AmCache parser produces this at all. It needs free space to read, so it pays off on a hive taken from an image or a shadow copy - a live export is a reorganised hive whose free space has already gone, and the parse says so rather than reporting nothing.

What its 9 columns hold

Column	From	Type	What it means
`cell_offset`	the carve	file offset	Where in the hive file the recovered cell sits. It is the row's provenance - the claim can be checked by going back to that offset in the evidence.
`key_name`	nk +0x4C	key name	The deleted key's own name, still sitting in the freed cell. For a file entry that name IS the FileId.
`key_path`	nk +0x10 chained	path	The path the key had, when the chain of parents up to a surviving key could be walked.
`parent_resolved`	from `key_path`	flag	Whether that walk succeeded. When it did not, the key is recorded without a path rather than being given a guessed one.
`key_last_write`	nk +0x04	FILETIME	The deleted key's LastWriteTime, recovered with it - when the Appraiser wrote the entry that somebody later removed.
`subkey_count`	nk +0x14	UInt32	How many subkeys the deleted key claimed.
`value_count`	nk +0x24	UInt32	How many values the deleted key claimed.
`record_state`	the carve	always deleted	How the record was found - which is the difference between a cell that was freed and one that was only unlinked. It is the honesty column: it says what kind of recovery this row is.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

AmcacheCarvedValues 10 columns The values belonging to those recovered entries, grouped back onto them by the cell offset of their parent key.

What its 10 columns hold

Column	From	Type	What it means
`cell_offset`	the carve	file offset	Where in the hive file this recovered value cell sits.
`parent_cell_offset`	the carve	file offset	The cell offset of the key this value belonged to, which is how recovered values are grouped back into recovered entries.
`key_path`	nk +0x10 chained	path	The path of that parent key, when it could be resolved.
`value_name`	vk +0x14	value name	The deleted value's name.
`value_type`	vk +0x0C	REG_* code	The registry type the deleted value declared.
`data_size`	vk +0x04	UInt32	How many bytes of data the value declared.
`is_inline`	vk +0x04 bit 31	flag	1 when the data was four bytes or fewer and stored inside the value record itself rather than in a cell of its own. Inline data survives carving better, because there is no second cell to have been reused.
`data`	vk +0x08 → data	bytes	The recovered data, as text.
`record_state`	the carve	always deleted	How this value record was found.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

UnknownSubkeys 4 columns Anything under Root this parser has no schema for, kept whole. A new Windows release adding a key lands here instead of being dropped in silence.

What its 4 columns hold

Column	From	Type	What it means
`subkey_name`	nk +0x4C	key name	The name of a key under `Root` that this parser has no schema for. It is the coverage column: a new Windows release adding a key shows up here instead of being dropped in silence.
`data`	nk +0x28 → values	JSON	Everything that key held, kept as text so nothing is lost.
`key_last_write`	nk +0x04	FILETIME	The LastWriteTime of this entry's own registry key: when the Appraiser wrote the entry. The Appraiser writes in batches, so how much ordering it supports varies by table - see the `nk` tab above.
`parsed_at`	bookkeeping	-	When Crow-Eye read the hive. Bookkeeping - it belongs on no timeline and describes the examination, not the evidence.

Where these figures come from. The figures here were measured from the Amcache.hve of a live Windows 11 system - the reference system. The file hash is replaced by a placeholder of the same length; the key counts, value counts and sizes are real.

What the hive contains

AmCache is written by the Application Experience service, whose job is to know what software is on the machine so compatibility fixes can be applied to it. The hive is that knowledge, written down. Every key under Root is a category of thing the service catalogues.

Each of those categories is one key under Root, and each thing catalogued is one key beneath that, with its properties as registry values. There is no packed record format to decode: the registry already provides one, which is why Figure 3 maps hive records rather than AmCache ones.

How it gets written

Nothing writes AmCache as programs run. The Microsoft Compatibility Appraiser - a scheduled task running compattelrunner.exe - wakes on its own schedule, walks what it is configured to look at, and writes what it found. Three consequences follow from that single fact, and they explain most of the mistakes made with this artifact:

Entries appear late. A program installed after the last run is simply not there yet. Absence is not evidence of absence - it is evidence about when the Appraiser last ran.
Timestamps come in batches. The key write time is when the Appraiser recorded the entry, not when anything ran, and it writes a whole category at once. On the device, driver and compatibility tables the batching is near total: all 373 Mare entries on the reference system share one timestamp, as do all 16 device containers, 399 of 445 driver binaries and 269 of 292 PnP devices. Ordering within those tables carries no information. InventoryApplicationFile is the exception, with 1,086 distinct write times across 5,212 entries.
It is an inventory, not a log. The Appraiser records what it scanned, what an installer copied, and what needed a compatibility shim. Only the last implies the program ran.

What survives that process is unusually durable. Deleting the file does not remove its entry, so AmCache routinely describes binaries that are no longer on disk: 790 of the 2,423 recorded paths on the reference system, 32.6 per cent, no longer resolve to a file.

The association between a file entry and an installed program is weaker than it is often taken to be. On the reference system 3,786 of 5,212 file entries - 72.6 per cent - carry a ProgramId that matches no InventoryApplication row, so “belongs to no installed program” describes most of the table and separates almost nothing. Narrowing it to entries that also hold an on-disk path and are not flagged IsOsComponent leaves 930 entries, 17.8 per cent, and that is the population in which a dropped or portable executable would sit.

A file entry, field by field

Table 4

Entries are not uniform in size, and the distribution is bimodal. Of the 5,212 file entries on the reference system, 2,789 hold no path at all: every one carries an AppxPackageFullName, and each is described by one or two values. The remaining 2,423 hold a path and carry a median of 16 values, ranging from 8 to 18. The table below lists the value names of the second population. The names are the schema; the contents belong to the reference system and are not reproduced.

Value	What it holds	Worth knowing
FileId	the file's SHA-1	prefixed with four zeros. A lookup against the unmodified string matches nothing
LowerCaseLongPath	full path, lowercased	lowercasing is lossy on a case-sensitive comparison
Name	the file name	as catalogued, which may differ from the path's tail
Size	file size in bytes	a cheap first check against a suspected binary
LinkDate	PE compile time	from the binary's own header, and trivially forged
BinaryType	PE32 or PE64	-
ProductName, ProductVersion, Publisher	version resource	attacker-controlled: it is whatever the binary claims
Usn	USN journal record number	ties the entry to the file system journal, if it still holds that record
ProgramId	link to InventoryApplication	how a file joins to the program that installed it

FileId is not a hash until the prefix is removed

FileId is the SHA-1 with four leading zeros in front of it. Submitted to a hash set unmodified it matches nothing, and the negative result is readily misread as evidence that the file is not known malware when it establishes only that the string submitted was not a hash. The failure is silent and its direction is towards a clean verdict, which is what makes it consequential.

What an entry supports, and what it does not

Presence, not execution

An AmCache entry means the Application Experience service catalogued the file. That happens at install time, during scheduled inventory scans, and when the file is examined - not only when it runs. Treating every entry as an execution turns a list of what was on the disk into a list of what someone did, and those are different claims.

The timestamps come from several different clocks

LinkDate is from the PE header and is whatever the compiler wrote, or whatever an attacker set. The key's own last-written time is when the service catalogued it. The install date on the parent program entry is a third thing again. They are routinely quoted interchangeably and they mean quite different things.

Where it is strong: AmCache is one of the few places a deleted binary leaves a SHA-1 behind. The file is gone, Prefetch may have rolled over, but the inventory still names it, sizes it and hashes it. For an executable that ran once and was cleaned up, it is often the only surviving fingerprint.

How Crow-Eye reads the hive

Two paths, sharing one schema. Against a collected image or a hive file it opens Amcache.hve and replays its .LOG1 and .LOG2 first, because AmCache is written continuously and a copy taken from a running machine is mid-transaction by default. Skipping that replay is how an inventory ends up missing its most recent entries, which are exactly the ones an incident is about.

On a live machine it exports the hive with backup privilege (NtSaveKeyEx) and does not replay anything - there is nothing to replay. That export is a snapshot of the hive as the kernel currently holds it, which already contains everything the logs would have applied. Handing that open handle to the replay step instead of a path is not a subtle mistake: it raised TypeError and the entire live AmCache parse produced nothing.

The registry internals guide covers the hive format underneath, the transaction logs, and how records deleted from a hive can still be recovered from its freed cells.

Schema changes across Windows releases

Table 5

The schema has been replaced twice. Each row below records a change that alters what a reader may conclude, not only how the bytes are arranged; a parser written against one schema returns nothing against another, and does so without error.

Windows	What changed	What it means for a reader
7	`RecentFileCache.bcf` - a flat file, no hashes	Paths only. Not a hive and not comparable.
8	`Amcache.hve` arrives, keyed by `File\{volume GUID}`	The old schema. `101` is the SHA-1, `15` the path. Numbered value names, not readable ones.
10 (1607+)	The `Inventory*` schema replaces it	Anything written before 2016 uses value names that no longer exist. Parsers that only know one schema return nothing on the other, with no error.
10 and 11	`InventoryApplicationFile`, `InventoryDriverBinary`, `InventoryDeviceContainer` and more	26 keys under `Root` on the reference system.

Reference

Keys of primary interest

Table 6

The full list of keys and the table each is written to appears in Table 2. The keys below carry the highest evidential density on the reference system.

Key under Root	Holds
`InventoryApplicationFile`	Executables: path, SHA-1, size, publisher, link date, and the `ProgramId` that joins a file to the program that installed it.
`InventoryApplication`	Installed programs, install date and source, the uninstall string, the registry key it registered under, and on some entries the SID of the user who installed it.
`InventoryDriverBinary`	Drivers, with signing state. Where an unsigned driver shows up.
`InventoryDevicePnp`	Devices with `InstallDate` and `FirstInstallDate`, manufacturer and hardware id. Live device properties are denied to a running system, so for a device attached once this is often the only source.
`InventoryDeviceContainer`	Devices as containers, including things attached once.
`InventoryApplicationShortcut`	Shortcuts, which imply a Start menu or desktop presence.
`Mare`	Compatibility entries. The real install directory is inside the `restore` value, not in a field of its own.
`MareBackupApps`	Carries `SidState`, which contains a user SID.
`DeviceCensus`	Machine identity - Entra device id, activation channel, whether it is a VM. Hundreds of distinct value names, and more with every Windows release.

Commonly misread fields

Table 7

Field	Reads like	Actually is
`FileId`	A SHA-1	Four zeros followed by a SHA-1. The unmodified string matches nothing.
`LinkDate`	When the file arrived	The PE compile timestamp, set by the linker and trivially forged.
`Usn`	A timestamp	A USN journal sequence number. Orders events, is not a clock.
`ProgramId`	An identifier of the file	An identifier of the installed PRODUCT. Many files share one.
Key's last-written time	When the program ran	When the inventory scan wrote the key.

Anti-forensic handling, and what survives it

Table 8

The preceding sections describe what an intact hive supports. This section describes the hive after an attempt to remove or evade it, which is the condition in which it is frequently encountered. In most rows the attempt leaves a trace of its own.

Technique	What is done	What survives
Deleting the file	The binary is removed after use.	This is what AmCache is for. The entry and its SHA-1 survive the file, which is often the only remaining identification of something that is gone.
Deleting Amcache.hve	The hive itself is removed.	Windows rebuilds it, and the rebuild is dated. A hive far younger than the operating system is an anomaly worth explaining.
Running from removable media	The binary never resided on the system disk.	The entry still records the path it ran from, including the drive letter, which pairs with the USB history in the registry.
Trusting an absence	The program is not in AmCache.	Not evidence it did not run. The inventory is written by a scheduled task, so a binary that ran and was deleted before the next scan never appears at all.

What this page covers

An unmounted registry hive

The hive records that make up an AmCache entry

Where the records sit in the file

How the records reach each other

The records byte by byte

Every field of every record

Every key under Root, and where it lands

Three tables that are not keys under Root

What the hive contains

How it gets written

A file entry, field by field

FileId is not a hash until the prefix is removed

What an entry supports, and what it does not

Presence, not execution

The timestamps come from several different clocks

How Crow-Eye reads the hive

Schema changes across Windows releases

Reference

Keys of primary interest

Commonly misread fields

Anti-forensic handling, and what survives it

Every key under `Root`, and where it lands

Three tables that are not keys under `Root`