How Windows Screen Capture Exclusion Actually Works

If you've ever wondered how a window can be visible on your own screen but absent from a Zoom share, a Teams recording, or an OBS capture, the answer isn't a hack, a driver, or a virtual display trick. It's a single, documented Win32 API call: SetWindowDisplayAffinity. This post explains what it does, why it works, and where its limits are.

The short version

Windows lets an application tag one of its own windows with a "display affinity" — a flag that tells the compositor which output surfaces are allowed to show that window's pixels. Set the affinity to WDA_EXCLUDEFROMCAPTURE, and the Desktop Window Manager (DWM) stops including that window's contents in anything that captures the screen programmatically: screen-sharing tools, recording software, and screenshot APIs. The window still renders normally to a human looking at the physical monitor.

That's the entire mechanism. No kernel driver, no hooking, no injecting into other processes. It's a flag on your own window, honored by the compositor that owns the entire desktop's rendering pipeline.

Why this is possible at all

Modern Windows doesn't let applications draw directly to the screen. Every window is composited by DWM, which owns a single shared surface (the desktop) and decides, frame by frame, which window's buffer goes where. When a screen-sharing tool wants to capture your desktop, it isn't reading pixels off the physical display controller — it's asking DWM (via the Desktop Duplication API, Windows Graphics Capture, or a similar surface) for a copy of the composited frame.

SetWindowDisplayAffinity works by teaching the compositor to skip a specific window's buffer when it's building any frame that isn't destined for the physical monitor. The API signature is almost insultingly simple:

BOOL SetWindowDisplayAffinity(
  HWND   hWnd,
  DWORD  dwAffinity
);

Pass WDA_EXCLUDEFROMCAPTURE (value 0x00000011) and that window is opted out of every capture surface DWM services — Desktop Duplication API (what most screen-share software actually uses under the hood), the older PrintWindow and BitBlt screenshot paths, and Windows' own Snipping Tool and Game Bar recorder. Pass 0 and the exclusion is lifted.

Where the requirement actually comes from

WDA_EXCLUDEFROMCAPTURE was introduced in the Windows 10 May 2020 Update (version 2004). Before that, Windows only offered WDA_MONITOR — a cruder flag that blacked out the window entirely on any secondary output, useful for DRM-protected video playback but useless for something you still want to see and interact with yourself. WDA_EXCLUDEFROMCAPTURE is the newer, more surgical version: exclude from capture, not from display.

The practical consequence is a hard floor on compatibility. Anything built on this API only works on Windows 10 version 2004 or later, or Windows 11. There's no fallback for Windows 8, no polyfill, and no equivalent API on macOS or Linux — this is a Windows-specific compositor feature, not a cross-platform standard. An application that depends on it either needs to detect the OS version at startup and refuse to run the stealth path, or (more honestly) needs to tell the user up front that this feature is Windows-only.

What it does and doesn't hide

It's worth being precise about the boundary here, because "invisible" gets used loosely in marketing copy (including, at times, our own).

What WDA_EXCLUDEFROMCAPTURE actually excludes a window from:

• Screen shares in Zoom, Google Meet, Microsoft Teams, Webex, and anything else built on the standard Windows screen-capture surfaces
• Screen recordings made with OBS Studio, the Xbox Game Bar recorder, or similar tools using Desktop Duplication
• Programmatic screenshots via PrintWindow, BitBlt, or the Windows Graphics Capture API

What it does not do:

• It does not hide the window from the taskbar, Alt-Tab, or Task Manager on its own — those are separate window styles and process-visibility properties, set independently (WS_EX_TOOLWINDOW, skipTaskbar, and so on)
• It does not make the process invisible to Task Manager. A process using this API still shows up by name (or whatever name it registers itself under) in the process list — display affinity affects window compositing, not process enumeration
• It has no effect on a second physical camera, a phone, or anyone physically behind you recording your monitor — this is a software-compositor feature, not a hardware one
• It does not defeat capture methods that don't go through the DWM-managed surfaces at all — a hardware HDMI capture card splicing the video cable downstream of the GPU, for instance, sees exactly what's on the monitor, unaffected by any window-level flag

That last point matters if you're evaluating any tool that claims blanket "undetectability." The API excludes a window from software-mediated capture. It cannot exclude pixels from a physical light path.

Why applications re-assert the flag continuously

If you inspect how a real implementation uses this API, you'll typically find it's not called once at window creation and forgotten. Windows can silently reset display affinity in a handful of situations — certain window-manager events, some DPI or monitor-configuration changes, and transitions in and out of fullscreen exclusive contexts on other windows. A robust implementation re-asserts WDA_EXCLUDEFROMCAPTURE on a short interval (commonly once a second) rather than trusting it to stick indefinitely, and re-applies it immediately after any event that's known to be able to clear it.

This is also why the window typically needs to stay WS_EX_NOACTIVATE and non-focusable: giving it real keyboard focus increases the number of code paths that can inadvertently touch window styles and affinity flags. Keeping it click-through and non-activating (via SetWindowLongPtrW with extended styles) reduces the surface area for the exclusion to get reset by accident.

The practical takeaway

If a Windows application claims its window is invisible to screen shares, SetWindowDisplayAffinity(hwnd, WDA_EXCLUDEFROMCAPTURE) is very likely the mechanism, because it's the only supported, non-hacky way to achieve that behavior on modern Windows. It's a real, Microsoft-documented API, not folklore. What separates a well-built implementation from a fragile one is:

1. Correctly gating the feature behind a Windows-version check (2004+) instead of silently failing on older systems
2. Re-asserting the flag on a loop rather than trusting it to persist
3. Being honest that this affects window capture, not process visibility, taskbar presence, or physical recording

Further reading

Microsoft's own documentation for SetWindowDisplayAffinity is short and worth reading directly if you're implementing this yourself — it documents both WDA_MONITOR and WDA_EXCLUDEFROMCAPTURE, along with the minimum supported client (Windows 10, version 2004).

If you're curious how this fits into a full interview-assistance overlay rather than a standalone demo, see how InterviewPilot uses it alongside live transcription and screen analysis, or read about what proctoring software can and can't detect.