How Far Back Does the $LogFile Go? Limits and Pitfalls
NTFS $LogFile retention in practice and its other blind spots: no clock, missing names, metadata only, rewritten by chkdsk or ntfs-3g, parsers that disagree.
TL;DR. $LogFile is a circular buffer of about 64 MiB on most current volumes. On a busy system drive that is minutes to hours of history; on a secondary or removable drive it can be much more. Besides retention, it has four structural blind spots: no clock time, names only when they change, metadata only (no non-resident content), and fragility (chkdsk, ntfs-3g and your own activity rewrite it). Parsers also disagree on details. Use it for the last window of activity, and pair it with the USN journal, the $MFT and shadow copies.
None of this makes the log less useful. It makes it a precise instrument with a short range, and reports that forget the range get challenged.
Retention: what the numbers look like
| Factor | Effect |
|---|---|
| Log size | Default is usually around 64 MiB on current Windows volumes; chkdsk /L shows or changes it (Microsoft Learn). Older or small volumes can be smaller — Microsoft's own chkdsk example shows 22,544 KB (KB 814594) |
| Metadata churn | Every file create, rename, delete, attribute or index change consumes log space. Browsers, updates, AV scans, indexing and SRUM all churn |
| Volume role | System volumes churn most; data and removable volumes least |
| Checkpoints | Table dumps written at each checkpoint consume space too |
Published observations:
- Maxim Suhanov measured the time for old data to be overwritten on Windows 10: 16 minutes in one test, 5 hours 20 minutes in another (How the $LogFile works?).
- Joakim Schicht's LogFileParser readme expects "a few hours" on a frequently used system drive and much more on external or secondary disks.
- TZWorks describes a few hours of activity under normal usage for a 64 MB log (mala).
Treat these as orders of magnitude. The only reliable number is the one in your evidence: the parser's LSN range and the oldest dated event.
Getting more history
- Collect early. Before memory-heavy triage, before copying tools onto the host.
- Every volume. A USB drive or a data volume may still hold yesterday.
- Volume Shadow Copies. Each snapshot contains an older
$LogFile. Parse each and label it with the snapshot time. - Readiness. On systems you administer, a larger log (
chkdsk C: /L:<size in KB>) keeps more history. LogFileParser's readme giveschkdsk D: /L:2097152as an example for 2 GB. Test the performance impact first, and never do this on a system you are about to acquire.
Blind spot 1: no clock
LFS records carry LSNs, not times. Any time a parser shows comes from inside the logged data:
| Event | Time source | Reliability |
|---|---|---|
| Creation | $FILE_NAME created in the FILE record or index entry | Good |
| Rename / move | $FILE_NAME changed | Good |
$SI change | New $SI value | Good unless backdated (timestomping) |
| Deletion | Last known time of the file | Lower bound only |
| Anything else | Nearest dated neighbour (≈) | Approximate |
The in-browser $LogFile parser labels every event with its time source for this reason. For exact times, correlate with $UsnJrnl:$J (USN journal parser) and compare the artifacts.
Blind spot 2: names are not always there
Most records name an MFT entry, not a file. Names appear when an index entry is added or removed (create, rename, delete) or when a full FILE record is written. A timestamp change on a file created last week comes with an entry number only. The $MFT of the same volume resolves the rest; without it, paths start with [MFT #n]. If the $MFT was collected later than the log, reused entries can resolve to the wrong names — check sequence numbers.
Blind spot 3: metadata only
- Non-resident file content never passes through the log.
- Small, resident files may appear in FILE record images or attribute creations. LogFileParser's documentation adds that on modern Windows later changes to resident data are generally not logged with their content.
- File reads are not logged (last-access updates are metadata but are often disabled or deferred).
Blind spot 4: it is easy to destroy
- Your own activity. Every file you write on the evidence volume adds log records.
- chkdsk. Can modify or resize the log; a restart page signed
CHKDis the tell. - Linux ntfs-3g. When asked to mount a volume that was not cleanly closed with its recovery option, ntfs-3g "empties" the log by filling it with
0xFF(ntfs_logfile_resetin libntfs-3g). Always attach evidence read-only. - Hard power-off vs clean shutdown. A clean shutdown on Windows 8+ writes the log back as version 1.1 (format versions); a crash leaves the 2.0 fast pages in place. Neither destroys records by itself, but they change where the newest page lives.
Blind spot 5: parsers disagree
The format is documented only by reverse engineering. Real differences between tools include:
- whether tail/fast pages are merged, and how;
- which side (redo or undo) of an index deletion holds the entry;
- open attribute table entry layouts;
- grouping records into actions (transactions vs proximity);
- partial
$SIupdates.
The in-browser parser is honest about its own status: it is validated against synthetic logs built from the published layouts (Linux ntfs3, libfsntfs, dfir.ru), not yet against a corpus of real Windows logs. It groups by MFT entry within a record window rather than by transaction, assumes $SI at offset 0x38 when the record layout is unknown, does not follow attribute lists, and does not check sequence numbers when resolving paths from the $MFT. Confirm important findings with a second tool — see $LogFile parsers compared.
Writing limits into the report
A sentence per finding is enough:
The NTFS transaction log covers LSN 115720 to 117880; the oldest dated event is 09:58:12 UTC. Activity before that time is not represented in this artifact. Log records carry no timestamps; times given are taken from file-system timestamps inside the records, as indicated per event.
Frequently asked questions
How far back does the NTFS $LogFile go?
It depends on log size and activity. The log is circular and usually about 64 MiB; on a busy system volume it may cover minutes to a few hours, on a quiet data or removable volume much longer. Published Windows 10 tests saw old data overwritten after 16 minutes in one case and 5 hours 20 minutes in another.
Can the $LogFile be made to keep more history?
Yes, as a readiness measure before an incident: chkdsk /L:size changes the log size on an NTFS volume. A larger log keeps more history. Do not run it on a volume you are about to acquire as evidence, since it modifies the log.