While rendering if the IDirect3DDevice9Ex::PresentEx
method returns D3DERR_DEVICEHUNG
then I release the resources and call IDirect3DDevice9Ex::ResetEx(&m_d3dParams, NULL)
where m_d3dParams
is of type D3DPRESENT_PARAMETERS
. Unfortunately, the ResetEx
method returns D3DERR_INVALIDCALL
. My second parameters is NULL
because I'm not in a full screen mode. How to call properly ResetEx
? Is it necessary to call ResetEx
when using D3D 9Ex ? Is it not enough to simply call Reset
?
Also, is there a way to reproduce D3DERR_DEVICEHUNG
error and what does this error mean ?
Thank you in advance for your help !

- 11
- 1
-
Just as a bit of background: ``Direct3D9Ex`` was never a compelling API. On all systems that supported it, Direct3D 11 is supported so there's really no point in using it for new projects. The primary consumer of ``Direct3D9Ex`` was the Windows Vista shell and a few media apps (back then Media Foundation interop was limited to Direct3D9). As such, there's basically zero developer education or samples covering it. – Chuck Walbourn May 22 '20 at 18:48
1 Answers
With Direct3D 9, you are supposed to wait until TestCooperativeLevel
returns S_OK
before you try to Reset
from lost device. With Direct3D9Ex, the same should be done with CheckDeviceState. Make sure you are doing this...
With Direct3D9Ex, you are using "DXGI device removed" scenarios rather than the older legacy "Lost device" you got with Direct3D 9.
The modern "DXGI device removed" happens in a few cases:
A new video driver is installed while you are running a Direct3D application
Some systems (typically servers and some hybrid devices) support physical hot-swapping of video components
Other cases of failure are "DXGI device hung" or "DXGI device timeout". This typically means that there is either a driver/hardware bug -or- you submitted a very long-running compute shader (not a thing with Direct3D9Ex). You can simulate this behavior by triggering a "TDR". VS 2015 or later has a command-line tool in the Developer Command Prompt:
dxcap --forcetdr
Keep in mind this forces it for the entire system, so you may have some trouble with debugging depending on where you set the breakpoint unless you use remote debugging.
See Microsoft Docs.
In general, 'device removed' means everything is gone: all loaded video RAM objects, all driver state, etc. For Direct3D 10+, the only recourse is to release all Direct3D interfaces and re-create the device. For Direct3D9Ex, there's no support for D3DPOOL_MANAGED
, so you have to re-create all your resources anyhow--it at least happens a lot less often than legacy 'lost device'.
In fact, the only published official sample for Direct3D9Ex doesn't even handle 'device removed'.

- 38,259
- 2
- 58
- 81
-
Thanks for your help. The command `dxcap -forcetdr` helped me to fix the D3DERR_DEVICELOST error. However, how to reproduce D3DERR_DEVICEHUNG error ? Is it possible to use TDR to reproduce this error case ? – m4d May 25 '20 at 08:34
-
1Functionally, the application needs to do the same thing for all those errors. – Chuck Walbourn May 25 '20 at 22:37