Jump to content
  • Advertisement
Sign in to follow this  
Darklighter

Lost Device Due to Display Uniqueness Change

This topic is 3775 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm experiencing a persistent Direct3D error that causes my application to crash in lost device scenarios when using the Debug Direct3D Runtime. This also happens with the Direct3D 9 SDK samples, which use identical code to handle lost devices (although wrapped in DXUT). Here's the output of the debugger:
Quote:
Direct3D9: :WM_ACTIVATEAPP: BEGIN Deactivating app pid=00000584, tid=000004cc Direct3D9: :DoneExclusiveMode Direct3D9: (INFO) :DDI threading stopped Direct3D9: :INACTIVE: 00000584: Restoring original mode (1680x1050x22x60) at adapter index 0 Direct3D9: :*** Active state changing Direct3D9: :WM_ACTIVATEAPP: DONE Deactivating app pid=00000584, tid=000004cc Direct3D9: (ERROR) :Lost due to display uniqueness change Windows has triggered a breakpoint in Test.exe. This may be due to a corruption of the heap, which indicates a bug in Test.exe or any of the DLLs it has loaded. This may also be due to the user pressing F12 while Test.exe has focus. The output window may have more diagnostic information.
I have searched around for a solution, but most occurrences of that error message involve the creation of multiple devices, yet my application uses a single device. It appears to be crashing on the call to IDirect3DDevice9::TestCooperativeLevel, but I can't step into my code as the breakpoint occurs in unknown territory:
Quote:
No symbols are loaded for any call stack frame. The source code cannot be displayed.
However, my application seems to behave properly when using the Retail Runtime or unchecking "Break on D3D9 Error" in the DirectX Control Panel. I'm using Vista, the March 2008 SDK and a GeForce 8600 GTS with latest drivers. Has anyone encountered this before?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
appears to be crashing on the call to IDirect3DDevice9::TestCooperativeLevel

You should be able to determine whether that's true or not and it's important to know exactly where the error occurs.

If you're using Visual Studio, then, in Debug mode, you can set a breakpoint at the line where the call to TestCooperativeLevel is made. If the app runs to that point without error, then press F10 (or whatever you have your single-set debugging key set to) to execute that line.

If the error occurs before that point, keep backing up your breakpoint until you determine the exact line where the error occurs.

Do you check the return code from TestCooperativeLevel and respond to a lost device immediately?

FYI: One google answer mentions initiating full screen mode with a backbuffer size different than the screen resolution and a timing problem between disabling the desktop manager and setting the new screen mode.

By any chance, are you going to full screen with a different resolution? If there's a timing problem, it may be due to the additional checking that's being done in Debug vs. Retail.

Also, FYI: The "No symbols loaded" is probably because the error occurs in a DLL.

Share this post


Link to post
Share on other sites
Thanks for the reply.

Quote:
Original post by Buckeye
You should be able to determine whether that's true or not and it's important to know exactly where the error occurs.


Sorry for the ambiguity. I have set a breakpoint that triggers when the application changes focus, and indeed it crashes on the call to IDirect3DDevice9::TestCooperativeLevel.

Quote:
Do you check the return code from TestCooperativeLevel and respond to a lost device immediately?


Yes, as stated in the documentation.

Quote:
FYI: One google answer mentions initiating full screen mode with a backbuffer size different than the screen resolution and a timing problem between disabling the desktop manager and setting the new screen mode.


I have tried killing the Desktop Window Manager process and service, but still the error persists.

Quote:
By any chance, are you going to full screen with a different resolution?


No, the backbuffer size matches the screen's resolution. In fact, I'm using IDirect3D9::GetAdapterDisplayMode to retrieve the display's resolution.

Any other suggestions?

Share this post


Link to post
Share on other sites
A little research, which you've already apparently done, seems to indicate you've discovered another instance of the combination of DirectX Debug mode + Vista + going fullscreen + NVidia.
Quote:
indeed it crashes on the call to IDirect3DDevice9::TestCooperativeLevel.

It certainly sounds like an unrecoverable error in the driver or possibly a problem with the coding of TestCooperativeLevel.

Techniquely it's a bit beyond me at this point, so I can only make suggestions for which I have no idea if they'll help:

1. Do you reset the device before the first TestCoop call?

2. Try different screen resolutions. One source indicated that he found a resolution that didn't display the problem. Unfortunately, that would prevent your app from being fully generalized.

3. Add a try()..catch() around the TestCooperativeLevel call and maybe you can recover from the error. I have doubts about this because you wouldn't know the state of the desktop. It would be a hack.

4. Long shot - create your device windowed but with the window hidden, then try going fullscreen.

Share this post


Link to post
Share on other sites
Quote:
Original post by Buckeye
1. Do you reset the device before the first TestCoop call?


No, but I discovered that IDirect3DDevice9::Present crashes as well (in normal circumstances it should return D3DERR_DEVICELOST).

Quote:
2. Try different screen resolutions. One source indicated that he found a resolution that didn't display the problem. Unfortunately, that would prevent your app from being fully generalized.


I tried most combinations of resolutions and formats supported by my display without success.

Quote:
3. Add a try()..catch() around the TestCooperativeLevel call and maybe you can recover from the error. I have doubts about this because you wouldn't know the state of the desktop. It would be a hack.

4. Long shot - create your device windowed but with the window hidden, then try going fullscreen.


Same results. In an attempt to trace the origin of the crash, I downloaded the Program Debug Database files for the Debug Direct3D Runtime and dumped d3d9d.dll and d3d9d.pdb in my Debug folder. The debugger loaded the symbols successfully:

Quote:
'Test.exe': Loaded 'C:\Users\Dominik\Desktop\Lost Device Test\Debug\d3d9d.dll', Symbols loaded (source information stripped).


...and yet it still can't find the symbols for that breakpoint. Does that mean that the crash occurs in a driver or operating system DLL? The issue disappears when using Direct3D 9 Extensions for Vista (IDirect3DDevice9Ex), but at the expense of backward compatibility with XP.

I have also upgraded to the June 2008 SDK, but no luck.

Share this post


Link to post
Share on other sites
Quote:
The issue disappears when using DirectX 9 Extensions for Vista (IDirect3DDevice9Ex)

Wow. Nice work, Darklighter. I'm just guessing that you don't have duplicate machines, one with XP, one with Vista. But you could check WINVER before you create the device.

Share this post


Link to post
Share on other sites
Interesting. I got this error yesterday once, but only once (Vista x86, GeForce 9600, windowed app). Returned to normal after that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!