My programm kills driver?

Started by
0 comments, last by Zipster 16 years, 2 months ago
Hello, I have a BIG problem that really drives me crazy: I have written a DirectX10 application which run without any problems. Today I changed some code (nothing special, instead of reading a char stream the application now reads a 32bit floatingpoint stream to create a terrain). But when I run the program with the modified code the whole computer screen turns black for 2-3 seconds and then I get a little popup on the lower right side that says (translated):
Quote:"The display driver was reset after an error occured. Device driver nvlddmkm doesnt react and was successfully reset.
Moreover I get this debug output from my application:
Quote:Removing Device. D3D10: ERROR: ID3D10Device::Flush: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT ]
And on every frame I get this debug output:
Quote:First-chance exception at 0x771c3843 in SkyRendering.exe: Microsoft C++ exception: _com_error at memory location 0x0017f674..
I am using 64 Bit Vista Business. I didnt know what to do so I fully deleted my display driver and reinstalled it. I just tried my application and the same problem occurs! How is it possible that my little program crashes the display driver? Was anyone faced with the same problems or has an idea what I could do? :(
Advertisement
We've gotten this before in our DX10 application. It seems that if the driver takes too long to perform some operation, Vista thinks it crashed and resets it. In our case we were trying to render too much geometry in a single draw call with a complex pixel shader, and the driver would hang. At least that's what we think the problem was, since when we simplified the shader so that it took less time, everything seemed to work. Maybe there was something else the driver didn't like about our shader, but there's no way we can ever know. What's worse was that the crash was only semi-reproducible -- it would only happen maybe 11 out of 20 runs. We'd literally just sit there and restart it over and over (it occurred during initialization so there wasn't any variability on the user's end).

For what it's worth, our application always crashed on the Present call. So if you can catch that in the debugger, you might be able to narrow down the sequence of draw calls that caused it.

This topic is closed to new replies.

Advertisement