Troubleshooting (Windows)

Windows-specific failure modes and fixes — registry proxy not applied, certutil failures, Task Scheduler tasks missing, WinHTTP clients bypassing the proxy. Phase-0 public beta.

Most failure modes on Windows are shared with macOS and Linux — see the main Troubleshooting guide for the common items (PAUSED states, loopback bind guard, install-fails-with-TLS-error, “no captures”). This page collects the Windows-specific items.

Run halton-meter doctor first — it walks every Windows-specific signal (HKCU proxy registry, user Root cert store, Task Scheduler tasks) plus the shared items.

WinHTTP clients ignore the proxy (Windows Update, some .NET tools)

Symptom: Most apps capture fine (Cursor, Edge, PowerShell + curl, Python SDKs), but a specific app — typically a .NET tool, a corporate client, Windows Update — bypasses Halton Meter entirely.

Cause: WinHTTP is a separate networking stack from WinINet. The HKCU proxy registry set by halton-meter init is read by WinINet (Chromium/Electron/curl/most-of-Windows) but not by WinHTTP (Microsoft.HttpClient with WinHttpHandler, BITS, Windows Update, some corporate .NET tools).

Fix: Mirror the WinINet proxy into WinHTTP. This is a one-shot OS command — init does not do it because WinHTTP requires admin and most users don’t need it.

PS (elevated) — mirror WinINet → WinHTTP

PS> netsh winhttp import proxy source=ie
Current WinHTTP proxy settings:
    Proxy Server(s) :  127.0.0.1:8081
    Bypass List     :  <local>

PS> netsh winhttp show proxy          # confirm

Re-run after every halton-meter init only if WinHTTP-only clients are part of your workflow. Most users do not need this.

`certutil -user -addstore Root` failed

Symptom: init reports the cert trust step failed. halton-meter doctor shows cert:user-root-store: FAIL.

Most common cause: Group Policy on a corporate-managed machine is blocking user-level certificate trust additions.

Diagnosis:

PS — check policy

# Is there a Group Policy override on Root trust?
PS> reg query "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root" /v "DisableRootAutoUpdate"
PS> reg query "HKCU\Software\Policies\Microsoft\SystemCertificates\Root"

# Is the mitmproxy CA actually in the user Root store?
PS> certutil -user -store Root | findstr /i "mitmproxy"

Fix (corporate machine): Talk to IT. Group Policy that blocks user-level Root additions also blocks every developer tool that intercepts HTTPS locally (mitmproxy, Charles, Fiddler). The mitmproxy CA itself is private to your machine — it doesn’t ship a backdoor — but the policy may need an exception.

Fix (personal machine, no policy): Try the trust step manually to see the actual error:

PS — manual trust attempt

PS> certutil -user -addstore Root $env:USERPROFILE\.mitmproxy\mitmproxy-ca-cert.pem

The error message names the underlying NTSTATUS. Common ones:

0x80090010 (NTE_PERM) — Group Policy. See above.
0x80092004 (CRYPT_E_NOT_FOUND) — the cert file doesn’t exist. Re-run halton-meter init so step 1 regenerates the CA.

Task Scheduler tasks not running on logon

Symptom: After a reboot or logout/login, halton-meter status shows the daemon isn’t running. Task Scheduler shows halton-meter / halton-meter-edge exist but their last-run-result is non-zero, or they never fired.

Diagnosis:

PS — inspect tasks

PS> Get-ScheduledTask -TaskName "halton-meter*" | Select-Object TaskName, State, Triggers, Actions
PS> Get-ScheduledTaskInfo -TaskName "halton-meter"          # LastRunTime, LastTaskResult

Cause: stale binary path after upgrade. Task Scheduler XML embeds the absolute path to the halton-meter binary. After a pipx upgrade or uv tool upgrade that moved the venv, the task points at a path that no longer exists.

Fix: Re-run halton-meter init. It re-registers the tasks with the current binary path.

Cause: LastTaskResult is non-zero. Some other component failed. Look at the daemon log:

Get-Content $env:USERPROFILE\.halton-meter\daemon.err.log -Tail 100

Apps already running don’t pick up the new proxy

Symptom: After init, your IDE (Cursor / VS Code / Windsurf) keeps making LLM calls that don’t appear in halton-meter report. New PowerShell tabs work fine.

Cause: Windows reads env vars from HKCU\Environment at process creation time. Running processes get a snapshot when they started. The WM_SETTINGCHANGE broadcast does refresh WinINet (so Electron apps’ HTTP stack picks up the proxy), but it does not refresh environment variables in already-running processes.

For env-based clients (Python SDKs, Node CLIs reading process.env):

Fix: Full app exit + relaunch.

IDE: right-click tray icon → Quit, or taskkill /F /IM cursor.exe, then relaunch.
PowerShell: close the window and open a new one.
Windows Terminal tabs: each new tab inherits fresh env; old tabs do not.

Verify the new instance has the proxy:

PS — verify env in new shell

PS> echo $env:HTTPS_PROXY
http://127.0.0.1:8081
PS> echo $env:NODE_EXTRA_CA_CERTS
C:\Users\you\.mitmproxy\mitmproxy-ca-cert.pem

Registry proxy keeps disabling itself

Symptom: Hours after init, the registry proxy is gone. halton-meter doctor reports system_proxy:registry: FAIL and re-running halton-meter init puts it back, but the cycle repeats.

Cause: A corporate-managed proxy management tool (often shipped with Endpoint Detection / VPN clients like Cisco AnyConnect, Zscaler, Palo Alto GlobalProtect) reasserts its policy on every interval. The HKCU registry write is being clobbered.

Fix: Talk to IT. The two stacks (Halton Meter as a local mitm + the corporate proxy management) need to coexist. Options:

Add an exception in the corporate policy that allows HKCU\…\Internet Settings\ProxyServer=127.0.0.1:8081.
Chain Halton Meter behind the corporate proxy via [upstream] proxy_url = "..." in ~/.halton-meter/config.toml.
Run Halton Meter only when you’re off-corporate-network and accept capture won’t run on the corporate network.

Halton Meter on WSL2 — what works, what doesn’t

Scope statement (phase 0): WSL2 guest traffic is not routed through the Windows-host Halton Meter daemon. The Windows daemon listens on 127.0.0.1:8081 of the Windows host; from inside a WSL2 distro, that’s a different network namespace. The default localhost mapping that WSL2 set up does not forward to the Windows host’s loopback.

Workaround: install Halton Meter inside the WSL2 distro itself (treat the distro as a Linux machine — see Install Linux). The WSL2 install captures Linux-side traffic; the Windows install captures Windows-side traffic; they roll up to the same Cloud workspace if you pair both.

Full WSL2 guest-routing support is deferred post-v1.0.