Question

An interesting bug came up that I’m having no luck with. In a windowed Direct3D9 program using native code, I handle a device lost using something similar to the following:

void MyClass::RecoverFromDeviceLost(LPDIRECT3DDEVICE9 deviceToRecover, D3DPRESENT_PARAMETERS devicePresentParams )
{


    HRESULT hr = deviceToRecover->TestCooperativeLevel();
    if(hr == D3DERR_DEVICELOST ) { 
        //Code to shutdown all D3DPOOL_DEFAULT allocated objects

    }else if(hr == D3DERR_DEVICENOTRESET){

        hr = deviceToRecover->Reset(&devicePresentParams);
        if(SUCCEEDED(hr))
        {
            //Code to rebuild all D3DPOOL_DEFAULT objects

        }

    }

}

This works fine on Vista, but seems to have major problems on XP. If the monitor is unplugged, or switched away from the PC via a KVM, I never receive the D3DERR_DEVICELOST. The only return value from TestCooperativeLevel I ever receive is D3DERR_DEVICENOTRESET. And every call to Reset gives a D3DERR_INVALIDCALL. I tried forcing the program to use the shutdown code by doing this:

...
else if(hr == D3DERR_DEVICENOTRESET){

        hr = deviceToRecover->Reset(&devicePresentParams);
        if(SUCCEEDED(hr))
        {
            //Code to rebuild all D3DPOOL_DEFAULT objects

        }else {
            //Duplicate of code to shutdown all D3DPOOL_DEFAULT objects
        }

    }
...

But there was no change. This problem only seems to affect Windows XP (so far tested on SP2, SP3). I am using the August 2007 DXSDK, and can’t update at this time. Has anyone seen this problem before, or have any idea why I can’t reset my device?

UPDATE: I believe I have found a solution, but am still perplexed by the failure of the second code segment listed above. After getting the DirectX Debug runtime to work over remote debugging, I realized the reason that the Reset function kept failing was because there were unreleased resources. However, the exact same release code, when applied as shown in the answer, resolved the issue. I did verify that the program was not creating D3DPOOL_DEFAULT objects between calls to the recover function. Is there something in the structure of Direct3D that could cause a problem if performing a reset as shown in the this question’s code segments?

Answer 1

I ended up testing a different program that uses DirectX for graphics, just to see if the problem was just with the one program. The other application recovered with no problems from a monitor unplug or KVM switchover in Windows XP. The main difference between the two programs was that the working one used DXUT to manage the Direct3d, whereas I was doing all manual management in the one that didn’t work. After combing through the DXUT source code, I noticed that they used a single step approach to device recovery that didn’t rely on a D3DERR_DEVICELOST being returned from TestCooperativeLevel prior to the D3DERR_DEVICENOTRESET return value. The following code seems to have fixed the problem:

void MyClass::RecoverFromDeviceLost(LPDIRECT3DDEVICE9 deviceToRecover, D3DPRESENT_PARAMETERS devicePresentParams )
{

    HRESULT hr = deviceToRecover->TestCooperativeLevel();
    if(hr == D3DERR_DEVICELOST ) { 
        //Device is lost and cannot be reset yet
        return;
    }


    //Code to shutdown all D3DPOOL_DEFAULT allocated objects

    hr=deviceToRecover->Reset(&devicePresentParams);
    if(SUCCEEDED(hr)){

        //Code to rebuild all D3DPOOL_DEFAULT objects

    }
}

This code does have the side effect of resetting multiple times if the monitor is unplugged (or KVM switched) for an extended period of time.