Get-WinEvent filtered query against ForwardedEvents crashes Windows Event Log service on Windows Server 2025

Environment:

1. Windows Server 2025 (build 26100.x), Domain Controller / member server acting as a WEF/WEC collector
2. Confirmed not reproducible on Windows Server 2022 with the identical subscription, query, and event volume — only Server 2025 is affected
3. ForwardedEvents populated via a standard source-initiated Windows Event Collector (WEC) subscription (SubscriptionType=SourceInitiated), forwarding from multiple Domain Controllers

What we're trying to do:

We read the local ForwardedEvents channel (populated by Windows Event Forwarding from our Domain Controllers) to collect security/logon-related events, using a structured/filtered query — either via PowerShell for manual testing, or programmatically via System.Diagnostics.Eventing.Reader.EventLogQuery in a .NET service. This is a standard, long-working pattern that has run without issue on Server 2016/2019/2022 for years.

What we tried

Manual repro via PowerShell:

Get-WinEvent -FilterHashtable @{LogName='ForwardedEvents'; Id=4624} -MaxEvents 10

Equivalent structured XPath query (also reproduces):

Get-WinEvent -LogName ForwardedEvents -FilterXPath "*[System[EventID=4624]]"

Also reproduces with a TimeCreated-only predicate (no EventID at all):

Get-WinEvent -LogName ForwardedEvents -FilterXPath "*[System[TimeCreated[@SystemTime>='2026-08-01T00:00:00Z']]]"

Expected behaviour:

The query returns matching events, exactly as it does against ForwardedEvents on Windows Server 2022, or as it does against any local (non-forwarded) log like Security on Server 2025 itself.

Actual behaviour:

Any of the above filtered/structured queries against ForwardedEvents specifically (not other logs) throws:

Get-WinEvent : The RPC server is unavailable

or, on repeated attempts:

Get-WinEvent : The remote procedure call failed

and — critically — this isn't just a query-level error. The Windows Event Log service itself crashes as a result:

1. Event ID 1001 (Application log) — APPCRASH, faulting module wevtsvc.dll, faulting process svchost.exe (the Event Log service host)
2. Event ID 7034 (System log) — "The Windows Event Log service terminated unexpectedly"

After the crash, all Event Log functionality on the box is disrupted until the service auto-restarts (or until Windows restarts it via SCM recovery), which is a much bigger blast radius than just "one query failed" — any other software depending on the Event Log service on that machine is affected for that window too.

What does not trigger it

An entirely unfiltered query against the same channel works fine and never crashes anything:

Get-WinEvent -LogName ForwardedEvents -MaxEvents 10

This strongly suggests the defect is specifically in how the Event Log service evaluates a structured/filtered query (<QueryList>/XPath predicate) against a channel populated via Windows Event Forwarding, as opposed to a channel populated by local event sources.

Workaround we've had to adopt

Detect Windows Server 2025 (or the affected build range) and fall back to reading ForwardedEvents unfiltered, then filter client-side in application code after the fact. This works, but it's strictly a workaround: it costs more CPU/IO (reading and discarding every forwarded event instead of letting the server-side query do it) and adds complexity we wouldn't otherwise need.

Questions

1. Is this a known/acknowledged defect specific to ForwardedEvents on Windows Server 2025?
2. Is there a hotfix, KB article, or planned cumulative update that addresses it?
3. Is there a supported alternative filtering mechanism for ForwardedEvents on Server 2025 that avoids triggering this crash, short of reading unfiltered and filtering client-side?

I found at least one other report describing the same symptom (APPCRASH on wevtsvc.dll, Event 7034) when filtering ForwardedEvents by time on Server 2025: Problem accessing ForwardedEvents on 2025 Windows Server (https://learn.microsoft.com/en-us/answers/questions/2241731/problem-accessing-forwardedevents-on-2025-windows) — that thread reports the same crash but with no resolution beyond downgrading to Server 2022. We can additionally confirm the crash triggers even with an EventID-only filter (no time predicate at all), which that thread didn't test, so the defect appears broader than just time-based filtering.