ERROR_EVT_QUERY_RESULT_STALE (0X00003AA3): Windows Event Log Fix

You're running a query against the Windows Event Log, and it dies with ERROR_EVT_QUERY_RESULT_STALE — hex 0X00003AA3. The event viewer window freezes, your script throws, or your monitoring tool loses its feed. This error means the query result set you're holding has gone stale. In plain English: the log changed underneath you, or the handle you're using is no longer valid.

The most common trigger I see is a long-running query against a busy log. Say you kicked off a wevtutil qe Security /f:text /rd:true at 2 AM and let it run while the Security log rolled over at 20 MB. Halfway through, the log rotated, your result set got invalidated, and the query returned 0X00003AA3. Same thing happens with Event Viewer left open overnight on a Domain Controller pushing thousands of events per minute.

Cause 1: The Event Log service needs a restart (fix this first)

This is the fix that resolves the majority of cases. The Windows Event Log service (internal name eventlog) manages log handles and rotation. If it's wedged, every query you throw at it comes back stale. Restart it and re-run your query.

1. Press Win + R, type services.msc, and hit Enter. The Services window opens.
2. Scroll to Windows Event Log. Don't confuse it with Windows Event Collector — different service, different job.
3. Right-click it and choose Restart. If Restart is greyed out, click Stop first, wait for the status to clear, then click Start.
4. After the service shows Running again, close and reopen Event Viewer.

You can do the same from an elevated Command Prompt in one shot:

net stop eventlog && net start eventlog

Watch the output. You should see two lines: The Windows Event Log service was stopped successfully and The Windows Event Log service was started successfully. If either fails, you've got a deeper problem — check the System log for Service Control Manager events 7000 or 7009.

If restarting eventlog breaks your event forwarding setup, don't panic. Windows Event Collector reconnects on its own within about 30 seconds. Give it a minute before you start troubleshooting.

Cause 2: Your query handle expired because the log rotated

Logs have a maximum size. When they hit it, Windows archives them as .evtx and starts fresh — or overwrites the oldest entries, depending on your retention setting. Either way, any open query against that log gets invalidated. The result set you were iterating is now pointing at data that doesn't exist in the current log file.

The real fix is to not hold a long-lived query in the first place. Rebuild the query each time you poll, and always pass a time window so Windows doesn't have to scan the whole log:

wevtutil qe Application /q:"*[System[TimeCreated[timediff(@SystemTime) <= 300000]]]" /f:text /rd:true /c:50

That query pulls the last 5 minutes of Application events, newest first, capped at 50. Run it, close the handle, run it again next cycle. No stale results, no 0X00003AA3.

If you're using .NET, the same rule applies. Don't cache an EventLogReader across polls. Create it, read, dispose it. The EventLogQuery object itself is cheap to build — the expensive part was the handle, and that's exactly what goes stale.

Also check your log sizes while you're in there. Right-click the log in Event Viewer, pick Properties, and look at Maximum log size. If it's under 20 MB on a busy machine, you're rotating constantly and inviting this error. Bump Application and System to 100 MB. Security to 200 MB if you've got the disk. Reboot isn't required — the new size takes effect immediately.

Cause 3: Corrupted log file or broken query XML

Less common but nastier. The .evtx file itself can be damaged from a hard power loss or a full disk during a write. Windows notices, flags the log as corrupted, and any query against it returns stale results because the underlying data can't be read.

Check for this by opening the log in Event Viewer. If you see "The event log file is corrupt" or entries just stop appearing past a certain timestamp, that's your smoking gun. You can also verify from the command line:

wevtutil gli Application

Look at numberOfLogRecords and lastWriteTime. If lastWriteTime is hours old on a machine that's actively running, the log is stuck. Rebuild it:

1. Open an elevated Command Prompt.
2. Clear the log: wevtutil cl Application. You'll lose existing entries — export them first if you need them.
3. Restart the Event Log service as shown in Cause 1.
4. Re-run your query. It should return clean.

The other half of Cause 3 is a malformed XPath. Event Log queries use XPath 1.0 with Microsoft's own extensions, and a single bad predicate throws odd errors — sometimes ERROR_EVT_QUERY_RESULT_STALE when you'd expect a syntax error. Test your query in Event Viewer's Filter Current Log dialog first. Open XML tab, paste your query, click OK. If Event Viewer chokes, your script will too.

Common gotchas: using and instead of and in the right spot (it's lowercase), forgetting quotes around string values, or referencing a Data element that doesn't exist in that event. Fix those before you blame Windows.

Quick reference

Start with the service restart — it costs you thirty seconds and fixes most cases. If the error comes back, look at your log size and query lifetime. Stale results are almost always a symptom of a handle held too long against a log that moved underneath it.