Fix 0x80010137 CO_E_FAILEDTOCREATEFILE

Quick Answer (advanced users)

cd %windir%\system32\com
dcomcnfg -repairdatabase
dcomcnfg -reinstall

Then restart the COM+ Services service. That's it.

What's actually happening here

Error 0x80010137 (CO_E_FAILEDTOCREATEFILE) means the COM+ subsystem tried to write a temporary scratch file — usually in %windir%\system32\com\tmp or the COM+ catalog store — and failed. Windows returns this when the COM+ catalog database (%windir%\registration\*.clb files) is corrupted, or when the DCOM launch permissions for the COM+ system application are hosed.

I've seen this most often after:

Running a registry cleaner that nuked COM+ entries
A failed Windows update that rolled back partially
Manually editing DCOM permissions in dcomcnfg.exe and then clicking "Apply to all" (bad idea)

The trigger is usually a COM+ component activation — maybe from Office, a third-party app that uses COM+, or even Windows Explorer itself when it tries to query COM+ objects. The fix isn't reinstalling Windows or the offending app. The fix is rebuilding the COM+ catalog cleanly.

Fix steps

Close everything that might use COM+ — Office apps, Visual Studio, anything that hosts COM objects. If you're not sure, safe mode works too.
Open an elevated command prompt — Win+X, Terminal (Admin) or cmd as admin.
Stop the COM+ services — run these three:
```
net stop COMSysApp
net stop MSDTC
net stop EventSystem
```
They'll stop cleanly. If one hangs, skip it and move on.
Rebuild the COM+ catalog — this is the real fix:
```
cd %windir%\system32\com
dcomcnfg -repairdatabase
```
This regenerates the .clb files from scratch. Takes about 30 seconds. You'll see no output on success.
Reinstall the COM+ core components:
```
dcomcnfg -reinstall
```
Don't skip this. The -repairdatabase flag fixes the files, but -reinstall registers the core COM+ classes again.
Restart the services — in this order:
```
net start EventSystem
net start MSDTC
net start COMSysApp
```
If MSDTC fails to start, run msdtc -uninstall then msdtc -install, then start it again.
Test it — open Component Services (dcomcnfg.exe), expand Component Services > Computers > My Computer > COM+ Applications. If you see a list of applications without errors, you're good. Try whatever app originally threw the error.

What if the main fix didn't work?

Option A: Registry permission nuke (advanced)

Sometimes the COM+ catalog files are fine but the registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID have bad ACLs. The nuclear option: run subinacl or icacls to reset permissions on the entire CLSID hive. But this breaks a lot of other things. Only do this if you're comfortable restoring from backup.

Option B: SFC + DISM first

If the catalog rebuild fails with "access denied," your system files might be hosed. Run:

sfc /scannow
dism /online /cleanup-image /restorehealth

Then repeat steps 3-6. The catalog rebuild won't work if core COM files are missing.

Option C: Create a new COM+ application manually

If only one specific app throws the error, the COM+ app might be corrupted. Open Component Services, find the app in question, export it, delete it, then re-import. This fixes permission inheritance issues that cause the file creation failure.

Prevention tips

Never run registry cleaners. They don't speed up your PC, and they trash COM+ entries regularly.
If you edit DCOM permissions in dcomcnfg, click "Apply" on that one app only — never hit "Apply to all" under the COM+ tab unless you want this error.
Back up the COM+ catalog periodically by exporting each COM+ application to a .msi file (right-click > Export). If the catalog blows up, re-import takes two minutes.
After a Windows update that fails, run dcomcnfg -repairdatabase preemptively. It costs nothing and catches corruption early.

The reason step 3 works is that -repairdatabase rebuilds the .clb binary files from the registry. If the registry CLSID entries are intact, you get a clean catalog. If they're also corrupted, then you need SFC or a restore point. But 9 times out of 10, the catalog files are the only thing broken — a leftover from a partial update that left orphaned writes in those files.