System Informer: a portable Windows system inspector and process tool

Process Hacker, renamed and rebranded

This repository is a mirror. The repository description says it is a mirror of the processhacker2/processhacker project, and the README that comes with it is not Process Hacker's README at all. It is the README for System Informer, the tool that grew out of Process Hacker, brought to you by Winsider Seminars and Solutions, Inc.

That naming history matters more than it might sound, because a reader arriving from a Process Hacker reference will find a different set of URLs. The download links point at systeminformer.com, the GitHub issue tracker link points at the winsiderss/systeminformer repository rather than the mirror's own tracker, and the CI badge is for the winsiderss/msbuild workflow. The project homepage is processhacker.sourceforge.net, which is the historical address.

So the mirror is a copy of the source, not the place the work happens. Reporting a bug through the mirror's issue tracker would put it in the wrong place, and the README's guidance is to use the GitHub issue tracker at github.com/winsiderss/systeminformer for problems and feature requests.

The tool itself is written in C, licensed MIT, and the licence is described as 100% Free Software. The system requirement is Windows 10 or higher, 32-bit or 64-bit, which is a tight constraint and the first thing to check for anyone coming from a Unix-side habit.

What the single window is for

The feature list describes one interface that answers several separate operational questions, and the interesting thing is that most of them are the kind of question the standard Windows tools answer badly.

There is a detailed overview of system activity with highlighting, and graphs and statistics to track down resource hogs and runaway processes.

Then come the questions that usually need a second tool. Can't edit or delete a file? Discover which processes are using that file. See what programs have active network connections, and close them if necessary. Get real-time information on disk access.

The file lock and network connection views are the ones that make this more than a task manager, and both have a diagnostic shape rather than a monitoring shape. Finding the process holding a file open is a question you ask when an install or an update fails, and the answer requires correlating a handle with a process, which the standard tools make awkward.

There is more under the hood than the interface suggests. Stack traces come with kernel-mode, WOW64 and .NET support, which means the tool can show you what a managed process is doing rather than just its thread list. And the service management goes beyond services.msc, allowing you to create, edit and control services.

The last line of the list is the deployment model: small, portable and no installation required. A single executable you copy onto a machine and run is how you would use this on a colleague's desktop during an incident, and it is also why the settings file can live on a USB drive.

The portable trick and the settings file

Because the tool has no installation step, it needs somewhere to put its settings, and the default is wherever the executable happens to live. The README documents the case where you run it from a USB drive and want the settings to travel with it.

The mechanism is a blank file named SystemInformer.exe.settings.xml placed in the same directory as SystemInformer.exe. The steps given are deliberately manual, and they are written for someone who does not have file extensions shown in Explorer. Untick Hide extensions for known file types in Tools, Folder options, View. Right-click in the folder and choose New, Text Document. Then rename the file to SystemInformer.exe.settings.xml, deleting the .txt extension.

That is a slightly awkward procedure, and it is the kind of detail that tells you the tool grew up as a portable utility rather than as an installed product. The alternative is to accept that the settings live wherever Windows puts them and accept that a USB copy starts from defaults.

The `SystemInformer.natvis` file in the repository root is related in spirit. It is a Visual Studio debugger visualizer, so a developer working on the codebase can inspect the internal structures in the debugger in a readable form rather than as raw struct dumps.

Building the C codebase on Windows

Building requires Visual Studio 2022 or later, and the free Visual Studio Community Edition is enough.

There are two batch scripts, both in the `build` directory, and the order matters:

build_init.cmd
build_release.cmd

`build_init.cmd` is the one-time setup, and the README notes it does not need to run again unless there are updates to the tools or third party libraries. `build_release.cmd` is the actual compile. If you prefer, you can load the `SystemInformer.sln` and `Plugins.sln` solutions in Visual Studio and build from there instead, which is the more familiar route if you want to step through the code. The build readme in `./build/README.md` has more detail.

The repository is a large C project with a specific structure. `SystemInformer/` is the main application, `KSystemInformer/` holds the kernel-mode components, `phlib/` and `kphlib/` are the user-mode and kernel-mode support libraries, and `phnt/` is the Windows NT header definitions the project needs. `plugins/` is a separate solution, which is how the tool's extension points are organised. There is a `tools/` directory, a `cmake/` directory and a `CMakeLists.txt` at the root alongside the Visual Studio solutions, so the build is not Visual Studio only.

Two solution files exist for the main project, `SystemInformer.sln` and `SystemInformer.slnx`, and the newer one is the slnx format. The shared MSBuild configuration lives in `Directory.Build.props`, `Directory.Build.targets`, `Common.Kernel.props`, `Common.Kernel.ruleset` and `Common.User.props`, which is the standard way to keep the kernel and user-mode halves building with the same settings.

The repository also carries `HACKING.md`, a `CLA.md`, a `SECURITY.md`, a `CHANGELOG.txt` and a `COPYRIGHT.txt`, so there is a written record of how changes are expected to be made and how security issues are handled.

Where the mirror and the upstream project differ

The mirror arrangement has a practical consequence for anyone planning to work on this code.

The commits in this repository are copies of upstream commits, and the last push was on 2026-09-10, so the mirror is being kept reasonably current. But the pull request flow, the issue tracker and the release artefacts all live upstream. The README's own links point there, and the build CI badge points at the winsiderss workflow, so the mirror is not where a change would be tested or merged.

The releases are the other half of this. There are no GitHub releases on the mirror, and the README's download badges point at systeminformer.com/downloads, at a release-stats page for the winsiderss/systeminformer repository, and at SourceForge for the historical processhacker project. So the binaries come from the upstream project site, and the SourceForge project is a legacy distribution channel for the older name.

None of this makes the mirror a bad thing to clone, and for reading the source it is entirely fine. It does mean that a patch should go upstream, and that the version you run should be matched to a release from the upstream site rather than to a commit in this tree.

The broader point about the tool itself is worth making once. It is a diagnostic instrument. The description says it helps you monitor system resources, debug software and detect malware, and the malware part is the one to read carefully, because it means the tool surfaces indicators you then investigate, not that it is an antivirus. Used as a first look at a suspicious machine, the network connection view and the per-process stack traces are genuinely useful, and it remains a debugging and monitoring tool rather than a security product.

Editorial conclusion

System Informer fits a Windows user who needs to answer what is holding a file, which process owns a network connection, or what is consuming CPU, and who wants a single portable executable rather than an installed agent. It does not fit a Linux or macOS user, and it is not a security product, since its malware detection is a diagnostic aid rather than a scanner. Before building it, install Visual Studio 2022 or later, run `build_init.cmd` once in the `build` directory to prepare the tools, then `build_release.cmd`, and note that the repository is a mirror of the upstream project rather than its canonical home.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. PKRoma/ProcessHacker on GitHub
4. Project website
5. README