Fix ERROR_LOG_MULTIPLEXED (0X000019E6) – Log Multiplexed

Quick answer

Stop the service that opened the log, then restart it. If that doesn't work, use logman stop <session name> to release the handle.

What this error actually means

This error tripped me up the first time I saw it on a Windows Server 2019 box running a custom ETW trace. The event log system in Windows uses multiplexed logs for efficiency—multiple writers can push events to the same physical log file. But you can't write directly to that physical log when it's multiplexed. It's like trying to scribble on a whiteboard that's already being shared by three people with markers. The system says: back off, you can't go straight to the file.

You'll typically see this error when a tool or script tries to open the log file with OpenEventLog or BackupEventLog while an active ETW session or service has it locked. I've also seen it after a system crash when a log handle didn't close cleanly.

How to fix it

1. Identify what's holding the log. Open Event Viewer (eventvwr.msc). Check under Windows Logs > Application or System for recent events from source EventLog or Microsoft-Windows-Eventlog with IDs like 1101 or 1102. These tell you the log name and session.
2. Stop the service or session. If it's a third-party service (like a backup agent), restart it: net stop "Service Name" && net start "Service Name". For ETW sessions, use logman stop <session name> -ets. You can list sessions with logman query -ets.
3. Clear the log file handle. As a last resort, stop the Windows Event Log service: net stop EventLog. Then restart it: net start EventLog. This forces all handles to close. But be warned—you'll lose any unflushed events.
4. Check for locked file handles. Use handle.exe from Sysinternals or openedfiles to see which process has the log file open. Look for paths like C:\Windows\System32\winevt\Logs\*.evtx.

If the main fix doesn't work

Sometimes the handle is stuck because of a buggy driver or a corrupted log file. Here's what else to try:

• Rename the log file. Stop the EventLog service, go to C:\Windows\System32\winevt\Logs\, rename the problematic .evtx file (e.g., to Application.old.evtx), then restart the service. Windows will create a new empty log. You'll lose the old events, but the error goes away.
• Run wevtutil to clear the log. Open Command Prompt as Administrator. Run wevtutil cl Application (replace with your log name, like System or Security). This clears it without restarting the service.
• Reboot. I hate saying it, but if a log handle is hung by a kernel-mode driver, a reboot is the cleanest path. Schedule one if you can.

Prevention tip

Don't write scripts that open event logs with direct file I/O. Always use the Windows API calls like OpenEventLog or EvtOpenLog. If you're writing a tool that consumes logs, use wevtutil, PowerShell's Get-WinEvent, or the EventLog class in .NET. Those handle multiplexing automatically.

Also, avoid running multiple backup or monitoring tools that try to read the same log file simultaneously. If you see this error pop up weekly, check your monitoring agents—there's probably a conflict.