zodiacon/AllTools: Windows Diagnostics Bundle and Tool Index

What zodiacon/AllTools Packages for Windows Diagnostics

AllTools solves a distribution problem rather than defining a new diagnostic workflow. Its repository contains many separate Windows executables and ZIP archives for inspecting operating-system behavior, application artifacts, and native file formats. The README describes AccessMask for decoding access masks, DriverMon for driver activity, KernelObjectView for kernel objects and handles, MemMapView for process memory, and NtfsStreams for NTFS alternate data streams. Other entries cover processes, scheduled work, Windows Runtime components, and system-wide objects.

This collection is aimed at people who already know which internal surface they need to examine. A Windows application developer may look at PEExplorer or PdbView, while a support engineer may need ErrorLookup, PerfMonX, or TaskSched. That specificity matters. The collection does not present one guided console or a common plugin architecture, so it offers choices rather than a prescribed sequence for diagnosing a machine.

The repository also contains Sysrun, described as running an executable with the SYSTEM account without a service, and DebugPrint, described as monitoring OutputDebugString and DbgPrint calls without a driver. Those capabilities are sensitive administrative functions. The README gives no access-control model or deployment guidance for them, so their presence is not evidence that ordinary users should run them.

The Executable and Archive Structure of AllTools

Based on the repository layout, AllTools is primarily a binary distribution. Top-level files include standalone programs such as AccessMask.exe, CPUStress.exe, FSClass.exe, KDump64.exe, ObjDir.exe, TotalPE.exe, and sysrun.exe. Other tools are packaged as archives, including BgInfo.zip, DriverMon.zip, ErrorLookup.zip, and MemMapView.zip. Both loose executables and archives are present, so the exact delivery mechanism differs by tool.

The utilities operate through several distinct Windows mechanisms. DebugPrint targets debug output calls. DriverMon targets driver activity. ProcMonX and its second version are described as ProcMon-like tools based on Event Tracing for Windows. ETWExplorer reads ETW XML manifests for registered providers. System Explorer combines information about the system, processes, threads, objects, and handles. These descriptions indicate separate execution paths and data sources rather than a shared AllTools backend.

Several projects also link to dedicated repositories, including AccessMask, CLRExplorer, InfStudio, PoolMonXv2, and WFP Explorer. Based on that layout, AllTools is best understood as an index and binary collection point. It may serve as a convenient place to find the utilities, but the README does not establish a common release pipeline, configuration format, logging system, or shared command-line convention across them.

Downloading and First Use Without a Documented Installer

The README does not document package installation, supported Windows versions, prerequisites, or a build process. It also does not provide installation commands. According to the repository contents, a user would need to obtain the relevant executable or archive from the repository and then determine its dependencies and execution requirements separately. The absence of a documented setup path is a real limitation for an organization that needs repeatable provisioning.

There is no safely documented first-launch configuration to reproduce. The most specific first-use guidance supported by the README is to choose a utility according to the information sought, then consult its linked repository when one is provided. For example, AccessMask is described as decoding an access mask, while ErrorLookup returns descriptions for Win32 GetLastError and NTSTATUS codes. Both are standalone utilities rather than steps within an AllTools application.

The repository includes a file called PavelTools-May22.zip, but the README does not identify its contents. Recent release records also mention v2.2 as Pavel Tools 2.2.0 and v1.7 as MSI. Those names do not establish a complete version matrix for every executable. A first user should therefore verify the selected binary and its matching release rather than assume that every file was rebuilt or tested under the same release name.

Process, Kernel, and File Inspection Choices

AllTools offers several overlapping inspection categories, but they are not interchangeable. CLR Explorer is described as viewing .NET process information and dumping a file. CLRExplorer.exe and CLRExplorer64.exe are both present, making architecture selection an explicit part of locating the right binary. System Explorer takes a broader view of system, process, thread, object, and handle information. ProcExpX.exe provides another process-focused entry, although the README does not explain its exact feature set.

For native and kernel inspection, ObjDir exposes the object manager namespace from the command line, ObjExp is an object and handle explorer, and KernelObjectView reports kernel object and handle statistics. MemMapView is described as viewing process memory, including protected and minimal processes. Access rights and visibility can therefore depend on the Windows object involved and the privileges available to the launching process. The README does not document how AllTools handles access-denied conditions.

The file-oriented tools follow the same pattern. PEExplorer and PEExplorerV2 inspect PE files, PdbView reads PDB files, and NtfsStreams lists alternate streams. INF Studio views and edits INF files, while TotalReg views and edits the Windows Registry and includes undo and redo according to its README entry. Editors introduce a different operational risk from read-only inspectors, but AllTools supplies no shared confirmation, backup, or recovery policy.

ETW, Debug Output, and Process Monitoring Boundaries

ProcMonX and ProcMonX v2 are described as enhanced ProcMon-like applications based on Event Tracing for Windows. ETWStudio.exe is also present, although the README does not list it as a separate project entry. ETWExplorer is assigned a narrower role: viewing ETW XML manifests for registered providers. Together, these files indicate an ETW theme, but the README does not document whether they share event sessions, trace formats, filtering controls, or export behavior.

DebugPrint takes a different route. The README states that it monitors OutputDebugString, DbgPrint, and DbgPrintEx calls without needing a driver. That is useful for tracing debug output from components that use those APIs, but it does not establish equivalence to full process, file, registry, or network activity monitoring. A troubleshooting workflow that assumes ProcMonX captures the same evidence as DebugPrint would be wrong.

The collection also includes a WIP status for WinSpy and labels it a WIP alternative to Spy++. That wording is an explicit maturity warning. Its listed functions are showing windows and monitoring messages, but the README gives no stability statement beyond calling it work in progress. Production support processes should not depend on undocumented behavior from an entry marked WIP without first validating the executable in its intended environment.

AllTools Compared with Individual Upstream Utilities

The clearest comparison appears in the README's description of BgInfo as a WPF version of the Sysinternals BgInfo tool. That indicates a direct functional overlap rather than a claim that AllTools replaces the Sysinternals distribution model. Sysinternals tools are individually named products with their own documentation and release identity. AllTools presents BgInfo.zip alongside unrelated utilities, which can reduce the number of repositories a user checks but does not merge their operating manuals.

WinSpy provides a second example. The README calls it a WIP alternative to Spy++, with window display and message monitoring as its stated functions. This comparison identifies a different interface choice and a WIP status, but the repository does not document message coverage, UI behavior, architecture support, or compatibility. It would be unsafe to infer parity with Spy++ from the alternative label alone.

AllTools is therefore best compared with visiting each upstream repository separately. The bundle centralizes discovery and binary files, while an individual repository may provide a narrower scope and more specific documentation. The trade-off is clear: fewer places to find tools, but no evidence of a unified support contract across every included program.

MIT Licensing, Releases, and Upgrade Review

The repository identifies the MIT license, so the included project material is published under permissive terms that include copyright and license notices. That does not by itself answer operational questions about Windows dependencies, redistributable third-party components, signing, or whether each linked utility uses the same license. The README does not document those details, and license conclusions for individual binaries would require their corresponding repositories or license files.

The recorded release history includes Pavel Tools 2.2.0 on 2026-10-08 and MSI v1.7 on 2026-09-05. The repository's last push was also on 2026-10-08, and it is not archived. These dates show recent repository activity, but the README does not provide a release manifest mapping every archive to a version or documenting upgrade procedures.

An upgrade therefore requires file-level review. The repository contains both fixed executables and ZIP archives, some with versions embedded in their filenames. It also contains archives with labels such as beta or WIP-related README status. Users cannot infer that a new repository push upgraded every tool. The concrete first check should be the archive name and corresponding release entry for the specific diagnostic being deployed.

Editorial conclusion

Adopt AllTools when you need a focused Windows diagnostic executable and are comfortable evaluating the individual utility before use. Do not treat it as a unified, documented platform or as a source build. Verify first that the required tool is present in the selected release, matches your Windows environment, and has adequate privilege for the object you need to inspect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zodiacon/AllTools on GitHub