 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Lost Device Due to Display Uniqueness Change |
|
 |
Darklighter Member since: 12/30/2005 From: Montreal, Canada |
|||
 Posted - 7/19/2008 9:50:13 PM |
||||
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: 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: 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? |
||||
|
||||
|
Buckeye Member since: 2/10/2008 From: Emmaus, PA, United States |
|||
|
Posted - 7/19/2008 10:20:06 PM |
||||
Quote: 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. |
||||
|
||||
|
Darklighter Member since: 12/30/2005 From: Montreal, Canada |
||||
|
Posted - 7/20/2008 3:13:49 AM |
|||||
Thanks for the reply.Quote: 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: Yes, as stated in the documentation. Quote: I have tried killing the Desktop Window Manager process and service, but still the error persists. Quote: 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? |
|||||
|
|||||
|
Buckeye Member since: 2/10/2008 From: Emmaus, PA, United States |
|||
|
Posted - 7/20/2008 10:21:34 AM |
||||
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: 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. |
||||
|
||||
|
Darklighter Member since: 12/30/2005 From: Montreal, Canada |
||||
|
Posted - 7/20/2008 2:00:52 PM |
|||||
Quote: No, but I discovered that IDirect3DDevice9::Present crashes as well (in normal circumstances it should return D3DERR_DEVICELOST). Quote: I tried most combinations of resolutions and formats supported by my display without success. Quote: 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: ...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. |
|||||
|
|||||
|
Buckeye Member since: 2/10/2008 From: Emmaus, PA, United States |
|||
|
Posted - 7/20/2008 2:06:13 PM |
||||
Quote: 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. |
||||
|
||||
|
ET3D Member since: 10/24/2004 |
|||
|
Posted - 7/21/2008 3:58:48 AM |
||||
| Interesting. I got this error yesterday once, but only once (Vista x86, GeForce 9600, windowed app). Returned to normal after that. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
