Thumbcache forensics: evidence from Windows thumbnail caches

Thumbnail caches are one of the few Windows artifacts that hold the content of a file instead of metadata about it. Pictures, video frames, PDF and Office first pages: if Explorer drew a preview, a small copy often sits in the user's thumbnail cache long after the original was deleted, wiped or moved to a USB drive that never came back. In image-based cases (CSAM, data theft, harassment) that is frequently the most important evidence on the disk.

This guide covers what the caches contain, what they do and do not prove, and how to extract and report them. You can follow along in the Thumbcache Parser, which opens every file mentioned here in the browser.

Where the caches live

Since Windows Vista the caches are per-user and centralised:

%LOCALAPPDATA%\Microsoft\Windows\Explorer\
  thumbcache_16.db   thumbcache_32.db   thumbcache_48.db   thumbcache_96.db
  thumbcache_256.db  thumbcache_768.db  thumbcache_1280.db thumbcache_1920.db
  thumbcache_2560.db thumbcache_sr.db   thumbcache_wide.db thumbcache_exif.db
  thumbcache_wide_alternate.db  thumbcache_custom_stream.db  thumbcache_idx.db
  iconcache_16.db … iconcache_2560.db

The exact set depends on the Windows release (Vista and 7 only have 32, 96, 256, 1024 and sr). Each size is a separate database, so the same picture can appear several times, and one size may still hold it after another has been purged. Always collect all of them, plus thumbcache_idx.db and the iconcache_*.db files.

Before Vista, Explorer wrote a hidden Thumbs.db into each folder it displayed as thumbnails. Modern Windows still writes Thumbs.db on network shares unless a policy disables it, so file servers are worth a look too. See the Thumbs.db guide for that format.

What a thumbnail proves (and what it doesn't)

A cache entry exists because the Windows shell produced a thumbnail for a file on that user profile. In practice that happens when:

• a folder is viewed in any icon view large enough for thumbnails;
• a file is selected with the preview or details pane open;
• a file-open or save dialog shows the folder in a thumbnail view;
• an application asks the shell for a thumbnail through IThumbnailCache.

So a thumbnail is solid evidence that the file existed on a volume that profile browsed, and that its content matched the image. It is weak evidence that the user looked at that particular file. They may have scrolled past a folder of hundreds. Say this plainly in reports; defence experts will.

Two more limits:

• No timestamps per entry. Modern thumbcache entries carry no date. Use the .db file's own $MFT timestamps as a bound, and correlate with jump lists, LNK files, ShellBags and the search index.
• No file name. Entries are keyed by a 64-bit cache ID (see below). Only the legacy Thumbs.db Catalog stores original names.

Recovering deleted thumbnails

Deleting the source file does not touch its thumbnail. Explorer cleans the caches only when Disk Cleanup's Thumbnails option runs, when automatic maintenance decides to, or when the cache is rebuilt. Even then, a freed entry is usually just left behind: the database tracks an "available" offset, and space past it is reused lazily.

Every entry starts with the four bytes CMMM, followed by its size, so the old entries are easy to carve. The parser walks the live entry chain and then signature-scans the whole file. Hits past the header's available offset are reported as Slack; hits elsewhere (for example after a corrupted entry) are reported as Carved. Both appear with a red border in the gallery and are flagged in every export.

Two practical tips:

1. Also check Volume Shadow Copies. Older copies of the cache files can hold thumbnails that were purged from the live ones.
2. Carve unallocated space for CMMM. When a cache database itself was deleted, its entries can still be carved from free clusters and then loaded here as a raw chunk.

Linking a thumbnail to the original file

Each entry's cache ID is the same value Windows Search stores as System_ThumbnailCacheId for the indexed file. If the file lived in an indexed location, the search database gives you its path and other metadata:

• Windows Vista to 10: %ProgramData%\Microsoft\Search\Data\Applications\Windows\Windows.edb (ESE)
• Windows 11: Windows.db in the same folder (SQLite)

Collect the database with its transaction logs. An ESE database copied from a live system is usually "dirty" and needs esentutl /r or /p on a copy before tools can open it. Drop it into the Thumbcache Parser next to the cache files and every indexed thumbnail is labelled with its original path, name, size and modified time — the inspector and all exports carry them.

Icon caches

iconcache_*.db use the same format but hold application and file-type icons. They are a quiet source of program execution context. A portable tool run from a USB stick, or an installer later deleted, can leave its icon behind.

Collection checklist

• All thumbcache_*.db, thumbcache_idx.db and iconcache_*.db for every profile
• Shadow copies of the same folder
• Windows.edb / Windows.db plus logs (edb*.log, edb.chk)
• $MFT for the timestamps of the cache files themselves
• Thumbs.db from user data folders, removable media and file shares

The files are locked while explorer.exe runs, so use KAPE's ThumbCache target, FTK Imager, a shadow copy, or pull them from an image with Disk Image Parser and drop its ZIP export straight into the parser.

Reporting

For each thumbnail you rely on, record the source file and its SHA-256, the entry offset, the cache ID, whether it was allocated or recovered, and the MD5/SHA-256 of the extracted image bytes. The parser's Evidence ZIP bundles the images, a CSV, a JSON dump and a self-contained HTML report with all of that. It hashes the image exactly as stored in the database, so anyone re-extracting the same offset will get the same hash.