That is one of the most maddening Outlook behaviors, especially when you just downloaded the file directly from Microsoft 365 eDiscovery or Content Search and know it shouldn't be corrupt.

What is happening under the hood comes down to how Outlook opens PSTs versus how Microsoft 365 packages them, combined with local file system locks.

1. The "Dirty Shutdown" Flag

When Microsoft 365 builds and exports a PST, it creates the database structure programmatically on the server. However, it doesn't always perform the exact sequence of low-level disk writes that a live, desktop version of Outlook uses when gracefully closing a file.

Because of this, the PST is often downloaded with its internal "dirty bit" set or without the expected "clean unmount" header marker.

• When you attach it, Outlook initially opens it read-only or in a quick-mount state.


• The moment Outlook tries to write anything to its local tracking index (even simple metadata like unread states or view settings), it detects that the PST header wasn't cleanly closed.


• Outlook immediately marks the file as potentially compromised and triggers SCANPST or its built-in background repair routine to reconcile the internal database index.

2. Local File Locks & Web Download Scans

If you double-click or mount the PST shortly after downloading it, background security tools or the browser itself might still hold a handle on the file:

• Antivirus / Defender scanning: Windows Defender or your endpoint security often scans newly downloaded .pst files in the background. If Outlook tries to write to the file while AV has an open read lock, the write fails mid-operation.


• The "Mark of the Web" (MotW): Files downloaded from 365 carry an internet zone flag. Outlook sometimes struggles with partial permissions on MotW files until they are unblocked, causing write errors that Outlook misinterprets as database corruption.

3. PST Format Overhead (The 4GB+ Threshold)

If the exported PST is large (especially over 4GB-10GB), Outlook processes the internal B-tree structure in real-time. If there is even a single minor mismatch in the item-count table from the export tool, Outlook's local engine flags it as an index discrepancy the moment you click through a few folders.

How to Stop It From Happening

To bypass these false-positive corruption scans on fresh 365 exports, try these quick steps before mounting:

1. Unblock the file first: Right-click the .pst file $\rightarrow$ Properties $\rightarrow$ check Unblock at the bottom $\rightarrow$ Apply.


2. Move it out of Downloads: Copy or move the file to a local dedicated folder (e.g., C:\PSTs\) rather than opening it directly from your Downloads or Temp folder where security tools continuously poll.


3. Wait a few seconds after downloading: Give your AV/EDR a moment to finish its initial write-scan before launching Outlook.


4. Open via Outlook UI, not double-clicking: In Outlook, go to File > Open & Export > Open Outlook Data File instead of double-clicking the file in Windows Explorer.

That explains the scan requirement completely - and unfortunately, it means the issue isn't just an Outlook quirk this time. That PST is genuinely corrupted or incomplete inside the ZIP archive.

When 7-Zip throws a Headers Error alongside a CRC failed warning on a split archive part (.005), it means the data stream for [email protected] didn't pass its mathematical integrity check during extraction.

What Happened

1. Partial Extraction: 7-Zip still tried to carve out as much of Nigel...002.pst as it could salvage and dropped it onto your disk.


2. Missing/Truncated Data: Because the CRC failed, parts of the PST's internal structure (like the index or node tables) were corrupted or cut off mid-stream.


3. Outlook's Reaction: Outlook opened the file using whatever valid header data was salvaged, but the second it tried to parse a folder or item that hit the damaged/missing sector, it realized the internal pointers didn't match and immediately halted to demand a repair scan.

What to Do Next

Note: Running SCANPST.exe on a PST extracted from a failed CRC archive might recover some orphaned emails, but it will usually strip out heavily damaged folders or truncate the file significantly.

To get a clean, usable PST without missing data, you'll need to fix the source archive:

• Re-download Part 5 (PSTs.005.All_Data.zip): A CRC failure on a specific split part usually means the network stream dropped bytes during the 365 export download. Re-downloading just that .005 file often resolves it.


• Verify All Multi-Part Files Are Present: Ensure .001 through .005 (and any subsequent parts) are all in the exact same local folder before attempting to extract .001.


• Test the Archive in 7-Zip: Right-click PSTs.001.All_Data.zip (or the first volume) $\rightarrow$ 7-Zip $\rightarrow$ Test archive to confirm which specific volume is corrupt before re-exporting or re-downloading the entire batch.

It's unlikely to be a transient network "overload" or congestion issue in the way we usually think of slow transfers.

When you copy files over a network, protocol-level checks (like TCP) guarantee that every packet of data arrives intact or gets retransmitted. If the network drops packets due to high traffic or CPU spikes, the connection simply slows down or drops-it doesn't silently write scrambled bytes onto your drive.

However, a heavy network transfer can trigger hardware or storage-level glitches that cause a CRC/Header error during an archive build or extraction. Here is where a transfer load can actually break a split ZIP:

1. SMB / Storage Port Buffering Drops (The Real Culprit)

Since you are pulling directly from a network administrative share (\\PC\f$\...), a heavy load can overwhelm the network interface, SMB buffer, or target disk controller on either end. If the sending machine or network storage unit (NAS/server) experiences a brief buffer overflow, the file system can commit a zero-byte fill or truncated block directly into the .005 archive file without dropping the SMB connection.

2. High Disk IOPS & Memory Pressure

If the host holding that f$ share was under heavy I/O or memory pressure while generating or copying that multi-part ZIP export:

• In-Memory Corruption: System RAM or disk caching on the host machine can drop or misplace bits before writing them to the f$ drive.


• Partial Writes: If the eDiscovery export tool was writing to f$ while a network copy operation was simultaneously reading .005, the read process might have grabbed an incomplete file lock.

3. File System Interruption During Multi-Part Writes

Multi-part ZIP archives (.001, .002, .005) are written sequentially. If the network link flickers for even a fraction of a second while .005 is being transferred, Windows SMB usually retries automatically, but it can miscalculate the file offset, causing the 7-Zip header and CRC hash to mismatch upon extraction.

How to Tell for Sure

Before re-downloading the entire export, you can quickly isolate whether it was just a bad network copy:

1. Check File Sizes: Compare the exact byte size of PSTs.005.All_Data.zip on the remote share (\\PC\f$\...) versus your local copy. If they differ by even a few kilobytes, the copy aborted prematurely.


2. Hash Comparison: Run a quick PowerShell command on both the local and remote .005 file:

Get-FileHash \\PC\f$\Co\Reed\PSTs.005.All_Data.zip -Algorithm SHA256 

If the hashes match, the archive was corrupt before you copied it over the network. If they don't match, the network copy itself dropped data mid-flight.