Screenshot returns undecodable image on VM/RDP desktops after the first capture

[SIMON-WORLD]

Summary

Screenshot becomes unreliable on VM/RDP-hosted interactive desktops after the first successful capture: subsequent calls return an image the MCP client reports as "undecodable image" (empty/invalid bytes), while Snapshot and window listing keep working.

Environment

• Windows 11 VM guest (VMware/VirtualBox) driven through an RDP-hosted interactive session
• Codex Desktop 26.803.5235.0 with windows-mcp 0.8.5 via uvx windows-mcp serve
• Python 3.14, screenshot backend auto (dxcam -> mss -> pillow)

Reproduction

1. Start a session with the MCP server and call Screenshot once: returns a valid desktop image.
2. Perform UI actions (open an app, type), then call Screenshot again: returns "undecodable image".
3. Retrying 10+ times, including forcing pillow and dxcam backends, produces the same result.
4. Note: the same environment cannot use Windows.Graphics.Capture at all (SetIsBorderRequired failed 0x80004002), which is typical for VMs/RDP without full WDDM capture support.

Workaround found

Setting server env WINDOWS_MCP_SCREENSHOT_BACKEND=mss and WINDOWS_MCP_DISABLE_FLASH=1, then restarting the server, makes captures stable afterwards.

Suspected causes

• The always-on-top orange-red flash overlay window (rendered after capture) may break subsequent captures on capture-unfriendly environments.
• The auto backend fallback may not handle a dxcam partial-initialization failure that produces empty frames instead of raising an exception, so it never falls through to mss/pillow.

Expected behavior

• Screenshot should either fail loudly with a useful error and automatically fall back to a working backend, or remain stable across repeated calls.

[hugosmoreira]

Hi! I’d like to work on this. The current fallback appears to be exception-driven, while your report suggests a backend may return unusable output without raising. I would start with a regression test for that condition, verify fallback to the next backend, and cover the flash sequencing. I don’t have your exact VM/RDP environment, so I would use deterministic tests locally and ask you to validate the candidate patch on your setup. Does that direction sound useful?

[Jeomon]

A likely fix for this is now on main (#397, 8800458), but I would like your confirmation before closing.

windows_mcp/desktop/screenshot.py now detects a backend returning an empty frame and falls back to mss instead of handing the caller an undecodable image.

The reason I am not closing this outright: the failure is specific to VM/RDP desktops after the first capture, and I could not reproduce it on physical hardware here — the fallback logic itself is covered by tests/test_screenshot_fallback.py, but the trigger condition is not something I can exercise. So this is a fix aimed at the reported symptom rather than one I have confirmed end to end on an affected machine.

Could you try main on the RDP/VM setup where you saw it and report back? In particular, whether repeated captures in one session now stay decodable. If it still reproduces, the frame that comes back — and whether it is empty versus malformed — would tell us whether the detection threshold is wrong or the fallback is not engaging at all.