Fix CO_E_INIT_SCM_MAP_VIEW_OF_FILE (0X80004010) fast

You're staring at 0X80004010 and it's not obvious why

This error pops up when OLE (Object Linking and Embedding) tries to map a view of a file and can't. I've seen it mostly on Windows Server 2012 R2 and 2016 boxes running older COM+ applications or DCOM services. One client had it on a file server running an in-house inventory app—every morning the service would crash with this exact code. The root cause is almost always one of two things: a blown-out temp folder or corrupt registry permissions. Let's skip the guesswork.

The fix that works 9 times out of 10

Reset the temp folder. Here's the step-by-step that saved me hours once I figured it out.

Step 1: Clear the temp folder

1. Press Win + R, type %temp%, hit Enter.
2. Select everything in that folder and delete it. You'll get "file in use" errors for some—skip those. I use Shift + Delete to bypass the recycle bin.
3. Do the same for C:\Windows\Temp and C:\Users\[YourUser]\AppData\Local\Temp.

Had a client last month whose print queue died because of this—a locked temp file from a failed printer driver install was blocking OLE. Clearing all three folders fixed it instantly.

Step 2: Re-register OLE

Open an elevated Command Prompt (right-click, Run as Administrator) and run:

regsvr32 /u /s oleaut32.dll
regsvr32 /s oleaut32.dll
regsvr32 /u /s ole32.dll
regsvr32 /s ole32.dll

This re-registers the core OLE libraries. Don't skip the unregister step—I've seen leftover registrations cause issues.

Step 3: Reset permissions on the temp folder

If the error persists, permissions are the next suspect. Right-click the temp folder (say %temp%), go to Properties > Security. Make sure the SYSTEM account and your user have Full Control. I use this PowerShell one-liner to reset it quickly:

icacls $env:TEMP /grant "SYSTEM:(OI)(CI)F" /grant "BUILTIN\Administrators:(OI)(CI)F" /T /Q

That grants SYSTEM and Administrators full control recursively. Reboot after running it.

Why this works

OLE uses memory-mapped files to share data between processes—think COM objects passing large blobs of data. When it can't create a file mapping, it's because the underlying file (in the temp folder) is corrupt, locked, or missing. Resetting the temp folder clears corrupted files. Re-registering OLE fixes broken registry entries that tell OLE where to find its library. Fixing permissions ensures the SYSTEM account—which runs most COM+ services—can write to the temp folder.

The error code 0X80004010 maps to CO_E_INIT_SCM_MAP_VIEW_OF_FILE, which literally means the Service Control Manager (SCM) couldn't map a view of the file. The SCM is just the middleman—it's the temp folder that's the bottleneck 90% of the time.

Less common variations

Sometimes the temp folder isn't the culprit. Here are two edge cases I've hit.

Corrupt registry key for the COM+ application

If a specific app always triggers the error, check its registry entry under HKEY_CLASSES_ROOT\AppID\{YourAppGUID}. I had a case where the RunAs value was set to a deleted user account. Delete the RunAs key or update it to a valid account.

Anti-virus interference

Some AV software (looking at you, old Symantec Endpoint Protection) hooks file operations and blocks OLE's memory-mapped file creation. Temporarily disable the AV to test. If that fixes it, create an exclusion for the temp folder and the OLE DLLs (ole32.dll, oleaut32.dll).

Prevention

Stop this from coming back. Set up a scheduled task to clear the temp folders weekly. I use this PowerShell script on a monthly schedule:

$tempFolders = @("$env:TEMP", "$env:WINDIR\Temp", "$env:LOCALAPPDATA\Temp")
foreach ($folder in $tempFolders) {
    Get-ChildItem -Path $folder -Recurse -Force | Where-Object { !$_.PSIsContainer } | Remove-Item -Force -ErrorAction SilentlyContinue
}

Also, when you install any COM+ or DCOM-based app, check that the installer isn't dumping temp files in a custom path—had a client whose ERP installer used D:\Temp that didn't exist. Always run those installers as Administrator to avoid permission issues.

Final note: if you're on a domain, make sure Group Policy isn't redirecting temp folders to a network share. OLE needs local file handles—network paths break memory-mapped files. That one took me two days to track down once.