Why Screenshots Become Black in Windows

If you have ever pointed a capture tool at a protected exam app, streaming service, or casino client and only got a black window screenshot, you have hit Windows' protection layers. This article explains why screenshot becomes black in Windows, what APIs are involved, and how the graphics pipeline makes that decision.

We focus on the internals and legitimate security / compatibility research, not on breaking terms of service.

Screen capture protected window, black window, and what you are really asking

If you searched for screen capture protected window, capture black window, capture protected window, or how to capture black window, you are usually seeing one symptom: the window looks normal on your monitor, but OBS, Snipping Tool, Game Bar, RDP, or your own capture code records a black window or empty rectangle. That is typically intentional: the app or the OS has marked the surface so screen capture APIs omit protected pixels.

If you would like to capture a black window or protected window in the sense of fixing or understanding that behavior, the first step is to know *why* the pipeline returns black (below)—not to assume your capture code is broken. For authorized remote-desktop or lab scenarios, the companion post SetWindowDisplayAffinity bypass techniques maps the full capture stack (app hooks, duplication APIs, NVIDIA scanout, driver buffers, DWM, kernel) and links to reference implementations.

From GDI to DWM: Who Owns the Pixels?

On modern Windows, visible pixels are not drawn straight to the screen by each process. Applications render to off‑screen surfaces (often GPU textures). The Desktop Window Manager (DWM) composes those into the desktop image you see.

This has two important effects:

Capture APIs rarely read from the physical framebuffer.
The compositor can decide per surface whether it should be included in capture.

When you see a black window screenshot even though the window is clearly visible on your monitor, it usually means the surface was excluded at composition or capture time.

How SetWindowDisplayAffinity Prevents Screenshots in Windows

The most visible API here is SetWindowDisplayAffinity. A window can set flags such as:

WDA_NONE – normal capture
WDA_MONITOR – only visible on a local monitor, not on remote sessions
WDA_EXCLUDEFROMCAPTURE – exclude this window from screen capture

When a process marks its top‑level window with WDA_EXCLUDEFROMCAPTURE, the compositor and several capture paths are instructed to omit that content. The result depends on where you capture:

Per‑window capture (some streaming SDKs, RDP, modern capture APIs) will typically give you a transparent or black image.
Full desktop capture may still work in older APIs, but newer ones respect the exclusion.

This is one of the main reasons a protected window screenshot request yields an empty frame. When people search for “How SetWindowDisplayAffinity Prevents Screenshots in Windows”, this is the core mechanism: the window opts out of capture, and the compositor enforces that choice at composition time.

Why Some Apps Block Screenshots (Overlay Window Method)

Some apps combine affinity flags with overlay windows or special swap chain flags:

DirectComposition, DXGI, and full‑screen exclusive modes can mark layers as protected.
Hardware overlays allow content (e.g., DRM‑protected video) to bypass the normal compositing path.

If video is rendered on a protected overlay, the desktop image never contains the actual movie pixels. Capture tools only see the “holes” where the overlay will be placed, which again looks like a black window screenshot. This is often called the overlay window method, and it is a major reason why some apps block screenshots even when you use low‑level capture APIs.

This is why you might be able to grab the window frame, buttons, and static UI, but the video area or question content stays black.

Why Bluebook and Exam Apps Block Screenshots

Many exam platforms (for example, the Bluebook app for the SAT exam) enforce strict proctoring rules. They combine:

SetWindowDisplayAffinity and related flags,
special keyboard / input hooks,
and sometimes kernel‑mode drivers to monitor the environment.

From the capture side, your RDP or streaming solution may try to capture the desktop normally but receive blank frames for those protected windows. This is why Bluebook and exam apps block screenshots so aggressively: the goal is to prevent trivial cheating or unauthorized recording, while still letting the OS and GPU pipeline operate normally for unprotected content.

For security research or enterprise deployments, it is important to understand that this is intentional and not a “bug in your capture code”.

Why Simple Hooks Often See Black Too

Developers sometimes ask: “If I hook BitBlt or DirectX, why is the buffer still black?” There are a few reasons:

1. The call path changed – modern apps may use DXGI or DComp paths your hook does not see.

2. The source surface is already censored – the API you hook receives a texture that is solid black because the compositor stripped protected content earlier.

3. GPU side composition – relevant decisions happen in the GPU driver and kernel mode, not in the user‑mode API you patched.

In other words, once the protection decision has been made upstream, your user‑mode hook often cannot “un‑black” the pixels without violating the security model.

Where bypass work sits in the stack

Discussing capture of a protected window spans many levels: hooking the application, DXGI / Windows Graphics Capture duplication, NVIDIA scanout or frame‑buffer capture paths, graphics driver–visible buffers, DWM composition, and kernel or hypervisor research. Each layer has different feasibility, stability, and policy implications.

For a full layer-by-layer map and how it ties to authorized SetWindowDisplayAffinity bypass work, see SetWindowDisplayAffinity bypass techniques. To discuss architecture or research programs in more detail, contact us.

Kernel, Drivers, and Detection

At the lowest levels, the Windows graphics stack relies on:

Win32k.sys and friends for window management,
GPU drivers for actual pixel movement,
kernel‑mode paths for protected video playback (e.g., PlayReady, PVP).

Any attempt to bypass capture restrictions for unauthorized recording tends to leave strong forensic traces and violates platform and app policies. Security tooling can:

Detect untrusted drivers or suspicious hooks,
Watch for processes that try to access protected surfaces,
Correlate this with exam or DRM policy violations.

For red‑team or defensive research, the important part is knowing where decisions are made so you can reason about hardening, monitoring, and compatibility.

Takeaways for Tool Developers

If you build remote desktop, streaming, or monitoring tools on Windows and you are surprised that some windows always render as black:

First, check whether the target uses SetWindowDisplayAffinity or protected overlays.
Understand that black screenshots are often a feature, not a bug.
Design your product and support docs to clearly communicate which apps cannot be recorded for legal or technical reasons.

By understanding why screenshot becomes black in Windows, you can:

Avoid chasing impossible “fixes”,
Better explain limitations to your users,
And focus your research on legitimate compatibility and security analysis instead of breaking protections.

Why Screenshots Become Black in Windows