python-evtx: reading Windows event logs from any platform in pure Python

The Vista format is binary XML, and that is the whole problem

The Background section explains why this library exists at all. With the release of Windows Vista, Microsoft introduced an updated event log file format, and the format used in Windows XP was a circular buffer of record structures that each contained a list of strings, which a viewer resolved against templates hosted in system library files before inserting the strings into appropriate positions. The newer event log format is proprietary binary XML, so unpacking chunks from an event log file from Windows 7 results in a complete XML document with a variable schema. The changes helped Microsoft tune the file format to real-world uses such as long running logs with hundreds of megabytes of data, and system independent template resolution. A parser for that format is genuinely hard to write, which is why pure Python implementations of it are worth looking at. The structure definitions and parsing strategies here were heavily inspired by the work of Andreas Schuster and his Perl implementation Parse-Evtx.

The module gives you headers, templates and records

The module provides programmatic access to the File and Chunk headers, record templates, and event entries. That is the useful shape for a forensic pipeline, because the three levels answer different questions. The file header tells you the log's own metadata and its declared chunk count, which is the first thing you check when a log looks truncated. The chunk headers carry the per-chunk records and their offsets, and each chunk carries a checksum, which is what the bundled evtx_info.py script verifies. Templates are the part that trips people up: a record in the binary format is a token stream referring to template identifiers, and the template says how the tokens are laid out, so without a resolved template a record is just numbers. The practical consequence is that a log copied without its resource files may parse but produce records you cannot interpret, and the README is honest that the module operates on event log files from Windows operating systems newer than Windows Vista.

Four scripts that mirror the Parse-Evtx tools

Four scripts ship with the parsing module Evtx, and they mimic the tools distributed with Parse-Evtx. evtx_info.py prints metadata about the event log and verifies the checksums of each chunk. evtx_templates.py builds and prints the templates used throughout the event log. evtx_dump.py parses the event log and transforms the binary XML into a human readable ASCII XML format. Finally evtx_dump_json.py parses event logs, similar to evtx_dump.py, and transforms the binary XML into JSON with the added capability to output the JSON array to a file. The pyproject also registers these as console scripts, so evtx_dump, evtx_dump_json, evtx_dump_chunk_slack and evtx_eid_record_numbers are installed as commands, along with others in the same package. The chunk_slack variant name suggests output to a chat destination, and the eid_record_numbers script is the one that extracts event identifier and record number pairs, which is the form you want when you are correlating a specific event across a timeline.

The dump script is twenty lines, and that is the point

The README makes a point about the ergonomics by showing the entire implementation of the dump logic, which it notes is only 20 lines:

print(e_views.XML_HEADER)
print('<Events>')
for record in log.records:
    print(record.xml())
print('</Events>')

The comment on the length is the argument, not the code itself. A record exposes an xml() method, and the surrounding document assembly is your own code rather than something the library does for you. That is a deliberate trade: the library does the hard part, which is the binary format, and leaves the document shape to you. If you want a different output, you write a different loop over log.records, and each record still hands you XML. The same reasoning shows up in the module design, where the README does not describe a high-level event abstraction at all, and in the choice to keep the dependency list down to a single package.

Confirming you have the right file before you parse it

Because the format changed at Vista, it is worth checking what you actually have before parsing. The README notes that version 5.09 of the file utility identifies such a file as MS Vista Windows Event Log, and to confirm the file type manually you look for the ASCII string ElfFile in the first seven bytes:

xxd -l 32 Security.evtx
0000000: 456c 6646 696c 6500 0000 0000 0000 0000  ElfFile.........

The hex dump shows the bytes 45 6c 66 46 69 6c 65, which spell ElfFile, followed by the zeros that pad the first chunk of the header. The point of the check is that a file from Windows XP or earlier is a different format entirely, and a parser built for the Vista format will fail on it in a confusing way rather than saying so. For a forensic workflow, running that one check before the parse is cheap insurance.

Pure Python means the same install on every platform

The dependency story is one line long. python-evtx is a pure Python 3 module, so it works equally well across platforms like Windows, macOS and Linux, and the manifest requires Python 3.9 or later with a single dependency, hexdump at 3.3 or later. That matters more than it sounds. A Windows event log collected from a target machine can be parsed on an analyst's laptop, in a container, or in a CI job, with no compiler and no platform-specific client library, and the same code path produces the same output on each. The packaging is setuptools with the packages found across Evtx* and evtx_scripts*, excluding tests, and the project is classified as Production/Stable with audience of Developers and Information Technology, and topics of System Logging, Python Modules and Security.

Install, then run the linters the way the maintainer does

Updates to python-evtx are pushed to PyPI, so you install the module with pip:

pip install python-evtx

The source is hosted on GitHub and you may download, fork and review it from the repository, with issues and feature requests going through the project's bug tracker. For development the README prescribes a specific toolchain, and it is worth matching it if you plan to contribute. Formatting uses isort with the length-sort, black profile and a line length of 120 over the Evtx, scripts and tests directories, and black with the same line length. Linting uses ruff over the same three directories, and the repository also carries a .justfile so you can run just lint to run the linters. The licence is the Apache License, Version 2.0, which the README spells out as freely available for use and modification in a personal and professional capacity. The release history is steady rather than fast, with v0.8.1 on 2025-05-02 after v0.8.0 in June 2024 and v0.7.4 in March 2021, and the last push was on 2026-10-06, so the file format support is not moving quickly but the project is not abandoned either.

Editorial conclusion

Adopt python-evtx if you need to read .evtx files from a non-Windows machine, or if you want record-level access to event data in a forensic pipeline. Do not adopt it for live Windows event log collection on a running system, because it works on files rather than on a live event channel. Before you commit, check that your logs are from Vista or later, since the format before that was a different circular buffer format, and plan for the fact that template resolution depends on resources that are not always present in a copied log directory.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. williballenthin/python-evtx on GitHub