Skip to content

Troubleshooting and FAQ

Jump to bottom
Max Ivankovsky edited this page Aug 12, 2026 · 1 revision

Troubleshooting and FAQ

"A domain shows 'Unscored' in the Incidents feed"

Two different, unrelated causes, depending on which version you're running:

  • If you're on v0.7.0 or earlier: this was a real bug. Domain risk scoring silently failed on every single lookup in the packaged build, because a data file the WHOIS library needs at runtime wasn't bundled into the installer. Fixed in v0.7.1; update and it resolves itself for every match going forward (existing "Unscored" incidents stay as they are, since that's already-recorded history).
  • If you're on v0.7.1+ and still seeing it: some registries just don't return a parseable registration date. Israel's .il registry, for one, reports it under a field name (assigned:) the WHOIS library's parser doesn't recognize, so the lookup correctly comes back "couldn't determine domain registration age" rather than guessing. This is an accurate "we don't know," not a bug: an honest "Unscored" beats a fallback parser that might misread some other registry's format entirely.

"I set a policy to Block, but it's only Flagging"

Check, in this order:

  1. Is Simulate mode still on? New policies default to Simulate mode on. It overrides everything else: a Block action with Simulate on behaves exactly like Flag. Turn it off in the policy editor.
  2. Is a risk threshold set that the match doesn't meet? If you configured "only block when risk is at least High" and the domain scored Low or Medium, that's the flag you're seeing, correctly.
  3. Is this actually the policy governing the match? Click into the incident and check which policy it's tied to. If you have multiple policies for the same data type, the client (desktop agent or browser extension) picks up policy changes on its next heartbeat, not instantly: within about 2 minutes for the desktop agent, up to 5 for the browser extension. If it's been longer than that, something's actually wrong; check the agent's log at %ProgramData%\CloakDLP\logs\agent.log for a [pairing] console's credit-card policy changed line confirming it noticed.

"The tray icon didn't show up after installing"

Should be immediate as of v0.6.0+: the installer launches it directly when setup finishes, not just at next logon. If you're on an older version, update. If it's still missing on a current version, check Task Manager for CloakDlp.Tray.exe; if it's not running at all, try logging off and back on (it also starts via a Startup-folder shortcut, visible and toggleable from Settings → Apps → Startup).

"Clipboard detection isn't catching anything"

If you copy a genuinely Luhn-valid card number (a random-looking string of digits often isn't one; card numbers pass a checksum) and nothing happens:

  • Confirm the matching policy actually covers the clipboard channel.
  • Confirm it's enabled and, per above, not silently downgraded by Simulate mode if you expected a block.
  • Clipboard detection runs from the tray notifier specifically, not the background Windows Service. This is deliberate: Windows Services run in an isolated session that literally cannot see the interactive desktop's clipboard, confirmed directly during development. If the tray notifier isn't running (see above), clipboard detection won't work no matter what your policies say.

"Why does the extension only cover some checkout pages?"

The browser extension blocks real <form> submissions with a native submit event. A checkout flow that reads the card field and sends it via fetch()/XHR directly, with no actual form submission involved, has nothing for the extension to intercept at that point; it still detects and reports the value as it's typed, it just can't stop that specific kind of submission. This is a known, documented scope limit, not a bug.

"Does CloakDLP send my card number anywhere?"

No. The full number never leaves your browser or your machine. Detection happens locally (in the browser extension or the desktop agent), values are redacted to the last 4 digits immediately, and only the redacted snippet plus the destination domain are ever written down, into your own local console, running on your own PC. There is no CloakDLP-operated server of any kind. The only outbound network calls CloakDLP itself makes are to public WHOIS servers and the URLhaus blocklist feed for domain risk scoring, neither of which receives any card data.

Where are the logs?

Everything lives under %ProgramData%\CloakDLP\:

  • logs\agent.log: desktop agent service
  • logs\tray.log: tray notifier (also handles clipboard detection)
  • logs\CloakDLPConsoleService.out.log / .err.log: console backend
  • cloakdlp.db: the SQLite database backing everything shown in the console

Clone this wiki locally