Read .evtx files without a Windows machine

The log is never on the machine you are sitting at

The pattern is always the same. Something happened — a suspected compromise, a lockout storm, a service that died at 03:00 — and the evidence is a Windows event log that someone exported, imaged or copied off a machine you cannot boot, cannot log into, or are not licensed to touch. Your own machine is a Mac, a Linux workstation or a locked-down corporate laptop with no Windows VM in sight. Event Viewer is not coming to help.

The good news is that an .evtx file is a documented, self-contained binary format. Everything Event Viewer shows you about a record — with one important exception covered below — is inside the file, and a proper parser can read it anywhere. The EVTX viewer on this site runs that parser (the Rust evtx crate, compiled to WebAssembly) in your browser tab, because event logs name users, machines and IP addresses and should no more be uploaded to a random converter site than a packet capture should. What follows is the working method, not the tool manual: what to look at, in what order, and what the fields will and will not tell you.

What is actually inside an .evtx file

An .evtx file is a 4096-byte header followed by a sequence of 64 KB chunks. Each chunk holds a run of event records, and each record is stored as binary XML (BinXML): a System block the operating system fills in, plus the provider’s own payload as EventData or UserData. Open one record and you find fields, not prose — EventID 4625, a timestamp, a channel, and named values like IpAddress, TargetUserName and LogonType. Those fields are the evidence. They are also all a parser on a foreign machine can honestly give you.

Here is the exception, and it shapes everything else in this guide: the sentence Event Viewer displays — “An account failed to log on” — is not in the file. Windows renders it at view time from message DLLs that belong to each provider and live on the machine that wrote the log. That is why data values sometimes look like %%14592: they are references into a message table the file does not carry. A viewer on another machine can show you every field the event recorded, and its raw XML exactly as stored — but a tool that presents polished message text for someone else’s .evtx is reconstructing it from its own DLL copies or guessing. Fields first, prose last, is the honest order.

One more structural fact worth knowing before you cite numbers: the file’s chunks are independent. A log carved out of a disk image, or copied off a dying drive, often has individual chunks that no longer parse. A good reader reports each damaged chunk with its byte offset and reads everything around it. Silence on this point — a tool that returns a shorter log and says nothing — is how records quietly disappear from an investigation.

Start with the System block

Every record’s System block carries the same skeleton: Provider (which component wrote it), EventID (what happened, in that provider’s numbering), Level (1 Critical through 5 Verbose, with 0 for events that carry no level), Channel (Security, System, Application, and the hundreds of operational logs under Microsoft-Windows-*), Computer, a UTC timestamp, and the EventRecordID. Triage starts by sorting a whole log into that skeleton: how many records, spanning what time range, from which channels, dominated by which Event IDs. A Security log that is 80% one event ID is usually a story about that one thing — a firewall deciding, a service authenticating in a loop — and the summary tells you before you read a single record.

Cite the EventRecordID from the System block when you reference a record. Files that were carved, selected or re-exported can have their record headers renumbered by the tool that produced them, while the System block keeps the ID the machine originally assigned — the difference between “record 7 of this excerpt” and “EventRecordID 319457858 in the original log” matters the moment someone tries to reproduce your finding. Timestamps deserve the same care: inside the file they are UTC, always. Event Viewer converts them to the local time of whatever machine opens the log, which is why two screenshots of the same record can disagree by hours. Pick UTC for the report and say so.

Four event IDs that earn their keep

1102 — the audit log was cleared. The Security log records its own erasure, as the first event in the new log. Its fields name the user who cleared it. In an incident, an 1102 is both evidence and a boundary: everything before it in that log is gone from the file you have, and the clearing itself is a fact worth a line in the report. If a log’s earliest record is an 1102 with a timestamp inside your window of interest, say so before anyone builds a theory on the absence of earlier events.

4624 and 4625 — logons, successful and failed. These are the workhorses of account investigations. The fields that matter are TargetUserName, IpAddress and above all LogonType: 3 is a network logon, 10 is Remote Desktop, 2 is an interactive console logon, 7 is an unlock. A brute-force pattern reads as a burst of 4625s against one account from one address, followed — the moment that matters — by a 4624. A single 4625 is a typo; the shape of the sequence is the signal, which is why you filter and count rather than scroll.

4688 — a process was created. When audit policy records it, each 4688 names the new process (NewProcessName), the account that launched it and often the parent process — the raw material of “what ran on this machine, and when”. Two caveats keep you honest: 4688 only exists if “Audit Process Creation” was enabled on the source machine (its absence proves nothing about what ran), and command-line capture is a separate setting again. Treat a rich 4688 trail as a gift, not an entitlement.

These four are a starting set, not a syllabus — 4624’s special-logon sibling 4672, the explicit-credential logon 4648, and service installation 7045 in the System log are the usual next stops. But a remarkable share of first-day questions — was the log wiped, who got in, from where, and what did they run — are answered by 1102, 4624, 4625 and 4688 alone.

What the fields cannot tell you

Discipline about absence is most of log work. The file cannot show you events the source machine never recorded: audit policy decides what exists, and a default-configured machine logs far less than an investigator hopes. It cannot show you message text, as covered above — a %% reference is a pointer to a string on a machine you do not have. It cannot, by itself, prove tampering or its absence: record ID gaps appear in honest carved files as well as cleared ones, which is why the explicit 1102 record, and not a gap, is the signal to lean on.

And a log is one witness. Timestamps come from the source machine’s clock, which may have been wrong; accounts appear under the names the machine knew; a network logon’s IP is the address the machine saw, NAT and VPNs included. The fields are exactly what the machine recorded — no less, and the discipline is remembering, no more.

A five-minute triage routine

First minute: open the file in the EVTX viewer and read the summary before any record — total count, time range, channels, and the top Event IDs. Note any chunks the viewer reports as unreadable, with their offsets; that caveat belongs in your notes from the start, not as a footnote later.

Second minute: check for 1102. If the log was cleared, everything about your approach changes, and the clearing time and account are your first hard facts. Third minute: filter 4625 and look at the shape — count per account, per source address. A burst followed by a 4624 for the same account from the same address is the finding; note the exact timestamps. Fourth minute: with the suspicious window fixed, filter 4688 (and 4624 type 10, if remote access is in question) inside that window and list what ran and who logged on. Fifth minute: export the filtered records as JSON or CSV and write the paragraph while the numbers are in front of you — record IDs, UTC times, account, addresses. The export is your working paper; the paragraph, with the caveat about unreadable chunks and the message-text limit, is the deliverable.

That routine does not close an investigation. It turns a foreign binary file into five cited facts and a defensible next question, on whatever machine happens to be in front of you — which is most of what triage ever is.

Frequently asked questions