Fix ERROR_LOG_CONTAINER_STATE_INVALID 0x19F2

Your log container service or VHD is stuck in an invalid state, usually from a dirty shutdown or disk-full event. Here's how to get it back online without nuking the host.

Quick answer: Stop the dependent services, detach and re-attach the log container VHD (or reset the container directory), run wevtutil to rebuild the log manifest, then restart. In 90% of cases the container is fine — the metadata lock is what's broken.

LOG_CONTAINER_STATE_INVALID means the service that owns the log container found the container's state flag set to something it can't act on — mounted, dirty, orphaned, or mid-transition. The kernel returns 0x19F2 when the caller's expected state (say, "Active") doesn't match what the container's metadata says (say, "Dirty"). It shows up most on Windows Server 2019 and 2022 boxes running clustered roles, WEF (Windows Event Forwarding) collectors, or Docker on Windows with a VHD-backed log volume. I've seen it after a host lost power mid-checkpoint, after a CSV drained its free space to zero, and honestly more than once after somebody snapshotted a VM with the container mounted and then reverted. The container wasn't corrupt in any of those cases. The state byte was.

Why this happens

Dirty shutdown: the host or VM died before the container could commit its state change from Dirty back to Active.
Zero free space: the log volume filled up and the checkpoint write failed silently.
Snapshot revert: you rolled a VM back while the VHD was held open. Metadata now points at a state that doesn't exist anymore.
Stale CSV ownership: a cluster node went down, the container failed over, and the old owner still holds the lock.
Bad driver update: I've seen a specific storage miniport revision cause this on NVMe arrays more than once. Not naming names, but check your HBA firmware notes.

Fix it step by step

Do these in order. Don't skip to chkdsk — that's wasted time on this error, and on a 4TB log volume it's hours you won't get back.

Stop the writers. Anything holding the container open has to go down first. For WEF collectors that's the Windows Event Collector service. For containers it's the Docker service plus the HNS service.
```
Stop-Service -Name Wecsvc -Force
Stop-Service -Name docker -Force
Stop-Service -Name hns -Force
```
Confirm the container's current state. Mount the VHD read-only and check the metadata. If you're on a raw volume rather than a VHD, skip to step 4.
```
Mount-VHD -Path C:\Logs\container.vhdx -ReadOnly
Get-Disk | Where-Object Location -Like '*container*'
```
Dismount cleanly and remount. The remount writes a fresh state commit. This alone clears the error maybe half the time.
```
Dismount-VHD -Path C:\Logs\container.vhdx
Mount-VHD -Path C:\Logs\container.vhdx
```
Rebuild the log manifest. This is the part people miss. The event log's internal manifest still thinks the container is in the old state. Force a re-registration:
```
wevtutil um C:\Windows\System32\winevt\Manifests\container.man
wevtutil im C:\Windows\System32\winevt\Manifests\container.man
```
Adjust the manifest path to match whatever you've got registered. If you're not sure, wevtutil el lists every log currently registered.
Check the container ACLs. Every time I've seen this in a clustered setup, someone had edited NTFS permissions on the container path and stripped NT VIRTUAL MACHINE\Virtual Machines or the cluster service SID. Restore the defaults if so.
Bring the services back. Watch the System log for 0x19F2 during startup. If it doesn't reappear within 60 seconds, you're done.
```
Start-Service -Name hns
Start-Service -Name docker
Start-Service -Name Wecsvc
```

If that didn't work

At this point you're dealing with a genuinely bad container, not just bad state. Two options.

Option A: Move the container

On a cluster, move the role to another node and let the new owner re-acquire. This forces a state refresh on the storage side too.

Move-ClusterGroup -Name 'LogContainer' -Node NODE02

Option B: Recreate the container

Export what logs you can still read, then rebuild. Yes, you lose history. No, there's no reliable way to salvage a container whose state byte is corrupted — I've tried, and the last time cost me a weekend I'm still bitter about.

$logs = wevtutil el | Where-Object { $_ -like 'Container*' }
foreach ($l in $logs) { wevtutil epl $l "C:\Backup\$l.evtx" }
New-VHD -Path C:\Logs\container-new.vhdx -SizeBytes 500GB -Dynamic

Prevention

Three things actually help here, and one that doesn't.

Alert on free space below 15% on any log volume. Set it as a hard alert, not a warning. This error is the #1 cause I see and it's 100% preventable.
Use clean shutdown scripts on VM hosts and cluster nodes. A forced power-off leaves the container Dirty and you get 0x19F2 on next boot.
Don't snapshot live log containers. Snapshot the host, or stop the writers first. Reverting a snapshot with the VHD mounted is a guaranteed way to reproduce this error.

The one that doesn't help: running sfc /scannow. It won't touch the container's metadata. Skip it.