Halton Meter Docs
Docs /Operations /Troubleshooting (Windows)
OPERATIONS · 01 · WINDOWS Windows Beta

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.

Windows 10/11 · Python 3.11+ ·5 min read ·Updated Jun 8, 2026

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.

See also

  • Troubleshooting (shared): symptoms shared with macOS and Linux: PAUSED states, loopback bind guard, no captures, paused_unauthorised, install fails with TLS, body capture skip.
  • Install (Windows): the install reference with full scope table.
  • halton-meter doctor: every signal, every fix, in one command.