You're staring at 0x800401C4. Maybe it popped in Outlook, maybe Word refused to open a legacy .doc, maybe some line-of-business app threw it during a file import. The HRESULT name is CONVERT10_E_STG_FMT, which is Windows-speak for: the IStorage (OLE compound file) I was handed has a header or stream table that doesn't match the spec.
The culprit here is almost always a corrupted file — not Windows itself. Compound File Binary Format (CFBF) has a strict header layout. If a single sector goes sideways, the whole thing becomes unreadable. A bad shutdown mid-save, a drive with pending sectors, a sync client that copied the file while it was still being written, any of those will do it.
Work the fixes in order. Stop when the error goes away.
Fix 1: The 30-second check — identify the actual file
Before you touch anything, figure out which file is lying. 0x800401C4 almost always names a target — in the dialog box, in the Event Viewer entry, or in the application's log. Search Event Viewer under Windows Logs > Application for source matching your app (Outlook, Word, your LOB tool) around the timestamp of the failure.
Once you've got a path, do this:
- Copy the file to a known-good local drive (not a network share, not a USB stick).
- Try opening the copy. If it works, the original location is the problem — bad sector, failing drive, or a share that mangles writes.
- If the copy also fails, the file is corrupt. Move to Fix 2.
Don't skip step 1. I've seen this exact error three times in the last year where the file was fine and the network share's SMB cache was the problem. Reboot the file server, error gone.
Fix 2: The 5-minute fix — repair the file or the drive
Which repair depends on what kind of file it is.
If it's an Office document (.doc, .xls, .ppt, .docx, .xlsx)
Open the app first, don't double-click the file. Then:
- File > Open > Browse to the file.
- Click the arrow on the Open button > Open and Repair.
- Choose Repair first. If that fails, run it again and pick Extract Data.
For older .doc and .xls files, this works surprisingly well. For modern OOXML (.docx, .xlsx) it's hit or miss — those are ZIP containers, and if the CFBF error is coming from the container itself, the file's gone. Grab the previous version from shadow copies:
vssadmin list shadows /for=C:
# Then browse to the shadow copy and restore:
# \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\path\file.docxOr right-click the file > Properties > Previous Versions tab.
If it's an Outlook .ost or .pst
Close Outlook. Then run the matching repair tool:
- .pst —
scanpst.exe(locate it underC:\Program Files\Microsoft Office\root\Office16\) - .ost —
scanost.exefor older Outlook, or just delete the OST and let Outlook rebuild it. Seriously. Rebuild is faster than repair 90% of the time.
For OST rebuild, the file lives at:
%LOCALAPPDATA%\Microsoft\Outlook\user@domain.com.ostRename it to .ost.bak and restart Outlook. It'll pull fresh from Exchange.
Run a disk check on the volume
If the file was on a local disk, verify the disk isn't the actual problem:
chkdsk C: /scan
# Read-only scan first. If it reports errors, schedule a full repair:
chkdsk C: /f /r
# Answer Y to schedule at next reboot, then reboot.On SSDs, /r doesn't do much good — it's for spinning rust. Skip it on NVMe. Just do chkdsk C: /f.
Also check SMART status. CrystalDiskInfo or wmic diskdrive get status. If you see reallocated sectors climbing, back up and replace the drive. Fixing the file is pointless on dying hardware.
Fix 3: The 15-minute fix — rebuild the OLE storage manually
When the built-in repair tools fail, you can sometimes salvage data by extracting the streams inside the corrupted IStorage container. CFBF files are basically little filesystems. If the header is intact but the directory is broken, you can pull what's readable.
Grab a tool. Two that work:
- 7-Zip — yes, it opens OLE compound files. Right-click > 7-Zip > Open Archive. If the directory is readable, you'll see the streams listed.
- CFBF Reader (open source, GitHub) — gives you a proper directory tree dump.
If 7-Zip opens it without complaint, extract everything, then try reassembling in the target app. For Office docs, the main stream is WordDocument or Workbook. If that stream extracts clean, you can often rename the file's extension after wrapping it back up.
If the header itself is hosed (bytes 0–7 won't show the CFBF magic signature D0 CF 11 E0 A1 B1 1A E1), you're done. No tool fixes a mangled magic signature — the file is a loss.
Check with:
# PowerShell one-liner to dump first 8 bytes as hex
Format-Hex -Path C:\path\file.doc -Count 8If you don't see D0 CF 11 E0 A1 B1 1A E1 in the first line, stop. Restore from backup.
When it's not the file
Sometimes 0x800401C4 shows up on files that are perfectly fine. Three real scenarios I've seen:
| Symptom | Actual cause | Fix |
|---|---|---|
| Error on every file in one folder | Folder is on a deduplication-enabled volume that's corrupt | Run Start-DedupJob -Type Optimization or disable dedup on that volume |
| Only fails over VPN | SMB signing mismatch on old appliances | Disable SMB signing on the client via GPO, or upgrade the appliance |
| Fails after Windows Update | AV filter driver is intercepting IStorage reads | Add the file path to AV exclusions, or test by disabling real-time protection |
That third row is more common than people think. CrowdStrike, Sophos Intercept X, and a couple of others have shipped builds that broke OLE compound file reads. If the timing lines up with an AV update, that's your answer. Test in Safe Mode — if the file opens there, it's a filter driver.
Bottom line
0x800401C4 is a corruption error, plain and simple. Copy the file locally first, try Open and Repair, run chkdsk if the drive's suspect, and if the file's shot, restore from backup or shadow copy. Don't waste time on registry cleaners or sfc /scannow — those won't touch a bad CFBF header. They never do.
And if you're seeing this across multiple files regularly, stop chasing the error. Chase the disk. Something's eating sectors.