Fixing ERROR_USER_MAPPED_FILE (0X000004C8) on Windows

When this thing shows up

You're trying to delete, move, or rename a file — maybe a database file, a log file, or a config file. Windows throws back ERROR_USER_MAPPED_FILE (0X000004C8). In plain English, it means some other program has that file mapped into memory, and Windows won't let you touch it while that's happening.

Had a client last month whose nightly backup script kept crashing on a server because one of their monitoring tools had a memory map open on a log file. Took me an hour to track down — but once you know the trick, it's a two-minute fix.

What's actually going on

When a program maps a file into memory (using CreateFileMapping and MapViewOfFile), it reads the file into RAM and keeps it there. This is common with databases, antivirus, backup agents, and some developer tools. The problem is that Windows sees this mapping as a lock — you can't delete or modify the file until every process unmaps it.

The error code 0X000004C8 maps to ERROR_USER_MAPPED_FILE. It's not a permission issue, and restarting the program that owns it usually works, but you don't always know which program that is.

The fix: find and kill the offending process

Skip the reboot if you can. Here's how to track down the process that's holding the file open — without guessing.

Step 1: Use handle.exe from Sysinternals

Download handle.exe from Microsoft's website. It's a command-line tool that shows which processes have open handles to a file.

Run this from an elevated command prompt (run as Administrator):

handle.exe -accepteula -a "C:\path\to\your\file.ext"

Replace the path with your actual file. The -a flag shows all types of handles, including memory-mapped sections. The output will show the process name (like notepad.exe or sqlservr.exe) and its PID.

Step 2: Identify the process with Process Explorer

If you prefer a GUI, download Process Explorer. Press Ctrl+F, type the file name, and hit Find. It'll list every process with a handle to that file, including memory-mapped ones.

Double-click the result to jump to that process. Look at the lower pane — it'll show the handle type. You're looking for Section or FileMapping.

Step 3: Kill or close the handle

You've got two choices:

• Kill the process — Right-click the process in Process Explorer and select Kill Process. Or use taskkill /PID 1234 in CMD (replace 1234 with the actual PID). This is nuclear but works.
• Close the handle — In Process Explorer, select the handle in the lower pane and press Ctrl+H to close just that handle. This is safer if the process does other things you need running.

Once the handle is closed, try your operation again. The error should be gone.

Step 4: Check for persistent issues

If the error keeps coming back, the program that maps the file is likely re-mapping it immediately. Common culprits:

• Antivirus real-time scanning (especially with database files)
• Backup software (VSS writers can keep memory maps)
• Database clients (SQL Server, Oracle, etc.)
• Monitoring agents (check your server's monitoring tool)

For antivirus, temporarily disable real-time protection. For backup software, stop the backup service. If it's a database, detach the database or stop the service before modifying files.

What if it still fails?

If the error persists after killing every obvious process, you might have a system-level memory map. Try these:

• Run chkdsk /f on the drive — file system corruption can sometimes leave phantom mappings.
• Check Windows Event Viewer under System and Application logs for clues.
• Reboot the machine — yes, it's the brute force fix, but it clears all memory maps.
• If it's a file on a network share, check if the server hosting the share has the file open. Use the same tools on the server.

One oddball case I saw: a developer had a Visual Studio debugger attached to a process that had memory-mapped a config file. Killing the debugger released the handle. Always check development tools and IDEs.

Pro tip: If this happens regularly to the same file, consider whether the file really needs to be memory-mapped. Some applications let you disable memory mapping via a config setting. For custom software, ask the developer to use FILE_FLAG_RANDOM_ACCESS or to close the mapping faster.

That's the whole deal. No need to reinstall Windows or mess with permissions. Just find the process, close the handle, and move on.