When running an Eyeshot application on a laptop or workstation, users may occasionally experience freezes, crashes or “device removed” errors after disconnecting external monitors, undocking a laptop, or connecting or reconnecting through Remote Desktop (RDP). This article summarizes the root causes of these issues and explains the scenarios in which they can occur.
Why this happens
Eyeshot uses Direct3D to create and maintain a GPU-backed rendering device. This device is tightly linked to the graphics adapter that was active when the viewport was created. If the operating system replaces, disables or switches the active GPU, the Direct3D device becomes invalid.
Typical situations that trigger a GPU switch are:
• Disconnecting the laptop from a docking station
• Unplugging external monitors
• Closing or reopening an RDP session
• Switching between an integrated GPU and a dedicated GPU
• Temporary GPU disable/enable events during remote connections
When the Direct3D device is lost, subsequent rendering calls may fail with exceptions such as Device Removed, NullReferenceException, or errors triggered internally by D3DImage.SetBackBuffer.
Three scenarios to distinguish
There are three different RDP workflows, and they do not behave the same:
- The application starts inside an RDP session, and you reconnect to the same session
This typically works. The GPU context remains consistent and Windows keeps the same virtual adapter. - The application starts inside an RDP session, and you then log in locally on the physical machine
This usually fails. The system switches from the RDP virtual GPU to the local physical GPU, invalidating the Direct3D device. - The application starts on the physical machine, and you later connect via RDP
This usually fails as well. Windows replaces the physical GPU with the RDP virtual GPU, causing a device loss.
Cases 2 and 3 are known limitations of Direct3D under RDP. The underlying graphics device changes and Direct3D cannot seamlessly recover from this transition. This behavior is not specific to Eyeshot; it affects all applications that rely on a persistent Direct3D device.
Is there a solution?
At the moment, there is no reliable way to recreate or migrate a Direct3D device in WPF during or after a GPU switch. WPF’s D3DImage infrastructure does not support dynamic reinitialization when the underlying GPU changes.
Because of these platform limitations, Eyeshot cannot safely rebuild its rendering context once the device has been removed.
If your users depend heavily on RDP:
• Always start and use the application entirely inside the same RDP session, without switching to the local console.
• Avoid workflows where the GPU changes during runtime.
• If possible, instruct users not to undock or unplug external monitors while the application is running.
• Consider running the application in OpenGL mode only if your deployment scenario supports it (note: RDP does not expose a real OpenGL context, so this is often not viable).
Conclusion
Freezes or crashes after disconnecting monitors, undocking, or switching between RDP and physical sessions are caused by Direct3D device loss. These are underlying limitations of the Windows graphics stack. Eyeshot cannot handle these transitions automatically, because the rendering device cannot be recreated safely after a GPU switch.
If your users need remote access, the most stable workflow remains launching and running the application entirely within the same RDP session.
Comments
Please sign in to leave a comment.