One of the most common questions we get from clients goes something like:

"Can you tell us when our subject emptied their Recycle Bin? And whether any of the deleted items are recoverable?"

It sounds like a simple yes/no question. It almost never is. Windows does not maintain a permanent log of Recycle Bin operations — there is no "Bin Emptied at 3:42 PM" line item anywhere on the disk. Answering the question requires correlating several lower-level NTFS artifacts, each with its own retention behaviour and its own quirks.

Here's how we actually do it on a typical Windows forensic image, and where the limits live.

What Windows actually stores

When you press Delete in File Explorer, two things happen inside the hidden C:\$Recycle.Bin\<SID>\ folder for your user account:

  1. The original file is renamed to $R<6 random chars><extension>.
  2. A small companion file $I<same 6 chars><extension> is created, containing the file's original full path, original size, and the deletion timestamp.

So if you ever have to recover something from the bin, you find the $I file (it tells you what the file used to be), then pair it with its $R sibling (the actual data). When the user clicks Empty Recycle Bin, both files are deleted from disk — the $I/$R pair vanishes.

This is the part that matters: a Recycle Bin "empty" looks, at the filesystem level, like a normal file delete on multiple $I and $R files within milliseconds of each other. That's the fingerprint we're hunting for.

The first surprise: there's usually more than one bin

Every Windows account on a machine has its own per-user bin folder under C:\$Recycle.Bin\, named after the user's Security Identifier (SID). On a typical machine you'll find folders for:

A SID looks like S-1-5-21-XXXXXXXX-XXXXXXXX-XXXXXXXX-RID. The three middle numbers identify the machine that originally created the account. If a bin folder's machine portion doesn't match the current Windows install's machine SID, that bin came from somewhere else — typically a backup, a Geek-Squad-style data transfer, or a folder dragged in from an external drive.

In one recent case we found eight distinct bin folders on a single image, in two parent locations. The largest one — over five thousand items — sat inside a third-party data-transfer folder, and every single one of its internal deletion timestamps fell within a seven-minute window from years earlier. That's the unmistakable signature of a one-time bulk migration on a prior PC, not real ongoing activity on the imaged machine. Without that machine-SID check, we'd have reported five thousand "deletions" that never happened on the current computer.

Lesson: before counting anything, identify which bin belongs to which install. The machine portion of the SID is your truth-teller.

"Did they empty it?" — the easy half of the question

If items in the live bin have deletion timestamps older than any suspected empty event, then no full empty has occurred since the oldest surviving item went in. A real "Empty Recycle Bin" operation wipes everything in the bin in one atomic operation — it cannot selectively spare older items.

So the very first thing we check is the oldest surviving $I file. Whatever date that is, it sets a hard floor: the bin has not been fully emptied since that date. This costs nothing and often resolves the client's question on its own.

What it can't tell us is whether anything happened before that floor. For that, we go to the journals.

The USN journal: where empty events actually live

NTFS maintains a Change Journal at \$Extend\$UsnJrnl:$J. Every file create, delete, rename, and security change on the volume gets logged here with a microsecond-precision timestamp. It's the single best place to spot a Recycle Bin empty event.

To extract it from a forensic image, you can either pull it from your AXIOM (or X-Ways, FTK, etc.) File System Explorer view — making sure to grab the $J alternate data stream specifically, not just the $UsnJrnl container — or carve it out with a low-level tool. The raw file is often several gigabytes on a busy disk.

We parse it with Eric Zimmerman's MFTECmd (yes, it parses USN despite the name, with the -f flag). The output is a CSV with one row per change record. To find an empty event, we filter for:

A burst of four FileDelete | Close records on $IXXX/$RXX pairs all at, say, 17:42:57.145 — that's an empty event (or a "delete selected items from bin" operation, which we'll come back to).

The trick you have to know about

There's a critical subtlety. A targeted "delete these specific items from inside the bin" looks almost identical in the USN to a full "Empty Recycle Bin" — the same FileDelete | Close records on $I/$R files in the same sub-millisecond burst.

How do you tell them apart? By checking what didn't get deleted. If older items in the bin survived the burst, it wasn't a full empty — it was selective. The user opened the bin window, highlighted a few items, and pressed Delete. The older $I/$R files would have been wiped too in a true Empty.

We've had cases where this distinction mattered enormously. A targeted bin delete suggests the user was specifically getting rid of two or three items; a full empty suggests routine housekeeping or active destruction. Same forensic fingerprint, very different narrative.

Bonus: recovering the original filename

Once a $I/$R pair is purged, the original filename and path are no longer obvious. But the USN journal also records the rename operation that originally moved the file INTO the bin. Look up the MFT entry number of the $R file in the USN, find the RenameOldName record on the same entry, and there's your original filename. Cross-reference the ParentEntryNumber against the parsed $MFT and you have the original folder path too. This works even after the bin entry is long gone.

What about $LogFile?

The NTFS $LogFile is the transaction log used for crash recovery. It records the same kinds of operations as the USN journal — but it's much smaller, often retaining only minutes to hours of activity. On a recent image we examined, the entire $LogFile covered a 38-minute window.

It can corroborate something the USN journal shows. It almost never adds history the USN journal doesn't already have. We always extract and parse it, but we don't lean on it.

When the $MFT helps (and when it doesn't)

When $I and $R files are deleted on an empty event, their Master File Table records are marked free. Until those records get reused by some other file, they still bear the $I/$R filename and the timestamps that record when they were purged.

In practice: on a busy Windows install that's been running for months, freed MFT records get reused quickly. On a recent case we saw 70,000+ freed MFT records and zero of them held a recognizable $I/$R entry. They'd all been reused by subsequent file activity. The trail was gone.

On a less busy machine — especially a fresh install or a single-user workstation that hasn't seen much activity since the empty event — the $MFT can yield gold. Always check.

The Volume Shadow Copy goldmine — when it exists

If Windows System Protection was enabled on the source machine, Windows periodically takes Volume Shadow Copies (VSCs) — frozen snapshots of the entire filesystem. Each VSC contains a copy of $Recycle.Bin as it existed at the moment of the snapshot. By comparing bin contents across VSCs, you can directly bracket empty events:

"On the snapshot from April 12, the bin contained items A, B, C. On the snapshot from May 20, the bin was empty. Therefore an Empty Recycle Bin event happened between those dates."

This is by far the cleanest way to reach back in time.

The bad news: on most modern consumer Windows installs, System Protection is disabled by default. We confirm this by checking \System Volume Information\SystemRestore\ on the imaged volume. If there's nothing in there but FRStaging, you have no shadow copies. We've also found it useful to query the forensic suite's case database directly (via SQLite on AXIOM's Case.mfdb) to enumerate all VolumeShadowCopy-typed sources the tool indexed — fast, and it confirms whether you're chasing something that exists or something that doesn't.

When there are no VSCs and the USN window doesn't reach far enough back, the answer to "when was it emptied before [date]?" becomes: we cannot determine that from this image. That isn't a failure of the examination — it's a property of the source data. A good report says so explicitly, lists the four artifacts examined, and explains what each one would have shown if the data had been there.

Where recovered emails fit in

Clients often conflate the Windows Recycle Bin with their email client's "Deleted Items" folder. These are completely separate systems. When you delete an email in Outlook, Thunderbird, or Windows Live Mail, it goes to the email app's internal trash, not to C:\$Recycle.Bin\. Emptying email trash is a different operation from emptying the Windows bin.

When the question is "are deleted emails recoverable?", we always answer for both interpretations:

A subject who appears to have "no emails" on their local machine often hasn't lost anything — they're just a webmail user. Confirm whether there's a local PST/OST or a mail-folder structure before promising email-recovery results.

The short version

  1. Identify every bin folder on the image and check the machine portion of each SID. Don't count a backed-up bin as live activity.
  2. Compare oldest surviving item to the suspected empty date — that alone often answers the question.
  3. Pull $UsnJrnl:$J and grep for FileDelete | Close on $I/$R filenames. That's where empty events live.
  4. Distinguish targeted deletes from full empties by checking what survived.
  5. Try $MFT for deleted $I/$R records — works on quiet machines, fails on busy ones.
  6. Check for VSCs by inspecting System Volume Information\SystemRestore\ and the case database. If they exist, you can reach back months or years.
  7. Be honest about the boundary. NTFS journals have finite retention. If the data isn't there, say so — and explain which artifact would have told you, and why it didn't.

The most valuable thing a forensic report can do isn't always to produce dates. Sometimes it's to credibly establish what dates are knowable and which aren't. That's the difference between a report that holds up in front of a tribunal and one that gets picked apart.

Data Rescue Labs performs Windows, macOS and mobile forensic examinations for law firms, corporate clients and law-enforcement agencies. If you have a question about what's recoverable from a device, our Computer Forensics and Litigation Support teams handle this work. Open a case for a privileged consult.