Yeah, this one's annoying. You're probably seeing it in Event Viewer or when an app tries to write to the Windows log service, and it just refuses to cooperate. Let's cut to it.
The Fast Fix: Clear the Corrupted Log Files
The error means the log service found a metadata file whose contents don't match what it expects. In plain terms: a log file is corrupted, and the service won't trust it. The most reliable way out is to delete the offending log files. The service recreates them on demand.
- Open an elevated Command Prompt (Run as administrator).
- Stop the Windows Event Log service. This locks the files so you can touch them.
net stop eventlog - Now clear out the log files. The default location is
C:\Windows\System32\winevt\Logs. You can delete individual files or all of them. If you're not sure which one is corrupted, nuke the whole folder's contents.
del /q C:\Windows\System32\winevt\Logs\*.evtx - Restart the service.
net start eventlog - Open Event Viewer and verify logs are populating again.
That's it. It's blunt, but it works. You lose old logs, but they were already suspect anyway.
Why This Works
What's actually happening here is that each .evtx file has a metadata header that describes its structure, and the service maintains a separate index of known-good metadata. When a file's header doesn't match the expected checksum or structure, you get STATUS_LOG_METADATA_INCONSISTENT. The service refuses to read it, and depending on the log, it might even refuse to start.
Deleting the files removes the bad metadata entirely. The service starts fresh and writes new metadata as new events come in. There's no repair tool for .evtx files—Microsoft assumes you'll just clear them. That's why the fix is so direct.
One nuance: if the corruption is in the system's own operational log (like System.evtx), you might need to boot into Safe Mode or use the Windows Recovery Environment to delete it, because the service might be holding it tightly. But in most cases, stopping the service is enough.
What If the Error Persists?
If you've deleted the logs and the error still shows up, the corruption isn't in the .evtx files themselves. It could be in the registry settings that define the log paths or in the service's own configuration.
- Check the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog. Each subkey corresponds to a log. Look for theFilevalue—make sure it points to a valid path. Sometimes a leftover pointer to a deleted file causes the same error. - If the registry is fine, try a system file check:
sfc /scannow. This doesn't often fix metadata issues, but it catches underlying system file corruption that might be triggering it. - Another remote possibility: your disk has bad sectors. Check with
chkdsk /fon the system drive. A failing drive can corrupt files at rest, and this error is a symptom.
Less Common Variations
This error doesn't only appear in Event Viewer. You might trip over it in a few other scenarios.
1. After a Power Loss or Forced Shutdown
A sudden power cut can leave the metadata file half-written. You'll likely see this error on the next boot, and the system might hang on the log service start. The fix is the same—boot into Safe Mode if needed and clear the logs.
2. When Using Custom Logs in Applications
If you're a developer and your app writes to a custom log via the Windows Event Log API, a bug in your own code could write inconsistent metadata. In that case, delete only your custom log's .evtx file, not the system ones. You don't want to lose security logs if you can help it.
3. In Server Clusters or with DFS Replication
On domain controllers or clustered servers, replicate the logs to a read-only copy. If a replication partner holds a corrupted metadata file, you might see the error on the source server when it tries to read the remote log. The fix here is to break the replication temporarily, clear the local logs, and then re-establish replication.
Prevention: Stop It From Happening Again
You can't completely avoid corruption, but you can lower the odds.
- Use a UPS. Most of these issues trace back to unclean shutdowns. A decent UPS with automatic shutdown software is cheap insurance.
- Set log size limits. If your logs grow without bound, they're more likely to hit file fragmentation or disk write errors. In Event Viewer, right-click a log, go to Properties, and set a reasonable max size (say, 20 MB for system logs). Enable "Overwrite events as needed" so the file doesn't balloon.
- Schedule regular log exports. If you clear logs frequently, you lose history. Set up a weekly task to export important logs to a separate location. Then you can clear them freely without fear.
- Don't manually edit
.evtxfiles. I've seen people try to merge logs with a hex editor. That's a one-way ticket to metadata inconsistency. Use the proper APIs or tools likewevtutilto export and import logs.
The blunt fix is your best friend here. Don't overthink it. Delete the bad logs, move on, and make sure your next shutdown is a clean one.