Run it again sounds like superstition. With ScanPST it is the documented method - up to a point. This page draws that point precisely.
Ask anyone who repairs Outlook for a living and they will tell you the same odd thing: run ScanPST, repair, then run it again. This is not folklore. The tool repairs the layer of damage it can see, and rebuilding that layer lets the next scan reach damage that was hidden behind it. But the method has a hard edge - past a certain point, passes stop helping and start merely rewriting your file. Knowing which side of that edge you are on is the whole skill. As always: passes run on a copy, backup box ticked, Outlook fully closed.
A PST's structure is layered: headers point to folder tables, folder tables point to item tables, and corruption in an upper layer hides everything beneath it. The first scan can only report the errors it can reach. Repair rebuilds that layer - and the second scan now walks further in and finds errors that were previously invisible, not newly created.
This is why a second pass finding errors is normal, and why even a pass that finds more errors than the one before is not automatically bad news. Judge the trend across passes, never a single count.
.log file beside the PST keeps it for you)On genuinely damaged files, three to five passes is an unremarkable number. Light damage often clears in one or two. Very large files make every pass slow - a big PST on a mechanical drive can take an hour or more per pass - which is a practical argument for patience and for running the passes on a local SSD if one is available.
What is not normal: counts that never move, or a scan that stops at the identical phase with the identical message every time. That is not a slow repair; that is a wall.
Stop the passes when any of these is true:
Every extra pass rewrites the file and can drop items it cannot place. On a working copy that risk is contained - but a contained risk with zero remaining benefit is still a bad trade.
The ladder above ScanPST, in order: roll back to the .bak if the last pass made things worse; import the best repaired state into a fresh PST under a fresh profile; hand the untouched original copy to an extraction tool and judge it by its free preview; or restore from backup. The decision rule is simple: passes are for damage that is retreating; the ladder is for damage that is not.
Watch the video to see real pass counts fall on a real corrupt file before you start your own.
Watch Full VideoEach repair pass rewrites the file and can drop items it cannot place, so endless passes do carry risk. That is why repairs run on a copy with the backup option ticked, and why a frozen error count is a stop signal rather than a challenge.
Check the disk activity for the ScanPST process in Task Manager and whether the .log file beside the PST is still growing. A large PST on a mechanical disk can honestly take an hour or more per pass; a frozen log with zero disk activity over a long stretch means the pass has died.
Usually not. The first repair rebuilds structures the scanner could not previously walk past, so the second scan sees further into the file and finds deeper errors. Judge by the trend over several passes, not by one surprising count.