NERR_LogFileChanged (0X0000094A): The log file changed between reads

What's actually happening here

The error code 0X0000094A maps to NERR_LogFileChanged — defined in the Windows Network Management API as NERR_Base + 74 (2100 + 74 = 2174 decimal). The NERR_ prefix tells you this isn't a generic system error; it's a network management error, specifically from the old NetAdmin API or its modern wrappers.

What's happening is simple: a process opened a log file for reading, read some data, then tried to read the next chunk — and Windows told it the file's timestamp, size, or content changed between those two reads. The OS won't let the reader continue because the data it already read might conflict with the new data. This is a consistency guard, not a bug.

You'll see this most often in two real-world scenarios:

• Running eventvwr.msc — the old Windows Event Viewer — while the Event Log service is actively writing to the same .evtx file. This happens constantly on busy servers.
• Using a third-party log reader or backup tool (like Veeam, SolarWinds, or custom scripts that tail Event Log files) that polls the .evtx directory directly instead of using the Windows Event Log API.

Cause #1: The Event Log service is writing while you're reading

This is the most common trigger. The Windows Event Log service (EventLog) writes to Windows\System32\winevt\Logs\*.evtx continuously. If you open one of those files with any tool that doesn't lock it properly — including old versions of Event Viewer — you get 0X0000094A.

The fix: Restart the Event Log service (temporarily)

1. Open Command Prompt as Administrator.
2. Run net stop EventLog. This kills the service that's writing to the files.
3. Run your log-reading tool — it should now read without conflict.
4. After you're done, run net start EventLog to bring the service back.

Why this works: Stopping the service removes the writer. The reader gets exclusive access. The downside: during the service stop, no new events are logged system-wide. On a production server, this means a gap in security auditing. Don't do this during business hours unless you're okay with that.

Real-world scenario: A sysadmin running a PowerShell script to export Application.evtx for analysis every 5 minutes. The script opened the file with [System.IO.File]::OpenRead() instead of using Get-WinEvent, which uses the proper API. The fix was switching to Get-WinEvent — no service restart needed.

Cause #2: Multiple readers, same file, no coordination

You might have two tools — say, a log parser and a monitoring agent — both trying to read the same .evtx file at the same time. Neither one knows the other exists, so neither locks the file properly. The OS detects the change and throws the error.

The fix: Use the Windows Event Log API instead of direct file access

The real fix isn't to restart services or add timeouts. It's to stop reading .evtx files like text files. The Windows Event Log API (wevtapi.dll) handles concurrent reads correctly. Tools that use it never see 0X0000094A.

• PowerShell: Use Get-WinEvent -LogName Application instead of Get-Content C:\Windows\System32\winevt\Logs\Application.evtx. The former uses the API. The latter doesn't.
• C#: Use System.Diagnostics.EventLog or System.Diagnostics.Eventing.Reader.EventLogReader — both go through the API.
• Command line: Use wevtutil query-events instead of trying to copy the file with robocopy or xcopy.

Why this works: The API gives you a snapshot of the log at the moment you open the query. You read that snapshot. Meanwhile, the service writes to the live file. The API buffers the writes. You never touch the actual file directly — so you never trip the consistency check.

Cause #3: Corrupted or truncated .evtx file

Less common, but worth knowing: if the .evtx file itself is damaged — maybe from a crash, disk error, or improper shutdown — Windows might mark it as "changed" on every read attempt, even if nothing is writing to it. The OS is essentially saying "this file doesn't match its own internal checksum, so I treat every access as a potential modification."

The fix: Clear the log or use a backup

1. Open Event Viewer as Administrator.
2. Right-click the problematic log (Application, System, Security, etc.) and choose Clear Log. This deletes all events but repairs the file structure.
3. Alternatively, if you need the old events: locate the .evtx file in C:\Windows\System32\winevt\Logs\, copy it to a safe location, then restore from a backup copy.

Why this works: Clearing the log forces the Event Log service to recreate the file from scratch — no corruption. It's the nuclear option. Only do this if you've exhausted the first two fixes and you're sure the file is genuinely broken.

Real-world scenario: A Windows 10 laptop that blue-screened during a log rotation. After reboot, Security.evtx showed 0x0000094A every time Event Viewer tried to open it. Clearing the Security log (which requires elevated permissions) fixed it instantly.

Quick-reference summary

The 0X0000094A error isn't scary once you understand it's just Windows being cautious about data consistency. Skip the hacky workarounds — use the API, and you'll never see it again.