A small corrupt PST is a repair job. A huge corrupt PST is a logistics problem - size changes which tools work, how long they take, and what you should do first.
Size is not a detail in PST repair; it is a repair variable. A 2 GB file scans in minutes and fails politely. A 49 GB file scans for hours, strains memory, and gives corruption a thousand more places to hide. Worse, Outlook itself enforces ceilings: the modern Unicode PST has a default limit of 50 GB, and the old ANSI format has a hard wall at 2 GB that no repair can move. If your file lives near either line, the shrink-and-split order matters more than the repair itself. And the standing rule still applies: copies only, Outlook closed.
Every ScanPST phase walks the file's structures, so pass time scales with size - and on a mechanical disk, a giant file can take an hour or more per pass, with several passes often needed. A nearly full system disk starves the repair of working room. And the probability maths is unkind: more gigabytes means more sectors, more tables, and more chances that one damaged area blocks a whole phase.
Practically: copy a giant PST to the fastest local disk you have before repairing, free up space around it, and expect the job to take real time. Rushing a giant repair is how people kill a pass at 95 percent and start over.
For Outlook 2010 and later, the Unicode PST's default size limit is 50 GB. As a file approaches it, Outlook slows, send and receive errors appear (the 0x8004060C family is the classic "mailbox full" complaint), and corruption risk climbs sharply. Past the ceiling, the file simply does not function as a working data file.
The limit can technically be raised through registry values - that operation has its own guide in this series, and it is deliberately not repeated here, because on a corrupt file it is the wrong first move: a bigger ceiling does not repair anything, it just gives a sick file more room to get sicker. Split first; debate ceilings later, on a healthy file.
The ANSI format belongs to Outlook 2002 and earlier, but ANSI files survive in the wild as old archives that kept being used. Its limit is not a default - it is a hard 2 GB wall built into the format. Corruption characteristically begins as the file approaches roughly 1.8 GB, and ScanPST's signature for this exact situation is Fatal Error 80040818.
To identify an ANSI file: in Outlook, right-click the data file's root folder, choose Data File Properties, then Advanced - the Format field reads either Outlook Data File (Unicode) or the 97-2002 ANSI wording. No repair pass fixes a format limit; the only road out is conversion, below.
If Outlook can still open the file, shrinking before repairing changes the whole job:
If Outlook cannot open the file at all, you cannot shrink what you cannot open - repair a copy as it stands, or extract from it, and split the moment it opens.
For an ANSI file at its wall, conversion replaces repair:
Watch the video fix for the repair error itself, then give your giant file the shrink-and-split treatment it actually needs.
Watch Full VideoIt may run, but Outlook itself will not work with the result properly - the 50 GB figure is Outlook's working ceiling for a Unicode PST, not just a ScanPST limit. Split the mailbox into year-wise PST files instead of chasing a bigger ceiling for a working mailbox.
In Outlook, right-click the data file's top folder, choose Data File Properties, then Advanced - the Format field says Outlook Data File (Unicode) or the Outlook 97-2002 (ANSI) wording. An old file stuck just under 2 GB is almost always ANSI.
Repair a copy first only if Outlook cannot open it at all - you cannot split what you cannot open. The moment it opens, stop repairing and split: archive whole years out, compact, and let the working file live well below the ceiling.