A standalone Windows tool for end-to-end network diagnosis. Capture every DNS, TCP, TLS, HTTP, and auth event your tracked processes generate during a workload window, group them into per- destination "stories," and get a deterministic per-connection diagnosis with pattern-matched verdicts.
Open-source under the Apache License 2.0. No telemetry, no cloud. This is a self-contained app that runs on its own without installing anything locally.
Built on Microsoft.Diagnostics.Tracing.TraceEvent, the same library
that backs PerfView and several Microsoft diagnostic tools.
Six tabs:
- Record — type an optional process regex (e.g.
outlook|teams|chrome) or leave blank for system-wide. Click Start, reproduce the failure, click Stop. The tool spins up a kernel ETW session and a user-mode ETW session and captures every network-related event your tracked processes generate. - Stories — per-destination grid. One row per (process, host) pair with outcome, step count, and the top diagnosis verdict. Double-click to see the full chronological step list (DNS → TCP → TLS → HTTP → auth) plus any verdicts the diagnosis engine attached.
- Auth failures — every Kerberos, NTLM, LDAP, and AAD failure captured during the window, with the protocol-specific result code.
- Firewall drops — every WFP-observed dropped packet with the Windows firewall rule that fired and the layer it fired in.
- Recommend — when the failing process is Chromium, Firefox, Java, Python, Node, etc. (anything whose HTTP stack is outside Windows), the tab shows copy-pasteable instructions for the right next-cheapest tool to continue the investigation (chrome://net-export, browser DevTools HAR, JVM debug flags, etc.).
- Help — primer on what each ETW provider sees and where the visibility gaps are.
The diagnosis is deterministic. The DiagnosisEngine is a small set of pattern-match rules over event payloads (TLS alert names, AADSTS codes, Kerberos KDC errors, etc.). There is no AI inference or heuristics that change between runs.
Network failures are notoriously hard to diagnose because the symptom is usually at the application layer ("white screen," "loading forever," "can't connect") and the cause is somewhere down the stack in DNS, TCP, TLS, firewall, proxy, or auth. NetPath captures every event from every relevant layer in one workload window and stitches them into per-connection chronological stories, so the cause is visible in the same view as the symptom.
Typical findings:
- A name resolves via the wrong DNS server (corporate vs. public), pointing at NRPT misconfiguration on a VPN profile.
- TCP connects fail to a specific IP because a Windows Firewall rule is dropping outbound to that subnet (Firewall tab names the rule).
- TLS chain validation fails with UntrustedRoot, surfaced as "your corporate TLS-inspection proxy is presenting a cert chain your machine doesn't trust."
- Azure AD Conditional Access denies a sign-in with AADSTS53003; the diagnosis engine recognises the code and explains the policy category and which Azure portal blade to check.
- Kerberos returns KDC_ERR_S_PRINCIPAL_UNKNOWN for a SQL Server SPN —
diagnosed as "missing SPN on the AD service account" with the
exact
setspncommand to verify.
Pre-built signed Windows executables are published on the
Releases page. Download ETDucky.NetPath.exe,
right-click → Properties → Unblock (mark-of-the-web), then run.
The app requires Administrator. The manifest requests elevation; you'll see one UAC prompt at launch.
Requirements: Windows 10+, .NET 10 SDK.
git clone https://github.com/trucule/ETDucky.NetPath.git
cd ETDucky.NetPath
dotnet build -c ReleaseSingle-file self-contained publish:
dotnet publish -c Release -r win-x64 `
-p:SelfContained=true `
-p:PublishSingleFile=true `
-p:IncludeNativeLibrariesForSelfExtract=trueTwo ETW sessions, one per session class:
| Session | Providers | Why |
|---|---|---|
| Private kernel | Kernel-Network, Process | TCP connect timing + process tracking |
| User-mode | DNS-Client, Schannel, CAPI2, WinHTTP, WinINet, AAD, WebAuthN, Kerberos, NTLM, LDAP-Client, WFP | Every other layer of the stack |
Per-process filter: a regex on image basename. PIDs whose image matches
are tracked, and so are children of tracked PIDs (so Outlook → embedded
WebView2 → its renderer child are all captured together). Blank or *
captures system-wide.
User-mode provider events come through TraceEvent's Dynamic parser,
which decodes any provider with a published manifest. We extract the
commonly-useful fields by name (QueryName, TargetName, ErrorCode,
etc.) into typed event records — best-effort, so an unexpected payload
shape doesn't kill the capture.
After Stop, the raw event queues drain into a snapshot. Events are bucketed by (PID, destination hostname). The destination key for each event type:
- DNS → query name
- TCP → resolved-back hostname from the DNS map, or the bare IP
- TLS → SNI server name
- HTTP → URL host
- AAD → resource / scope
- Auth → SPN / target
Within each bucket events sort chronologically and become the story's Steps list. Each step is rendered with source, kind, detail, outcome, and timing.
A small set of pattern-match rules runs over each story's Steps. Rules fire conservatively — only when the pattern is unambiguous (a specific Schannel alert name, a recognised AADSTS code, a Kerberos KDC_ERR_* identifier). When a rule matches, it produces a DiagnosisVerdict with severity, explanation, and a suggested next step.
Current rules: DNS NXDOMAIN / SERVFAIL, TCP connect failure (with DNS success), TLS untrusted-root / unknown_ca / protocol-version, Azure AD Conditional Access (AADSTS53003 / 50158 / 53000), Azure AD invalid grant (AADSTS50053 / 50057 / 50034 / 70008), Kerberos KDC_ERR_S_PRINCIPAL_UNKNOWN, Kerberos KDC_ERR_PREAUTH_REQUIRED (info), HTTP 401, HTTP 403.
When no rule matches, the story renders without verdicts and the user reads the raw step list. The absence of a verdict isn't "no problem" — it's "no rule recognised this pattern."
For each story, HttpStackDetector inspects the process name to
identify its HTTP stack family (Chromium, Firefox, Java, Python,
Node, etc.). When ETW has TLS coverage but no HTTP coverage for that
story, the tool emits an EscalationHint pointing the user at the
right next-cheapest tool — e.g., chrome://net-export/ for Chromium,
JVM -Djavax.net.debug=ssl:handshake for Java, NODE_DEBUG=http
for Node.
The tool admits its limits rather than silently showing an incomplete picture.
ETDucky.NetPath/
├── MainForm.cs Six tabs
├── Program.cs
├── HelpText.cs Help tab content
├── app.manifest requireAdministrator
├── app.ico
├── Models/
│ ├── NetworkEvents.cs Typed event records (DNS, TCP, TLS, ...)
│ ├── ConnectionStory.cs Per-destination story + Steps + Verdicts
│ ├── CaptureSession.cs Per-source lock-free queues
│ └── CaptureSummary.cs Top-level result + EscalationHints
└── Services/
├── ProcessTracker.cs Pattern-matched PID set + child following
├── NetworkCapture.cs Two ETW sessions, dynamic event dispatch
├── ConnectionStoryBuilder.cs Group events into per-destination stories
├── DiagnosisEngine.cs Pattern-match rules → DiagnosisVerdicts
├── HttpStackDetector.cs Visibility-gap detection + escalation hints
└── ResultExporter.cs JSON save/load (versioned envelope)
No external services. No ETDucky.Core reference. Standalone.
- Windows-only. ETW is a Windows subsystem.
- Administrator required. Kernel ETW and most user-mode providers need elevation for cross-process visibility.
- 8 kernel sessions per host. The tool uses a private kernel session, so it coexists with PerfView, xperf, ProcDelta, AvProfiler, the ET Ducky agent, and other ETW capture tools. Only when all 8 slots are full does Start fail.
- Browser HTTP visibility is limited. ETW sees DNS / TCP / TLS for Chromium / Firefox / Electron processes, but not the HTTP request /response details inside the browser's own HTTP stack. The Recommend tab tells you the right tool to fill that gap.
- Provider availability varies by Windows SKU. WebAuthN is Win10 1903+. The AAD provider is most useful on AAD-joined / Microsoft- account-joined hosts. Missing providers are skipped silently.
- DiagnosisEngine is conservative. False negatives (real problems that don't match any rule) are preferred over false positives. When unsure, read the raw step list yourself.
- WFP shows DROPS only. The ALLOW event volume is enormous and isn't what users typically investigate.
ET Ducky (https://etducky.com) is a commercial cross-platform diagnostic agent that uses ETW on Windows and eBPF on Linux for continuous fleet-wide kernel observability with AI-driven root-cause analysis. NetPath is the standalone, workload-driven, single-machine version of one diagnostic pattern the commercial agent runs continuously across endpoints.
The two are independent repositories.
Apache License 2.0. Free for any use — commercial or otherwise — with patent grant and trademark protection. See LICENSE for the full terms.
Contributions submitted as pull requests are accepted under the same license. By submitting a PR you confirm you have the right to license your contribution this way.
PRs welcome. The codebase is small. Useful directions:
- More diagnosis rules — particularly around proxy auth (407 responses with Proxy-Authenticate), QUIC failures, IPv6 fallback patterns, MTU / path-MTU-discovery issues.
- Broader AADSTS coverage in
DiagnosisEngine.cs— Azure AD has hundreds of error codes and only the most common are mapped today. - More HTTP-stack families in
HttpStackDetector.csso escalation hints fire for less-common runtimes (Rust reqwest, .NET Framework HttpClient through SslStream, native curl in WSL, etc.). - A "starter pack" of common diagnostic verdicts for popular SaaS endpoints (Microsoft 365, Salesforce, Slack, GitHub).