Fix CO_E_INIT_SCM_FILE_MAPPING_EXISTS (0x8000400F) in Windows COM+

You're not the only one staring at this error

That 0x8000400F error usually shows up when a COM+ application tries to start and Windows says "The OLE service file mapping already exists." It's cryptic, it's annoying, and it usually happens at the worst possible time — right when a legacy app needs to connect. Let's fix it.

The quick fix

1. Open Task Manager (Ctrl+Shift+Esc). Go to the Details tab.
2. Look for dllhost.exe processes. There are often several. Sort by CPU usage.
3. Find the one that's eating CPU or memory — that's likely your hung COM+ host. Right-click and End task.
4. Restart the COM+ application from Component Services (or just let it restart automatically).

That clears the stale file mapping because the process that held it is gone. The mapping dies with the process.

Why does this work?

Here's what's actually happening. COM+ uses file mappings to share state between the client and the server component. Normally, the mapping is cleaned up when the last handle closes. But if a dllhost.exe crashes or hangs — maybe due to a deadlock in your component, a leaked COM reference, or even a PowerShell script that called New-Object -ComObject and never released it — the mapping stays alive in the kernel. When the COM+ runtime tries to create a new mapping with the same name, it gets 0x8000400F.

Killing the process releases all its kernel objects, including that orphaned file mapping. The next start attempt succeeds because the name is free again.

When the process kill isn't enough

Sometimes the mapping persists even after you kill dllhost.exe. That happens when the mapping is held by a different process — often the client that called into COM+ and then crashed without cleaning up. In that case:

Restart the DCOM Server Process Launcher

net stop dcomlaunch && net start dcomlaunch

That restarts the DCOM infrastructure and forces all COM+ applications to stop. It's a nuclear option, but it works. Do this from an elevated command prompt.

If that still fails, reboot

Honestly, if both of the above don't clear it, a reboot is your friend. The mapping lives in the system's paged pool; a reboot wipes it. Don't waste time hunting for some hidden handle — reboot and move on.

Less common variations

You might see 0x8000400F in a few other places:

• IIS worker process: An ASP.NET app using COM+ components throws this in the event log. Same fix — recycle the app pool or run iisreset.
• Outlook or Office add-ins: Old add-ins that use COM interop can leave mappings behind. Restart Outlook, and if that fails, kill any lingering outlook.exe processes.
• Windows Services that host COM objects: Restart the specific service first, then try dcomlaunch if needed.

In all these cases, the underlying cause is identical: a process died without releasing a named kernel object.

Prevention

You can't stop every hang, but you can reduce the frequency:

• Check your components for resource leaks. If you wrote the COM component, make sure every CoCreateInstance has a matching Release. Use COM best practices.
• Set COM+ application pooling. In Component Services, right-click your app → Properties → Pooling. Enable it with 1–5 minutes. That way a hung instance gets recycled automatically, and the mapping never stays stuck.
• Monitor dllhost.exe count. If you see more than a handful, something's off. Use Process Explorer to see which component each host is running.
• Keep Windows updated. Microsoft has fixed several COM+ deadlock bugs in cumulative updates. The classic one in Server 2016 got addressed in KB4051613, but later updates have more.

That's the whole picture. The error looks scary, but ninety percent of the time it's a hung process holding a kernel object hostage. Kill it, restart, move on.