WAC 2.0.1

WAC 2.0.1 — bugfix release

Fixed: an entry of a hive's transaction log was dropped at each replay

A hive's sequence number is the number of the next log entry it expects, not of the last one it holds. WAC 2.0.0 treated the entry carrying that number as already applied, and skipped it. The replayed hive then read without any error, with keys and values missing.

The size of the loss depends on when the collection is taken. In steady state the skipped entry is small, and its pages are often written again by later entries. Minutes after a boot it is the largest one: 113 pages on the SOFTWARE hive measured, with 125 event channels absent and 28 % of the events rendered without their message, their provider missing.

Every hive collected with log entries not yet written to it lost one entry when converted with 2.0.0. The exhibit store is not affected: it holds the hive and its logs as collected. Converting it again with 2.0.1 (--convert=<folder>) gives the corrected registry artefacts.

Also fixed: after the replay, the hive's header now carries the sequence number following the last entry and the data size that entry announces, as Windows leaves it. An entry that grows the hive extends the file, and its pages are bounded by the size it announces.

How it is checked

• WAC's replay is now confronted at every test cycle with Windows' own recovery. The collected hive and its .LOG1/.LOG2 are loaded by reg load, and Windows replays them itself. That hive and the one WAC replayed are both walked whole: same number of keys and values (278 374 and 477 158 for SOFTWARE, 38 943 and 98 225 for SYSTEM in the 2.0.1 cycle), same SHA-256 over every key and value.
• A new test program, hive_recover_test, builds a hive and its logs one letter per page. It runs 11 checks, 4 of which fail on 2.0.0.

Files

Same as 2.0.0: WAC.exe (Windows 10 and 11, x64, standalone), wac.yml, verify-exhibits.ps1|.sh, verifier-consigne.ps1|.sh, raw_hive_test.exe, SHA256SUMS.