Windows capture APIs: where window privacy can fail

Screen-share privacy on Windows is not a single switch in a single graphics API. Desktop Window Manager (DWM), DXGI Desktop Duplication and the older BitBlt operation sit at different points in the graphics stack. For builders, that distinction matters more than treating “window capture” as one uniform request.

There is no specific Windows API release or dated platform change to report here. The useful development to track is how capture tools and privacy controls intersect with these separate routes. A block aimed at one route is not, by itself, evidence that every route is covered.

Three APIs, different jobs

DWM is the Windows component that manages and composes the desktop’s windows for display. Its role in presenting the desktop does not mean every screen-sharing app simply asks DWM for one finished image. Capture software can use different mechanisms, and the path can depend on what it needs to capture.

DXGI Desktop Duplication provides a way to acquire frames from a display output. That is useful for applications that need a changing view of a monitor. It is not the same thing as requesting pixels from one named application window. A capture flow that works at output level may include more than the window a user thinks they selected.

BitBlt is a graphics operation commonly associated with copying pixels between device contexts. It comes from an older Windows graphics interface, but “older” does not mean irrelevant: software may still rely on established paths. The important question for a privacy review is whether the capture application uses that path, not whether the API sounds dated.

Why API blocking is not a universal guarantee

OS graphics API capture controls aim to interfere with capture at the point where software requests or copies image data. That can be more targeted than hiding an app, closing it, or relying on a meeting app’s own selection interface. But blocking named APIs should be understood as control over those paths, not proof that no image can escape under every configuration.

Capture software can differ by version, feature and platform. A user may share a window in one session and a full display in another. Updates can also alter how an application obtains frames. A careful test therefore checks the actual setup: which app is sharing, whether it is sharing a window or display, what is visible to the recipient, and what happens when the private window changes.

This is why privacy claims should identify the mechanism. “Window isolation” is too broad if it leaves unclear whether the control masks a title, changes what a capture API can read, or only affects one sharing workflow. The distinction between focus modes and per-window cloaking as separate privacy layers is useful here: quieting interruptions and limiting captured content solve different problems.

What builders should test

• Test each sharing mode. Check both application-window sharing and full-display sharing where available. Do not assume one result predicts the other.
• Include a live change. Open, move, or switch to a private window after sharing begins. A static pre-call check may miss what happens during normal work.
• Check titles as well as pixels. A masked window image does not necessarily mean its title is hidden elsewhere, such as a task switcher or taskbar.
• Repeat after updates. A capture path can change when either the sharing software or privacy tool changes. Treat a previous test as a baseline, not a permanent guarantee.

These checks are practical, not a substitute for a platform-level guarantee. They help teams find mismatches between the intended sharing mode and the actual capture behavior, and they keep the scope of a privacy claim honest.

Where NoCapture fits

Membran Digital’s NoCapture lists per-window cloaking, title masking, global hotkeys and OS-level API blocking among its features. The company says that blocking covers DXGI, BitBlt and DWM APIs. That describes the product’s stated approach; it should not be read as a claim that every capture route or configuration has been independently verified here.

NoCapture supports Windows 10/11, macOS and Linux. Its listed pricing is a free tier for two windows, Pro at $5 per month, and Teams at $49 per month. Those details give practitioners a concrete option to evaluate, but the right test remains the same: verify the exact apps and sharing modes used in your own workflow.

The takeaway for this month is straightforward. DXGI, DWM and BitBlt are not interchangeable names for one capture switch. Builders should ask which layer a control addresses, test the capture path they actually use, and avoid treating API blocking as a blanket promise of invisibility.