Snoop WPF: How to Install and Use the WPF Spy Utility

What Snoop WPF solves, and for whom

WPF renders a tree of objects, and most defects in a WPF screen are really defects in that tree: a binding that resolved to nothing, a trigger that never fired, a template part that got replaced, a property that a style setter overwrote. Visual Studio can show you some of this, but only while the debugger is attached and usually only while execution is paused. Snoop takes a different route. The README describes it as an open source WPF spying utility that lets you "spy/browse the visual, logical and automation tree of any running WPF application (without the need for a debugger)". That phrase is the whole pitch. You point it at a process that is already running, and you inspect live objects while the application keeps responding to input.

The intended user is a developer or a QA engineer on a Windows desktop team who has the application installed and can run it. It is not a library you add to a project, and it is not a profiler. Nothing in the README suggests memory analysis, allocation tracking or timeline recording. If you want to know why a panel is 3 pixels too tall, Snoop is the right instrument. If you want to know why the application allocates 400 MB per minute, it is the wrong one.

Snoop was originally created by Pete Blois and is currently maintained by Bastian Schmidt, according to the README. The repository is not archived, and the last push was on 2026-08-23, so the project is still receiving changes. The README is also blunt about its own gap: "Unfortunately there isn't any exhaustive documentation on how to use Snoop and there are plenty of hidden features." Three linked YouTube videos are offered as the getting-started path. Budget for exploratory learning rather than reading a manual.

How the injector reaches a running process

The mechanism is injection, not remote debugging. The repository layout makes this visible: there is a Snoop.InjectorLauncher project, a Snoop.GenericInjector project, and native C++ payloads, which is why the build requirements in the README ask for the C++ workload in Visual Studio for x86, x64 and optionally ARM/ARM64. Snoop does not require the target application to be built with any special flag, and it does not require a Microsoft Visual C++ Redistributable to be installed, a constraint the 3.0.0 changelog explicitly removed when the injector code was rewritten.

Once injected, Snoop walks the WPF object graph from the target application's UI thread and presents three views of it: the visual tree, the logical tree, and the tree of WPF automation peers. Those are different structures and they disagree in useful ways. A control that exists in the logical tree may have no visual representation yet, and an automation peer may expose something a screen reader sees but the visual tree does not. The README lists the operations available on what you find: change property values, view triggers, set breakpoints on property changes. The triggers tab is worth noting historically, because the 2.9.0 changelog says it was ported from another utility called WPF Inspector, written by Christian Moser.

Two details shape day-to-day use. First, tracking modes: holding CTRL tries to skip template parts, and holding CTRL + SHIFT does not skip them. The 3.0.0 notes record that the skip behaviour moved to CTRL + ALT in newer versions, so the modifier you read about in an old blog post may be stale. Second, a global hotkey exists: start Snoop, focus a WPF application, and press CTRL + WIN + ALT + F12. That matters when the window you want to inspect is a popup or a context menu that closes the moment it loses focus.

Installing Snoop WPF and spying on your first process

The README lists three distribution channels: Chocolatey for stable and some preview versions, GitHub releases for stable versions, and AppVeyor for the latest preview builds produced on every code change. Chocolatey is the shortest path on a machine that already has it.

choco install snoop

The package name is snoop. After installation you get the Snoop executable and the injector launcher, and the README states you need at least .NET Framework 4.6.2 to run Snoop itself. That is a requirement of the tool, not of the application you intend to inspect.

If you prefer not to install a package manager, download the stable artifacts from the GitHub releases page. From 4.0.0 onward the changelog says the MSI, the Chocolatey NUPKG and the zip artifacts are digitally signed via SignPath.io, so you can check the signature before running the binary.

To inspect an application, start that application normally, then start Snoop. It presents a process chooser; the 3.0.0 changelog mentions usability improvements to the process dropdown and a much faster AppChooser.Refresh(). Select your process and Snoop injects into it. You should then see the tree of that application's windows. From there, the practical first exercise is to find a control whose appearance is wrong, open its property list, and read the effective value of the property you care about. The 5.0.0 release notes say Snoop filters uncommon properties by default, so if a property is missing from the list, that filter is the first thing to check rather than assuming the property does not exist.

Both Snoop.exe and the injector launcher accept command line arguments, per the 3.0.0 notes, which is how you script an attach against a known process instead of clicking through the chooser.

Where Snoop WPF stops working

The clearest boundary is stated in the README's supported .NET versions section: "Self-Contained single file applications are not supported as there is no reliable way to get a handle to the .NET runtime." If your shipping configuration is a single-file self-contained publish, Snoop will not attach to it. The 3.0.0 notes add a related caveat about trimmed single file applications, warning that trimming may have removed things Snoop relies on. Neither restriction is a bug you can work around with a flag; both follow from how the tool finds the runtime inside the target process.

Version skew is the second trap. Snoop 6.0 dropped support for all .NET Framework versions prior to 4.6.2 and for .NET 3.1 and .NET 5. If you are maintaining an application on an older runtime, the README answers the obvious question directly under "Why can't I snoop my application?" with a table mapping Snoop versions to the minimum runtimes they support: Snoop 3.0 covers .NET Framework 4.0 and .NET 3.0; 4.0 covers 4.5.1 and 3.0; 5.0 covers 4.5.2 and 3.1; 6.0 covers 4.6.2 and 6.0. The answer is to install an older Snoop, which means running two tools on two machines if your team supports both an old line and a new one.

The third limitation is platform. Snoop is a WPF spy utility. Nothing in the README claims support for WinUI, UWP, MAUI, Avalonia or any other XAML dialect, and the automation tree support it does have is described as WPF automation peers. Do not buy into it as a general XAML inspector. Finally, the documentation gap is real: the README says there is no exhaustive documentation and asks anyone willing to write it to get in touch. Expect to learn by poking at the tree.

Snoop against the debugger and against WPF Inspector

The honest alternative for many of these tasks is the Visual Studio debugger itself. Its live visual tree and live property explorer overlap heavily with Snoop's core views, and if you are already stopped at a breakpoint, there is no reason to launch a second tool. The difference is in the constraints. The debugger requires the source, the symbols and a debug build or a matching release build, and inspection is most comfortable while execution is paused. Snoop attaches to a process that is already running, including one you did not build on that machine, and lets the application keep running while you edit a property value or set a breakpoint on a property change. That is why it is useful for reproducing a defect on a tester's machine or on a release build where the debugger is awkward.

Within the WPF spying category, the README names one predecessor directly: WPF Inspector, written by Christian Moser. The 2.9.0 changelog says Snoop's triggers tab was ported from that tool. The practical difference today is maintenance and reach. Snoop has a release history through v6.1.1 in 2026 and a changelog that records ongoing work on runtime support, settings, themes and browser control inspection. WPF Inspector is referenced only as the origin of one feature. If you need the triggers view specifically, Snoop has it; if you need something WPF Inspector did that Snoop never ported, the README does not enumerate it.

One capability worth weighing separately: the 5.0.0 notes say Snoop can show browser dev tools on browser controls, with WebView2 and CefSharp currently supported. If your WPF shell hosts web content, that closes a gap where you would otherwise switch between two inspectors.

Licence terms and the cost of staying current

Snoop is distributed under the MS-PL, the Microsoft Public License. It is a permissive licence, and the repository carries both License.txt and License.rtf at the top level. This is not legal advice, and the terms that matter to you depend on whether you redistribute Snoop, embed its assemblies, or merely run the tool internally. Read License.txt rather than a summary of it, and route the question to whoever handles licensing at your organisation if you plan to ship anything derived from it.

Upgrade cost is mostly a function of your target runtimes, not of Snoop's internal churn. The project has made breaking changes on major versions: 3.0.0 dropped support for older .NET versions and rewrote the injector; 4.0.0 dropped everything before .NET Framework 4.5.1; 5.0.0 dropped everything before 4.5.2 and .NET 3.0, and replaced the settings system so that it no longer relies on System.Configuration; 6.0.0 dropped everything before .NET Framework 4.6.2 and .NET 6.0. If you keep Snoop installed as a developer tool rather than as a dependency, an upgrade is a download. If you have automated an attach step in a script, check the command line arguments after a major version, because the injector launcher is one of the pieces that has been rewritten.

There is one configuration detail that can save you effort. The 5.0.0 notes say the new settings system allows sharing settings between different snooped applications and lets you define settings for whole directory trees. Teams that inspect several applications from the same solution can set that up once. The same release added the ability to hide properties from Snoop's default view by annotating them with [System.ComponentModel.BrowsableAttribute(false)], which is a code change in the application under inspection, not in Snoop.

Editorial conclusion

Use Snoop if you maintain a WPF desktop application and need to see why a binding, a trigger or a template is not behaving, without attaching Visual Studio and stopping the process. Skip it if your UI is WinUI, MAUI, Avalonia or a self-contained single-file .NET app, because the README states there is no reliable way to get a handle to the runtime in that last case. Before adopting it, check the version table in the README against your target framework, since Snoop 6.0 dropped everything below .NET Framework 4.6.2 and .NET 6.0, and confirm that your organisation is comfortable with the MS-PL terms under which the source is distributed.

Frequently asked questions

Official sources

1. Issues
2. License: MS-PL
3. README
4. Releases
5. snoopwpf/snoopwpf on GitHub