"The description for Event ID cannot be found": fix it

You copy a Security.evtx off a suspect host, open it on your analysis workstation, and every record reads:

The description for Event ID 4625 from source Microsoft-Windows-Security-Auditing cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event.

Then a block of raw values: %%2313, 0xC000006A, 0x17. Nothing is broken and nothing is lost. The message is a rendering failure, not a data failure. This post explains where the description text actually lives, why it goes missing, how to fix it when you need to, and why, for triage, you usually don't. (If you just want the events readable now: the browser parser renders descriptions and decodes those codes offline.)

What the error actually means

An .evtx record does not store the sentence you read in Event Viewer. It stores the <System> block (provider, Event ID, time, computer) and the insertion strings in <EventData> or <UserData> (what is inside a record). The sentence, "An account failed to log on. Subject: … Failure Reason: …", is a template with %1, %2 placeholders stored in a message table resource inside a DLL or EXE belonging to the event provider.

Where Windows looks for that file depends on the provider type:

• Classic (legacy) event sources register under HKLM\SYSTEM\CurrentControlSet\Services\EventLog\<Log>\<Source>, with the path in the EventMessageFile value (plus optional ParameterMessageFile and CategoryMessageFile).
• Manifest-based providers (Vista and later, the Microsoft-Windows-* family) register under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{GUID}. The MessageFileName, ResourceFileName and ParameterFileName values point to binaries that carry the compiled manifest (WEVT_TEMPLATE resource) and the message table.

The key point: Event Viewer renders the message on the machine where you view the log, using that machine's registry and DLLs. The machine that wrote the event is irrelevant at display time. If the provider is not registered locally, there is no template, and you get the error followed by the raw insertion strings.

Common causes

• The log came from another host. The classic DFIR case. A third-party agent, an EDR, a SQL Server instance or a line-of-business app on the source host has no provider on your analysis workstation. Opening the file on macOS, Linux or a clean VM has the same effect: no Windows provider at all.
• Software was uninstalled. The uninstaller removed the DLL, but old events still reference the source.
• Missing, corrupted or moved DLL. The registry points to a path that no longer exists, or EventMessageFile is stored as REG_SZ instead of REG_EXPAND_SZ so %SystemRoot% never expands.
• 32/64-bit mismatch. A 32-bit installer wrote its DLL to what it thought was System32 (really SysWOW64 through file-system redirection), while the registered path is read by the 64-bit Event Log stack as the real System32.
• Locale. The provider's message table exists but not in the display language, or you opened an export saved "with display information" for a different language than the one your viewer uses.

The %% codes: parameter messages

Even when the main description renders, some fields show %%1833 or %%2313 instead of words. These are parameter message references: the value is an ID into a second message table, the provider's ParameterMessageFile / ParameterFileName. For the Security auditing provider that file is msobjs.dll. Offline, those references stay unresolved. The common ones worth knowing by heart:

The %%2080 %%2082 %%2084 triplet is the normal signature of a freshly created account in 4720. %%1937 on a 4688 is a process started with a full admin token after a UAC prompt.

Hex values are not %% codes. The Status / SubStatus fields of 4625 are NTSTATUS codes: 0xC000006A is a wrong password for a valid account, 0xC0000064 a user name that does not exist, 0xC0000234 a locked-out account. TicketEncryptionType on 4769 is a Kerberos etype: 0x17 is RC4-HMAC, 0x12 AES256. Both render as raw hex even when the provider is present.

Fix 1: export with display information

If you still have access to the source host, export the log so it travels with its messages. In Event Viewer: right-click the log, Save All Events As…, choose .evtx, and in the next dialog select Display information for these languages. Event Viewer writes a LocaleMetaData folder next to the file containing one .MTA file per language. Keep the folder beside the .evtx when you copy it; Event Viewer on the analysis machine picks it up.

From the command line:

wevtutil epl Security C:\ir\Security.evtx
wevtutil al C:\ir\Security.evtx /l:en-US

wevtutil al (archive-log) adds the locale metadata for an exported file. For collection at scale, see collecting EVTX from a live system.

Fix 2: install or repair the provider

On a machine you administer, where events from your own software don't render:

• Reinstall or repair the application that owns the source.
• Check EventMessageFile under HKLM\SYSTEM\CurrentControlSet\Services\EventLog\<Log>\<Source>: the path must exist, and the value type should be REG_EXPAND_SZ if it contains %SystemRoot%.
• For manifest providers, check Get-WinEvent -ListProvider <Name>; if it errors or lists no messages, the manifest registration is broken (wevtutil im <manifest>.man re-registers it, with the binaries in place).

Fix 3: render on the source host

Get-WinEvent renders the Message property only when the provider is present locally. On the source host (or a machine with the same software installed), this works:

Get-WinEvent -Path .\Security.evtx -MaxEvents 20 | Select-Object TimeCreated, Id, Message

On your workstation the same command returns an empty Message, but .Properties and .ToXml() still expose every value. More filtering recipes in querying EVTX with Get-WinEvent.

Fix 4: you usually don't need the message

For DFIR, the rendered sentence is a convenience. Every value it would display is in <EventData>: TargetUserName, LogonType, IpAddress, Status, SubStatus. Event Viewer's Details tab (XML View) shows them even when the General tab shows the error. Analysts working at scale read the fields directly anyway, which is how you should approach 4624 and the rest of the logon event family: the field names are stable across Windows versions and languages, while the rendered text is not.

Reading events offline in the browser

EVTX parser now shows a readable one-line description for about 60 common DFIR events: logons and 4625 failures, account and group changes, Kerberos 4768/4769/4771, NTLM 4776, services 7045/4697, scheduled tasks, Sysmon, PowerShell 4104 and RDP. It also decodes %% codes, NTSTATUS codes (0xC000006A wrong password, 0xC0000064 unknown user) and Kerberos ticket encryption types (0x17 RC4) inline. It needs no provider DLLs and no Windows; the file is parsed in your browser and never uploaded. For other ways to open the file, see how to open an EVTX file.

Checklist

• The error means the viewing machine lacks the provider, not that the record is damaged.
• Read <EventData> in the Details tab, Get-WinEvent .Properties, or a parser.
• Decode %% references against the table above; decode Status / SubStatus as NTSTATUS.
• Need the rendered text for a report? Re-export on the source host with display information (LocaleMetaData) or wevtutil al.
• For your own software, fix EventMessageFile or re-register the manifest.