EVENT_E_QUERYFIELD 0x80040204: Fix Invalid Query Field

Quick answer

EVENT_E_QUERYFIELD (0x80040204) means your event query string references a field that the Windows Event Log schema doesn't recognize. Fix the XPath or SQL filter to use valid field names from the event schema.

What's actually happening here

When you query the Windows Event Log — whether through Event Viewer's custom view, Get-WinEvent, or a C++ EvtQuery call — the query is parsed against the event schema. The schema defines every legal element name: EventID, Provider, Level, TimeCreated, Message, Task, Keywords, Data, and so on. The moment the parser hits a token it can't map to a schema element, it returns EVENT_E_QUERYFIELD with HRESULT 0x80040204. The error is deliberately vague — it doesn't tell you which field is wrong, only that one of them is.

The most common trigger I've seen in the wild is an XPath query that looks reasonable to a human but isn't valid: *[System[EventID=4624 and Username='admin']]. There's no Username element in the event schema — the user is nested inside EventData as a named Data element. Same thing happens when someone drops EventID='4624' with quotes into an XPath, or uses Source instead of Provider Name. It's a schema mismatch, not a corrupt log.

Fix it step by step

Find the offending field. Run the query through Get-WinEvent with -FilterXPath and you'll get a stack trace pointing at the token. With a raw EvtQuery call, log the failing filter string first — that's usually enough to spot the typo.
Check the field against the schema. In Event Viewer, open any event of the target type and click the Details tab, then switch the dropdown to XML View. Every element shown there is a valid query field. Anything not shown there is not.
Rewrite the query with the correct element. If you meant to filter on the username inside event data, you can't do it in a simple XPath selector against a named Data field directly — you either filter by EventID first, or use a structured XML query. Example of a valid XPath:

*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4624]]

Notice: Provider is an element with a Name attribute, not a bare Source. EventID is a number, no quotes. That's the shape the parser wants.

If you need to filter on Data fields, use a structured XML query instead of XPath. The QueryList/Select form supports Suppress and Data selectors that XPath doesn't:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[EventID=4624]]</Select>
    <Suppress Path="Security">*[EventData[Data[@Name='TargetUserName']='SYSTEM']]</Suppress>
  </Query>
</QueryList>

That's valid. It also runs faster than post-filtering in PowerShell because the event service does the work.

Re-run and confirm. A clean result set means the parser accepted every field. If you still get 0x80040204, bisect — remove half the conditions and try again. The error will disappear when you cut the bad field.

If that doesn't fix it

Case sensitivity in attribute values. Element names in XPath are case-sensitive. eventid won't match EventID. This burns people who copy queries between different logging tools.
Wrong log path. If your query says Path="Application" but you're actually querying a channel like Microsoft-Windows-TaskScheduler/Operational, some fields valid in one schema won't be in the other. Check the channel name exactly.
Old WMI-style queries. If you copied a Win32_NTLogEvent WQL query like SELECT * FROM Win32_NTLogEvent WHERE SourceName='...' and pasted it into an XPath filter, it will fail instantly. WQL and Event Log XPath share syntax style but not field names. SourceName in WQL maps to Provider/@Name in XPath.
Corrupt filter XML. If the XML itself is malformed — unclosed tag, wrong namespace — you'll sometimes get EVENT_E_QUERYFIELD instead of the more obvious ERROR_INVALID_XML. Validate the XML with [xml]$query in PowerShell before passing it in.

Prevention

Stop hand-writing queries. Use Event Viewer's Filter Current Log dialog to build the filter visually, then click the XML tab and copy what it generated. That output is guaranteed to be schema-valid. If you're writing PowerShell, prefer Get-WinEvent -FilterHashtable for common fields — it takes LogName, ProviderName, Id, Level, StartTime, EndTime, and builds the XPath for you, so you can't typo a field name. Reach for raw XPath only when you actually need the flexibility, and validate against a known event's XML view before you ship it into a scheduled task or monitoring script.