Recycle Bin & deletion records
Examine discarded files and deletion metadata while accounting for pathways that bypass the Recycle Bin.
Question & scope
The Recycle Bin can preserve content and metadata for files deleted through supported shell operations. During a screenshare examination, it may reveal a removed mod, archive, or utility connected to the disputed session. Examine the relevant volume and user context rather than only the graphical Recycle Bin view. The GUI is a presentation of available items, not a complete audit of every deletion.
On modern Windows systems, paired recycle artifacts can contain metadata and the discarded object, commonly using $I and $R naming. Preserve the pair and original source location when possible. Use a version-aware parser instead of inferring every field from filenames.
What to collect
| Source | Retain and examine |
|---|---|
| Recycle artifacts | Relevant $Recycle.Bin content from the examined volume and user context. |
| Metadata pair | Original path, size, deletion-related time, and parser-supported identifiers. |
| Discarded content | The paired object, its content hash, and acquisition notes. |
| Corroboration | MFT or USN observations, original mod references, and available execution evidence. |
Examination workflow
- Record volume and user context before exporting items from the bin.
- Collect the artifacts without restoring items into their original paths. Restoration would change the examined system.
- Parse metadata with a documented tool such as RBCmd and retain the raw pair.
- Hash recovered content and compare it with the exact claimed release before examining its code or resources.
- Connect deletion-related records to the session timeline, checking timezone and corroborating filesystem evidence.
Interpretation & false positives
Some deletion mechanisms bypass the Recycle Bin. An empty bin does not prove that no files were deleted, and surviving items may relate to an older or unrelated session. The metadata concerns the discarded object; it does not establish that the program ran before deletion.
A recovered item can still be incomplete, altered, or misidentified. Verify the bytes you have rather than assuming that a displayed original filename authenticates the contents. Do not execute recovered binaries or archives merely to see what they do.
Worked scenario
A discarded JAR matches an unofficial modification, but there is no link to the active game instance. Report its presence and deletion metadata, then look for launcher and game-session context. Possession, installation, loading, and actual use are different questions and should not be merged.
Report checklist
- The relevant volume and user context are known.
- Paired metadata and content are retained.
- Recovery did not silently restore files on the source system.
- Deletion is not treated as proof of prior execution.
Sources & further reading
The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.