$LogFile Format 1.1 vs 2.0: What Changed in Windows 8
NTFS log format 1.1 and 2.0 side by side: tail pages vs 32 fast pages, where the circular area starts, why live captures show 2.0, and what parsers must do.
TL;DR. Both versions start with two RSTR restart pages. LFS 1.1 (Windows XP–7, and Windows 8+ after a clean shutdown) follows them with two tail pages — copies of the page being written — and starts the circular area at 0x4000 (4 KiB pages). LFS 2.0 (Windows 8+ while mounted) uses 32 fast pages instead and starts the circular area at 0x22000. On a live capture, the newest records can exist only in the tail or fast area. A parser that ignores it loses the most recent activity; one that assumes the wrong version misreads the file.
The version is in the restart page header: minor version at 0x1A, major at 0x1C (libfsntfs, ntfs3). Everything else in this article follows from that one number.
The two layouts
| LFS 1.1 | LFS 2.0 | |
|---|---|---|
| Restart pages | 0x0000, 0x1000 | 0x0000, 0x1000 |
| Special area | 2 tail pages (0x2000, 0x3000) | 32 fast pages (0x2000–0x21FFF) |
| Circular area starts at | 4 × page size = 0x4000 | 0x22 × page size = 0x22000 |
| How a special page says which circular page it copies | In the page header's LSN field | Explicit file offset at 0x3C of the RCRD header |
| Typical source | XP–7; Windows 8+ after a clean shutdown | Windows 8+ while mounted |
The offsets are those used by the Linux ntfs3 driver (first_page = major_ver >= 2 ? 0x22 * page_size : …), which replays both versions.
Tail pages (1.1)
The LFS writes log records into the current page of the circular area. Rewriting that page in place on every new record risks a torn write destroying records already committed on it. LFS 1.1 protects against this with two tail pages: the current page is written to the special area first, and to its circular position later. As dfir.ru describes it, the special area holds two copies of the current record page.
For an analyst, the consequence is simple: the newest page of a live 1.1 log may be more complete in the tail area than in the circular area.
Fast pages (2.0)
Windows 8 changed the special area to 32 pages. Instead of rewriting the current page, the LFS writes updated pages to an unused slot in the fast-page area and only later to the circular area, which reduces writes to the circular area. Older versions of the same page stay in the fast area and can serve recovery after a torn write (again per dfir.ru).
Each fast page carries the file offset of the circular page it stands for, at 0x3C in the RCRD header (file_off in ntfs3, "used when major version >= 2"). That field is how a parser knows where a fast page belongs.
Why a live capture looks different from a dead-box image
dfir.ru notes that the log version is downgraded to 1.1 during a clean shutdown by default. So on the same Windows 11 machine:
| Capture | Version you will usually see | Special area |
|---|---|---|
| Live (KAPE, Velociraptor, FTK Imager on the running host) | 2.0 | Fast pages, possibly holding the newest page |
| Image after clean shutdown | 1.1 | Tail pages |
| Image after crash or hard power-off | 2.0 | Fast pages, as left at the crash |
The restart area also carries a flag the in-browser parser reads as "cleanly dismounted" (bit 0x2 of the restart-area flags); on a live capture or after a crash it is clear. Together, the version and that flag tell you a lot about how the evidence was captured — worth noting in your report.
What a parser must do
- Read both restart pages, validate their update sequence arrays, and use the one with the higher current LSN.
- Take the major version from it and compute where the circular area starts.
- Read every circular page.
- Read the tail or fast pages, find which circular page each stands for, and replace the circular page when the special copy is newer.
- Only then find records, reassembling those that span pages or wrap from the end of the file back to the start of the circular area.
The in-browser parser does exactly this and reports "N newest page(s) read from the tail / fast-page area" in its header line. On its synthetic sample (LFS 2.0, captured live), one page came from the fast area; without it, the last events of the fictional intrusion would be missing. It does not yet extract older copies of pages that may linger in the fast area — a possible source of extra records.
Pitfalls
- Hard-coding
0x4000. A 1.1-only parser run on a 2.0 log treats the fast pages as circular pages and misplaces or duplicates records. - Ignoring the special area. The newest page of a live capture may be there only.
- Assuming 4 KiB. System and log page sizes are in the restart page header (
0x10,0x14); read them. - Trusting a
CHKDpage. A restart page with theCHKDsignature means chkdsk worked on the log; treat the contents with care.
dfir.ru also mentions a planned version 3.0 for DAX volumes using CRC32 checksums instead of update sequence arrays. Neither the Linux driver nor this site's parser handles it; if you ever see major version 3, expect parsers to refuse the file.
Frequently asked questions
Which Windows versions use $LogFile version 2.0?
Windows 8 and later use log format 2.0 while an NTFS volume is mounted. By default the log is downgraded to 1.1 on a clean shutdown, so an image of a cleanly shut down Windows 10 or 11 disk can show 1.1 while a live capture shows 2.0.
Why does a parser need to know the log version?
The version decides where the circular record area starts (0x4000 or 0x22000 with 4 KiB pages) and how the tail or fast pages map to circular pages. Reading a 2.0 log with 1.1 assumptions treats the 32 fast pages as ordinary records and misplaces the newest data.
Further reading
- Maxim Suhanov, How the $LogFile works? — the source for the 1.1/2.0 behaviour described here.
- Linux kernel,
fs/ntfs3/fslog.c—log_init_pg_hdr, tail-page handling andRECORD_PAGE_HDR.file_off.