How Sherlock PST Viewer 1.4.0 Salvages Truncated PSTs That Standard Tools Decline

A large PST file that truncates during transfer often has a valid header declaring the full expected size while the file on disk is smaller and the internal index is missing beyond the truncation boundary. Standard email-forensics tools such as EnCase, FTK and Microsoft scanpst.exe treat that as a fatal validation error and decline the file. Sherlock PST Viewer 1.4.0 adds salvage reconstruction: it walks the intact data pages that precede the truncation boundary and rebuilds the recoverable folder tree and messages read-only, with a diagnostic manifest of what recovered and what did not.

Why Truncated PSTs Get Declared Unrecoverable

Large PST files transferred across networks, storage boundaries and vendor handoffs routinely encounter truncation that only surfaces at ingest time. The failure looks the same across tools: the PST header declares a total content size and an estimated message count, but the file on disk is smaller than the header claims and the internal B-tree index that maps messages to their storage locations is absent or cut off beyond a certain offset.

Mainstream email-forensics and repair tools validate that header and index structure before they read anything. When the structure fails validation they stop. EnCase, FTK and Microsoft's own scanpst.exe repair utility all decline a file that fails initial header and index validation rather than attempt a partial read. (This is a PST and Outlook-email problem specifically; mobile-device tools like Cellebrite operate in an entirely different domain and are not part of a PST salvage workflow.) A vendor whose toolchain stops at validation reasonably characterizes the file as unrecoverable and requests re-acquisition from the source.

Re-acquisition is often not available. The source mailbox may have moved, the workstation may have been decommissioned, or the truncated copy may be the only remaining artifact. When there is no clean source to re-pull, an "unrecoverable" determination can stall an investigation while alternatives are negotiated. That is the scenario salvage reconstruction is built for.

What Salvage Reconstruction Actually Does

Sherlock PST Viewer 1.4.0 opens the truncated file and produces a structured diagnostic on load rather than a fatal error: it reports the size the header declares, the estimated message count, the actual file size on disk, the offset beyond which the internal index is missing, and whether salvage reconstruction is available for that file.

The salvage reconstruction operates by walking the intact data pages that precede the truncation boundary and rebuilding the folder tree and message set from the surviving MAPI records, rather than relying on the missing index. It runs read-only on the source file: the tool does not modify the truncated PST. The output is a new reconstructed PST containing every message the salvage was able to recover and a diagnostic manifest documenting which messages recovered and which are absent (identified by the missing folder or message reference in the surviving pages), so the gap can be characterized precisely rather than guessed at.

Recovery is bounded by the data that physically survives ahead of the truncation. Messages whose pages fall past the boundary cannot be reconstructed, and the manifest names them by folder so an examiner can assess the materiality of the gap. In a typical truncation the bulk of the mailbox precedes the boundary and reconstructs, while the tail (often the most recent Sent Items) is what is lost.

Making the Salvage Court-Defensible

For salvage output to hold up as evidence, the reconstruction has to be documented as thoroughly as any acquisition. The Sherlock reconstruction records the receipt hash of the truncated file, examiner identity and timestamp, the tool version, the diagnostic report contents, the reconstruction parameters, the output PST hash and a per-message hash for every recovered message.

Where a partial second source exists, such as server-side Exchange retention that overlaps the same period, the reconstructed messages can be cross-correlated against it to confirm they match the corresponding records for the overlapping range. That corroboration strengthens the evidentiary chain and gives an examiner a defensible answer when salvage output is challenged: the methodology (walking intact data pages and rebuilding the folder tree from surviving MAPI records, read-only) is transparent and repeatable, and the recovered set is hashed and reconciled rather than asserted.

Where This Fits in a PST Workflow

The operational takeaways are straightforward. First, do not accept an "unrecoverable" determination on a damaged PST without an independent second-opinion assessment: a tool that stops at validation will decline files a salvage-capable tool would recover. Second, request the formal diagnostic when a PST fails ingest, because the specific failure mode (header truncation versus index corruption versus body truncation) determines whether salvage is feasible. Third, keep salvage-capable tooling in the standard review workflow so a damaged file does not stall an investigation while options are negotiated.

Sherlock PST Viewer 1.4.0 makes damaged-PST salvage a standard capability rather than a specialist engagement. The free tier produces the diagnostic and an upgrade prompt; the Sherlock PST Viewer Forensic Edition performs the reconstruction, read-only on the evidence file. It is a genuine differentiator against tools that decline files failing initial validation, and it does not require sending the evidence to a specialized data-recovery vendor for a multi-week engagement.

For organizations that prefer engagement over internal capacity, Sherlock incident response applies the same methodology as part of the standard PST-forensic scope. The reconstruction approach stays consistent regardless of who runs the tooling, and so does the documentation that makes the output defensible.