NWinfo reads Windows hardware directly instead of asking WMI

The design decision is to bypass WMI

NWinfo is a Win32 program that lets you obtain system and hardware information, and the feature list names the reason it is not just another wrapper. It gathers information directly without relying on WMI. That single decision shapes everything else about the project. WMI is the standard way Windows applications ask the operating system about hardware, and it is convenient, but it is a layer: a query goes out, a service processes it, providers talk to the kernel, and the answers come back through a stack that can be slow, blocked by policy, or simply unavailable on a stripped down or heavily locked down machine. Reading the same data directly means talking to the firmware tables, to the CPU, to the disks and to the graphics connector yourself. The cost of that choice is that the program now owns all of that low level work, which is exactly why the repository is as large as it is.

The device surface is wide and specific

The listed sources are precise, and they tell you what the utility is actually good for. It retrieves detailed information about SMBIOS, which is the firmware table that describes the motherboard, the chassis, the memory modules and the system as a whole. It reads CPUID, which is how you get the processor identity, the feature flags and the cache topology without asking the operating system. It pulls S.M.A.R.T. data, which is the drive health information you would otherwise need a vendor tool for, and the credits list names CrystalDiskInfo as the reference for that part of the work. It covers PCI, the bus inventory that tells you what expansion and graphics hardware is installed, and SPD, the serial presence data on memory modules. It reads EDID, the display identification data that describes the connected monitor. The topics on the repository match that list, with cpu, gpu, hardware, pci, smbios and usb. The GPU entry is notable: a card is only as well described as the EDID it exposes and the PCI information behind it, so for graphics hardware this program is reading the monitor as much as the board.

Output as JSON, YAML or HTML

The export formats are the second headline feature, and they are the reason to care about this utility if you are doing inventory work. NWinfo supports exporting in JSON, YAML and HTML. That matters because the same information a human reads on screen can be handed to a script, fed into a configuration management database, or dropped into a report. A GUI that can only display hardware is a diagnostic convenience. A program that can also emit JSON is a data source. The HTML export is the third option and it is aimed at sharing, which suggests the tool is expected to be used on machines you are documenting rather than only on your own bench. The repository also has a docs/ directory with its own README, and the project links a separate CLI page for nwinfo inside it, which tells you the command line interface is documented separately from the GUI and is a first-class part of the tool rather than an afterthought.

A C codebase that vendors its dependencies

The repository layout shows how much of this is hand written low level code. The top level contains nwinfo.c as the program entry, a Visual Studio solution nwinfo.sln with the nwinfo.vcxproj project and its filters file, a Resource.rc and resource.h for the Windows resources, and optparse.h. The dependencies are vendored as directories rather than pulled at build time, which is visible in the.gitmodules file and in the directory list: libcpuid/ for the processor identification work, libcdi/ and cditest/ for the disk health work, liblhm/ and lhmtest/ for the hardware monitoring side, libnw/ for the network related pieces, nuklear/ for the immediate mode GUI toolkit, and stb/ for the single header utility libraries. There is also a gnwinfo/ directory, which reads as the GNU/Linux counterpart, plus ioctl/ for the low level device calls, ids/ for identifier tables, and a Python helper, parse_jep106.py, which suggests the JEP106 standard used to name PCI devices is parsed from a data file rather than hard coded. The package is a Windows SDK style project with packages.config, so it expects a Visual Studio or MSBuild environment rather than a makefile.

PawnIO is how it reaches the hardware

The credits include PawnIO, and that entry explains the difficult part of the design. Reading S.M.A.R.T. data from a disk, or pulling SPD data from a memory module, means talking to a device that the operating system normally keeps to itself. On Windows that requires a kernel mode component, and PawnIO is a signed driver framework for exactly this kind of low level access. It is a dependency rather than a vendored directory, which is different from the other libraries in the tree, and it is the reason the tool can produce drive health and memory module detail at all. The contrast with WMI is clearest here. WMI would give you the same values through a provider that is already installed, already signed and already running as a service, with none of the driver installation. NWinfo trades that convenience for directness. The trade is worth making on a machine you own or manage, and is worth checking carefully on a machine where installing a kernel driver is not permitted, because the hardware queries that need it will simply not return data.

Nightly builds, a permissive licence and a single author

Two operational details are worth noting before you depend on this. First, distribution is not limited to tagged releases. Alongside the latest release link, the project publishes a nightly build, assembled from the msbuild workflow on the master branch, so you can run a build made from the current tip of the branch rather than waiting for a tag. The release names carry their own build identifiers, such as the build number appended to each version, which is how you tell two binaries apart when a nightly has replaced a release. Second, the licence is the Unlicense, which is a public domain dedication rather than a permissive software licence with attribution requirements. That is one of the least restrictive licences in use, and it removes the question of attribution entirely, which matters for a project that vendors other people's code and reads data that may include identifiers. The other credits are the usual set for a Windows utility of this kind, with hwdata for the hardware identifier tables, Nuklear for the GUI, stb for the header only utilities and the Paper Icon Theme for the icons. The repository also carries an AGENTS.md file, which is a convention for describing the codebase to automated tooling.

Where NWinfo is the wrong tool

The honest limit is that NWinfo is a single developer project, not a managed product. There is no support commitment, no compatibility matrix and no statement about which Windows versions are tested, and the repository shows a pattern of steady releases, v1.6.6 built in August 2026, v1.6.5 in July and v1.6.4 in June, with the last push on 2026-10-16, but the version line is still in the 1.x range and the changes between builds are not described as features. It is also Windows only in practice, even with a gnwinfo/ directory in the tree, since the program is described as a Win32 program and the build is a Visual Studio project. A second limitation is scope rather than quality. NWinfo reports what the machine exposes. It will not tell you which driver is out of date, whether the memory is running at its rated speed, or whether a disk is failing, because those are different questions with different tools. And there is one comparison worth making explicitly. A WMI query is one line of PowerShell that anyone on the machine can run without installing anything, and for routine inventory in a managed environment that remains the cheaper answer. NWinfo earns its place when WMI is unavailable, unreliable, or when you need the fields a provider does not surface.

Editorial conclusion

Adopt NWinfo when you need a hardware inventory on Windows without WMI in the loop, for example on a machine where the WMI service is disabled, restricted or unreliable, and when you want the output in JSON or YAML for a script. Skip it if you need a supported, signed product with a vendor behind it, because the project is a single developer effort released under the Unlicense with no support commitment. Before you rely on it, compare its output against WMI on one machine, since the two paths read the same devices through different code and will not agree on every field, and read the CLI section of the documentation before scripting the flags.

Frequently asked questions

Official sources

1. a1ive/nwinfo on GitHub
2. License: Unlicense
3. Project website
4. README
5. Releases