Fix ERROR_LOG_METADATA_INCONSISTENT 0X000019D6

This error hits when Windows' event log metadata gets corrupted. The fix is to stop the EventLog service, rename the metadata files, and let Windows rebuild them fresh.

Quick answer: Stop the Windows Event Log service, rename the EventMetadata folder files in C:\Windows\System32\winevt\Logs, and restart the service so Windows rebuilds the metadata from scratch.

You're seeing ERROR_LOG_METADATA_INCONSISTENT (0X000019D6) in the System log, probably right after a hard reboot or a storage hiccup. The message reads something close to "The log service encountered a metadata file with inconsistent data." What happened is that the .evtx log file and its matching metadata registry entry no longer agree on what channels exist, how big the file is, or which file IDs belong to which channel. Windows refuses to load the channel until someone reconciles the two. A very common trigger: an unclean shutdown on a VM where the underlying datastore got yanked mid-write, or a backup agent that opened the log for read while the service was still flushing. Either way, the metadata is toast and the service will keep complaining until you rebuild it.

Before you touch anything, back up C:\Windows\System32\winevt\Logs and the registry key HKLM\SYSTEM\CurrentControlSet\Services\EventLog. That's not optional. If you rename the wrong file, you lose months of logs you might actually need for an audit.

Main fix: rebuild the event log metadata

Open an elevated PowerShell or CMD window. Right-click the Start button, pick "Terminal (Admin)" or "Windows PowerShell (Admin)." Click Yes on the UAC prompt. You should see the window title start with "Administrator."
Stop the Event Log service.
```
net stop EventLog
```
You should see "The Windows Event Log service was stopped successfully." If it says it can't stop because of dependent services, run sc query EventLog and check which services list it as a dependency. On most servers there aren't any, but third-party monitoring agents sometimes cling to it.
Stop the Windows Event Collector service too (it usually runs alongside and will fight you):
```
net stop Wecsvc
```
Expected output: "The Windows Event Collector service was stopped successfully."
Rename the metadata folder. Windows keeps per-channel metadata in a subfolder that the service writes at startup. Renaming it forces a clean rebuild.
```
cd C:\Windows\System32\winevt
ren Logs Logs.bak
```
If the folder is locked, something still has a handle on it. Run handle.exe winevt from Sysinternals to find the culprit, or just reboot into Safe Mode and do it there.
Rename the registry subkeys that hold per-channel config. Fire up regedit.exe and go to:
```
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application
```
Rename the entire Application key to Application.bak. Do the same for System and Security underneath EventLog. Windows recreates these on next service start with default channel definitions.
Restart the services.
```
net start EventLog
net start Wecsvc
```
You should see "The Windows Event Log service was started successfully." within a few seconds. If it hangs, check Event Viewer under a different admin session — you'll often see the same 0X000019D6 error logged once more as the service tries to load the old metadata before falling back to a rebuild.
Confirm the rebuild. Open Event Viewer, expand Windows Logs, and click Application. You should see new events appearing with today's date. The old Logs.bak folder still holds your old .evtx files if you need to pull history from them later — just open them as saved logs.

Heads up: renaming the registry keys drops any custom channel registrations you added for third-party apps (Exchange, SQL Server, IIS log shipping, etc.). Those apps will re-register on next service start, but if one doesn't, you'll need to reimport its manifest with wevtutil im.

If the main fix doesn't work

Check disk health first. Metadata corruption on a healthy disk is rare. Run chkdsk C: /scan and then look at the SMART data with Get-PhysicalDisk | Get-StorageReliabilityCounter in PowerShell. If reallocated sector count is climbing, you've got a failing drive and rebuilding logs will just buy you a week.

Run a targeted SFC and DISM pass. The Event Log DLLs themselves can get corrupted during the same crash that killed the metadata.

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

Both should report no integrity violations when done. If SFC fixes files, reboot before retrying the rebuild above.

Manually rebuild individual channels. If only one channel is broken (say, Microsoft-Windows-TerminalServices-LocalSessionManager/Operational), you don't need the full nuke — just clear that one:

wevtutil cl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Then re-enable it:

wevtutil sl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /e:true

Last resort: restore from backup. If you have System State backup, restore just the EventLog registry hive and the winevt\Logs folder from before the incident. Restoring the whole server for event logs is overkill.

Prevention

Give the Event Log service time to flush before you yank power or force a VM shutdown. On Hyper-V and VMware, use the integration services' graceful shutdown rather than "Power Off." On physical boxes, size your C: drive so the log files have 2-3 GB of free headroom — running the volume near full is the second-most-common cause of this error after unclean shutdowns. Set a scheduled task to run wevtutil epl weekly and archive logs off-box; that way even if metadata dies, your history is safe elsewhere. And if you're running a monitoring agent that reads the Security log, configure it to open with FILE_SHARE_READ rather than holding an exclusive handle — agents that lock logs are a steady source of 0X000019D6 reports.