Recently, our support team received a bug report that Event Log Explorer was displaying incorrect task categories for Security event logs.
The user reported that on their Windows 11 24H2 and 25H2 systems, Event Log Explorer showed the same category for all security events.
At first, we couldn’t believe it — so we tested it ourselves.
Sure enough, we reproduced the issue immediately.
And yet, Windows Event Viewer displayed everything correctly.
🔍 Checking Older Windows Versions
Suspecting a Windows regression rather than a bug in our code, we tested on Windows 11 22H2 — and everything worked perfectly.
Even more interesting:
- Running Event Log Explorer on 22H2 to read logs from 24H2 → ✅ task names display correctly
- Running Event Log Explorer on 24H2 to read logs from 22H2 → ❌ task names display incorrectly
That ruled out our parsing logic and clearly pointed to an API-level problem in Windows 11 24H2 / 25H2.
🧪Testing Other Tools
To verify further, we tested with other event-log viewers.
NirSoft’s FullEventLogView
It showed the same issue — identical task names for every Security event.
Interestingly, Event Log Explorer and FullEventLogView even displayed different wrong names.
Microsoft’s Own Utilities
Let’s check wevtutil:
wevtutil.exe qe Security /c:30 /f:text > security.txt
When reviewing security.txt, we found that every event — even logon events — had the same category: User Account Management
PowerShell
Then we tried PowerShell:
Run PowerShell as Admin, type commands:
$Events = Get-WinEvent -LogName Security -MaxEvents 30
$Events | Select-Object -Property Id, Task, TaskDisplayName
Again — the same task name appears for different task IDs.
✅ Conclusion: this is a Windows Event Log API bug, not an Event Log Explorer issue.
But… why does the built-in Event Viewer still work?
⚙️ How the Windows Event Log API Works
Windows does not store the task category as text.
To save disk space, it stores a numeric ID, and software must resolve it to text using a message file.
In pre-Vista days, developers had to manually locate the category message file and extract text strings.
That process was slow, so caching was essential.
Modern Windows provides a cleaner API:
- Open event source metadata:
hMetadata = EvtOpenPublisherMetadata(…) - Retrieve task name:
EvtFormatMessage(hMetadata, hEvent, …, EvtFormatMessageTask, …) - Close the metadata handle:
EvtClose(hMetadata)
Developers often cache metadata handles to avoid reopening them repeatedly.
However, that optimization exposes a serious bug in recent Windows builds.
🐞The Root Cause
If you close and reopen the metadata handle, task names are resolved correctly. So I believe that Microsoft uses this ways in Event Viewer.
But if you reuse the same handle, EvtFormatMessage seems to cache results internally —
and that cache depends only on the metadata handle, not the task ID.
In other words:
Microsoft’s internal caching forgets to consider the task ID when formatting messages.
Interestingly, the semi-documented function EvtRpcMessageRender behaves correctly.
🧰 Our Fix in Event Log Explorer 5.7.2
As soon as we identified the cause, we released Event Log Explorer 5.7.2, which includes robust workarounds for this Windows API bug.
Affected programs:
- Event Log Explorer (all editions)
- Event Log Explorer Elodea Collector
- Event Log Database Exporter (Eldbx)
- Event Log Explorer Exporter (Logexport)
Depending on the module, we:
- Switched to using EvtRpcMessageRender, or
- Continued using the standard Windows Log API but explicitly closed and reopened metadata handles.
Internally, event tasks are now cached efficiently, preserving high performance.
✅ Recommendations
- Update immediately to the latest version of Event Log Explorer.
- If you use other event log utilities that haven’t implemented a workaround yet, switch to Event Log Explorer to ensure accurate task category display.
- PowerShell users: avoid relying on task category names until Microsoft releases an official fix.
🧩 Final Thoughts
This issue highlights how a subtle regression in a low-level Windows API can silently break multiple third-party tools.
While Microsoft’s Event Viewer remains unaffected, nearly all other log viewers — including ours — were impacted.
We’ve done our part to provide reliable workarounds.
Now we’re waiting for Microsoft to officially fix the API.
