Home
TR
Reference

Troubleshooting

Concrete fixes for capture, OCR, translation, and antivirus issues, grounded in how Snipdeck actually works.

This page collects the problems people hit most often and the practical fixes for each, with a short explanation of why the issue happens so the fix makes sense. Most of these behaviors are deliberate trade-offs in how Snipdeck captures the screen and reads text, not bugs.

If something here does not match what you are seeing, check the FAQ or open an issue on the project’s GitHub page.

Win + drag does not trigger the first time

Symptom. After Snipdeck has been idle for a while, the very first Win + drag — often on a secondary monitor — does nothing. The second attempt, and every one after it, works perfectly.

Why it happens. Snipdeck arms captures from a Windows low-level input hook (WH_MOUSE_LL / WH_KEYBOARD_LL). These hooks have a strict per-callback timeout: if your process is sitting idle at normal priority, Windows can suspend the hook chain and drop the first event delivered after a quiet period. That dropped event is your first Win + drag, so the capture never arms.

The fix is already built in. On Windows, Snipdeck raises its own process to HIGH_PRIORITY_CLASS at startup specifically to keep the hook callback responsive after idle. The UI is static, so this has no practical performance cost. If you still see the occasional missed first drag:

  • Just drag again. The second attempt always arms.
  • Make sure only one Snipdeck instance is running. A second copy would fight the first over the global input hooks. Snipdeck enforces a single instance per session, but a stuck process from a previous session can interfere — check the tray and Task Manager.

Note: Because the capture is driven by a global hook rather than a registered hotkey, the modifier you are holding is read live from the OS at the moment you click. If you release Win mid-drag, the snip still completes and the Start menu is suppressed.

A captured snip is black or blank

Symptom. The snip you just took is solid black, or a specific window (a hardware-accelerated browser, a video player, a game, or a GPU-composited terminal) shows up black while everything around it captures fine. This is most common on multi-GPU laptops.

Why it happens. Snipdeck captures the monitor with the DXGI Desktop Duplication API, which reads the actual frame the Desktop Window Manager composited on the GPU. This is what lets it capture GPU-composited and DirectComposition surfaces that a plain GDI BitBlt would render as black. When Desktop Duplication is unavailable, Snipdeck automatically falls back to the GDI path.

A fully black snip falls into one of these cases:

CauseBlack regionFixable?
DRM-protected content (e.g. a Netflix tab)Just that surfaceNo — enforced in hardware
The secure / UAC desktop was on screenThe whole frameNo — duplication is blocked there
An HDR or non-B8G8R8A8 outputThe whole monitorFalls back to GDI automatically
No DXGI output matched the cursor pointThe whole monitorFalls back to GDI automatically

What you can do:

  • DRM content is unavoidable. Protected video is black under Desktop Duplication and under the GDI fallback. This is enforced in hardware to prevent screen recording; Snipdeck cannot and does not work around it.
  • Avoid capturing over the UAC / secure desktop. Dismiss any elevation prompt before you snip.
  • Multi-GPU black windows usually mean the duplication path failed for that monitor and the GDI fallback ran, which cannot read the accelerated surface. Try moving the window to your primary display, or updating your GPU driver so Desktop Duplication succeeds on that output.

Tip: Snipdeck logs DXGI capture failed (...); falling back to GDI when it switches paths. Run the executable from a terminal to see these messages, which tell you whether you hit the fallback.

Why the UI itself looks plain (software rendering)

Separately from capture, Snipdeck forces Slint’s software renderer (SLINT_BACKEND=winit-software) instead of the GPU-accelerated one. This is intentional: the GPU renderer’s window-level transparency depends on per-GPU DWM behavior, so on multi-monitor setups with different adapters the selection overlay would end up opaque on one monitor and transparent on another. Software rendering goes through DWM’s standard composition path and behaves identically on every monitor. The UI has no animation or 3D, so there is no visible performance cost, and skipping the GL context lowers memory use. This is not a bug and there is no setting to change it.

Your antivirus or EDR flags Snipdeck

Symptom. Windows Defender, SmartScreen, or a corporate EDR agent warns about snipdeck.exe, quarantines it, or blocks it from starting at login.

Why it happens. A screen-snipping tool legitimately does things that look suspicious to heuristics: it installs global mouse and keyboard hooks, captures the screen, and starts itself at login. Snipdeck is deliberately built to minimize false positives, but a brand-new, unsigned binary from an independent developer can still trip reputation-based warnings like SmartScreen.

What Snipdeck does to avoid this:

  • Launch-at-login is registry-free. Snipdeck does not write an HKCU\…\CurrentVersion\Run value — that registry Run key is the single most heuristically-flagged autostart vector for antivirus and EDR tools. Instead it drops an ordinary Snipdeck.lnk shortcut into your shell:Startup folder, the same user-visible mechanism the Windows Settings UI manages:

    %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\Snipdeck.lnk

  • The binary is not UPX-packed. Executable packers are heavily associated with malware, so packed binaries draw extra scrutiny. Snipdeck’s release profile keeps the binary small with whole-program LTO (lto = "fat"), a single codegen unit, and symbol stripping (strip = true) — but keeps full opt-level = 3 optimization and never runs a packer. The shipped .exe is a normal, unpacked Rust binary.

What you can do:

  • If SmartScreen shows “Windows protected your PC,” click More info → Run anyway for the official snipdeck.exe from the Releases page.
  • If an EDR agent quarantines the file, add an allow-list exception for the executable, or build it from source yourself so you control the exact binary (see Installation).
  • Because the binary is open source and unpacked, you or your security team can audit and reproduce the build.

OCR returns no text

Symptom. You run OCR + Clipboard (or check a snip’s indexed text) and get nothing, or an “no text found” message.

Why it happens. Snipdeck uses the OS’s built-in Windows.Media.Ocr engine, fully locally. It returns empty when it genuinely cannot find recognizable text. Common causes:

  • The image is too small. The WinRT engine fails on very small images (roughly under 40 px on either side). Snipdeck automatically up-scales tiny snips with a Lanczos filter before OCR, but extremely small or single-character crops can still come back empty. Capture a slightly larger region.
  • There is no readable text — the region is a photo, an icon, a heavily stylized logo, or handwriting. The engine recognizes printed text, not arbitrary glyphs.
  • The script is not installed. OCR uses the languages in your Windows user profile, falling back to en-US. If you are capturing text in a script your system has no OCR language pack for, install it under Settings → Time & language → Language & region, add the language, and ensure its optional OCR feature is present.
  • Low contrast or tiny on-screen text. Zoom the source content in before capturing so the characters are larger and crisper.

Note: OCR runs in the background for every snip so the gallery’s full-text search works. If a snip’s search text is empty, the same reasons above apply.

OCR + Translate fails

Symptom. OCR works (you can copy the recognized text), but OCR + Translate shows an error, often something about the network or the request failing.

Why it happens. Unlike OCR, translation is not local. OCR happens on your machine, then only the recognized text is sent to Google’s public translate_a endpoint to be translated. That single network call is where this step can fail:

  • No internet connection. Translation needs network access; OCR does not. If you are offline, OCR still works but translate cannot.
  • A firewall or proxy blocks the request. The call goes to translate.googleapis.com over HTTPS. A corporate proxy or content filter may block it.
  • The endpoint rate-limited your IP. This is an unofficial, keyless endpoint. Hammering it from one IP can get you temporarily throttled. The volume from normal use (one short string per click) is trivial, so this is rare — wait a moment and retry.
  • The request timed out. Snipdeck uses a short timeout so a hung request cannot strand the worker thread. On a slow connection the call can time out; retry.

What you can do:

  • Confirm you have a working internet connection and can reach translate.googleapis.com in a browser.
  • If you are behind a proxy or filter, allow that host.
  • Retry — transient failures and throttling usually clear on their own. The UI degrades to an error message and lets you try again rather than crashing.

Warning: Translation is the one feature that sends data off your machine. Only the OCR’d text is transmitted, never the image, and only when you explicitly invoke translate. See Privacy & security for the full data-flow.

See also