Why scanpst often makes
PST corruption permanent.

The Inbox Repair Tool, scanpst.exe, is not malicious software and it is not badly written. It does what it was designed to do. The problem is what it was designed to do: make a damaged PST file openable again, by whatever means necessary, working directly on the file you point it at.

Openable is not the same as complete. Those two goals diverge sharply once a file is properly damaged, and the tool will always choose openable.

What a PST actually is

A PST is not a folder of messages. It is a single-file database with its own internal structure: a node tree that maps message IDs to storage blocks, a block allocation table describing which parts of the file hold live data, and index structures that make folders and search work. Messages, attachments, contacts and calendar items are all rows in that structure.

When a PST "corrupts", the message content is usually still there. What breaks is the bookkeeping: a truncated allocation table after an abrupt shutdown, a damaged node in the tree because a sector went bad under it, or an inconsistent header from a file that hit the legacy 2 GB ceiling.

What scanpst does about that

Given a broken map, scanpst rebuilds a valid one. To do that it walks the structures, and anything it cannot validate, it drops. Nodes that do not resolve get removed from the tree. Blocks it cannot account for are marked free, meaning available for reuse. Folders whose parent reference is damaged get orphaned or discarded. The result is a file Outlook opens without complaint, which is the success condition it was written for.

Two things about that process cause the real damage.

1. It writes to the original file

scanpst does not work on a copy. It modifies the file you gave it, in place. It offers to make a backup first, and that backup is genuinely worth taking, but it is off by default in the sense that plenty of people click straight past it, and it cannot be taken at all if the disk holding the PST is failing or nearly full.

Once the repair has run, the pre-repair state is gone. A recovery lab reconstructing that mailbox is no longer working with a damaged original. It is working with a damaged original that has since had its inconsistent parts deliberately removed.

2. Dropped blocks become free space

This is the part that turns a recoverable case into a permanent loss. When the repair marks unaccounted blocks as free, it is telling Outlook that region is available. As soon as Outlook opens that file and starts syncing new mail, it writes into that space. The old messages that were sitting there, still perfectly intact and still reconstructable by hand, get overwritten with today's inbox.

This is why the timeline matters so much. A PST that had scanpst run against it an hour ago is usually still in good shape. The same file after a week of normal use has had its recoverable remnants steadily written over.

The pattern we see on intake

The sequence is almost always identical:

1. Outlook throws an error, or a large archive stops opening.
2. A search suggests scanpst. It runs and reports errors found and repaired.
3. Outlook opens. Relief, briefly.
4. Over the next day someone notices a folder is missing, or that mail before a certain date is gone, or that a subfolder tree has collapsed into one flat list.
5. scanpst is run again, several times, because it worked the first time. Each pass drops more.
6. The file arrives here, and the question is how much of what was dropped is still sitting in what is now free space.

Running it repeatedly is the most damaging variation, and it is completely understandable, because the tool reported success each time.

What to do instead

• Copy the PST before doing anything. If the file is readable at all, copy it somewhere else first. This single step preserves every option. Copy it twice if it is important.
• Do not run the repair on the only copy. If you want to try scanpst, run it against a copy, never the original.
• Check whether the disk is healthy first. If the PST is corrupt because the drive under it is failing, the repair tool is the wrong layer entirely, and running it keeps a dying drive under sustained load.
• Do not delete the Outlook profile or resync the account. Especially with an OST. A fresh profile can pull down an empty or partial mailbox and overwrite the local store that still had everything in it.
• Stop after the first failure. If one pass did not give you back what you needed, more passes will not either. They will only drop more.

What a lab does differently

The difference is not better software. It is the order of operations. The file, and where relevant the whole disk under it, is imaged first, read-only. Everything after that runs against the image, so a wrong assumption costs a retry rather than the data. The internal structures are then walked directly, including the parts scanpst would discard as invalid, and the mailbox is reconstructed from the message data rather than from the index that points at it.

That is also why a case that has never been touched is so much cheaper and faster to resolve than one that has been repaired three times. The most valuable thing you can hand a recovery engineer is an unmodified original.