Troubleshooting & Diagnostics
Fixes for the most common issues with the Waxell desktop endpoint agent. Find your platform below, then scan for the symptom that matches what you're seeing.
The macOS app is notarized by Apple — Gatekeeper warnings shouldn't appear at all. The Windows preview is currently unsigned while our EV code-signing certificate finishes verifying, so a few Windows-only warnings (SmartScreen, Defender heuristics) are expected on the preview build. Future signed builds install with no warnings.
macOS
Gatekeeper / notarization warning
Symptom — macOS says the app "can't be opened because it is from an unidentified developer," or won't launch.
This shouldn't happen — the macOS build is notarized. If you do hit it (for example after copying the app between machines and stripping its quarantine attributes), right-click the app → Open, then confirm Open in the dialog. This only needs doing once.
Network monitor stuck on "Approve in System Settings"
Symptom — the app shows "Approve in System Settings" and the network monitor never activates.
The system extension needs a one-time approval:
- Open System Settings → General → Login Items & Extensions.
- Find Waxell and enable it.
- Click Allow on the content-filter dialog when macOS prompts you.
- Make sure the app is installed in
/Applications— the system extension won't load from a non-standard location (for example running it straight out of~/Downloads).
If the app isn't already in /Applications, drag it there, then relaunch and re-approve. macOS only loads the content-filter network extension for apps installed in the standard location.
Sign-in browser never returns to the app
Symptom — "Sign in with browser" opens your browser, you log in, but the app never flips to "Signed in."
The custom waxell:// URL handler that hands the browser session back to the app may not be registered. Quit and reopen Waxell Setup — it re-registers the handler on every launch — then try Sign in with browser again.
Windows
The Windows installer is unsigned until our EV code-signing certificate finishes verifying. Use the bundled team-install.ps1 script (which installs via msiexec) to avoid most warnings. The signed builds that follow won't show any of these.
SmartScreen blocks the MSI
Symptom — "This app isn't safe to install" or a blue SmartScreen screen when you open the MSI.
Use the bundled team-install.ps1 path, which runs the MSI via msiexec and doesn't trigger SmartScreen. If you double-clicked the .msi directly, click More info → Run anyway. Future signed builds won't show this.
Service not running / Defender quarantine
Symptom — after install, the WaxellNetworkMonitor service isn't running.
The network monitor watches outbound traffic, which looks malware-shaped to Microsoft Defender heuristics and can get false-positive quarantined.
- Open Windows Security → Virus & threat protection → Protection history.
- If
WaxellNetworkMonitor.exewas quarantined, restore it. - Add
C:\Program Files\Waxell\to Defender exclusions (theteam-install.ps1script normally does this for you). - Re-run
team-install.ps1.
To confirm the service state from a terminal:
sc query WaxellNetworkMonitor
# STATE: 4 RUNNING when healthy
Browser sign-in never returns to the app
Symptom — "Sign in with browser" opens your browser, you log in, but Setup never flips to "Signed in."
The custom waxell:// URL handler may not be registered. Close and reopen Waxell Setup — it re-registers the handler on every launch — then try Sign in with browser again.
PowerShell execution disabled
Symptom — "PowerShell execution disabled" (or a script-execution policy error) when running team-install.ps1.
Open PowerShell as Administrator and run:
Set-ExecutionPolicy -Scope CurrentUser RemoteSigned -Force
Then run the script again. This should be rare — the script self-elevates with -ExecutionPolicy Bypass — but a locked-down policy can still block the initial launch.
Memory Integrity (HVCI) is on
Symptom — on the Captures tab you see "Memory Integrity is on — L0 unavailable," and payload capture / QUIC SNI extraction don't work.
Windows 11 with Memory Integrity (a.k.a. HVCI — Hypervisor-protected Code Integrity) blocks the signed kernel driver that L0 payload capture and HTTP/3 (QUIC) SNI extraction depend on. The service silently downgrades to metadata-only.
Everything else keeps working normally — metadata flows, app discovery, hook governance, guard policy, cowork audit, and the in-app Captures and Activity tabs. The Captures tab surfaces the banner so an empty payload view isn't confusing.
If you need L0 capture on that endpoint, an admin can disable Memory Integrity (security trade-off) or wait for the attestation-signed driver. See the fleet guidance in the Windows MDM deployment guide for the full HVCI options.
Diagnostics
Windows — bundled diagnostic bundle
A diagnostic collector ships inside the install. Run it on a problem PC to gather everything support needs in one zip:
"C:\Program Files\Waxell\Setup\waxell-diagnose.ps1"
It writes a bundle to %TEMP%\waxell-diag-<datestamp>.zip. The bundle includes the service state, configuration, and (in section 10b) the device's HVCI / Memory Integrity status, so you can tell at a glance whether an endpoint is downgraded to metadata-only.
Where the logs live
| Platform | Log location |
|---|---|
| Windows | Service log: %PROGRAMDATA%\Waxell\service.log (i.e. C:\ProgramData\Waxell\service.log) |
| macOS | Console.app, or the app's Troubleshoot tab |
On Windows you can tail the service log directly:
Get-Content 'C:\ProgramData\Waxell\service.log' -Tail 20
When you file an issue, attach the diagnostic bundle (%TEMP%\waxell-diag-<datestamp>.zip on Windows) or the service log, plus a short description of what happened and a screenshot if something in the UI looks wrong.