Driver update causes XID 3

Hi,

I am the administrator for the http://delta3d.org open source game and simulation engine.

Since a driver update over this past summer we have been facing a serious show stopper bug that appears to be completely random in nature and doe not appear to be dependent on what is being rendered.

This problem is only seen on the desktop GEforce cards, I am running a 980 GTX with Windows 7 x64, the application is built in Visual Studio 2013 x64. I can confirm this same problem on at least 4 other computers with similar hardware.

At some point during a frame the graphics card throws an XID 3 “corrupt push buffer stream” and the driver does not recover, Windows 7 restarts the GPU driver and the application crashes.

Even in debug there is no callstack in the application which crashed, the only call stack is in the driver. Without access to debug symbols for the driver this problem seems unavoidable.

Any help would be greatly appreciated, thank you,
Brad

Hi Brad,

thanks for reporting the issue. To be able to analyze this, our OpenGL driver engineers would normally need the information from the checklist below to be able to file a bugreport.

The reproducer description needs to be complete and detailed enough for someone who’s not familiar with the application to reproduce the issue on a clean system.

If a reproducer is too big to be sent by e-mail, please let me know and I can setup a temporary FTP account to upload bigger data.

I can then forward the issue to our OpenGL driver team for investigation.

========================================
We normally need the following information to start analyses of bug reports.
(This is the general list and might not apply to all reports.)

  1. Operating system version.
    On Linux, an nvidia-bug-report.log generated by running nvidia-bug-report.sh as root.
  2. Graphics hardware.
  3. Graphics driver version.
  4. Display Control Panel settings for screen resolution, monitor configs, and driver settings.
    Under Windows: NVIDIA Control Panel -> Help -> System Information -> Save.
  5. Reproducer project.
    At least an executable which shows the problem. The simpler, the better.
    Make sure all necessary files to run this standalone are included (manifests, runtimes). Assume a clean test system!
    Source code in failing state highly appreciated.
    For GLSL compiler failures (C9999), the minimal set of shader sources reproducing the problem.
  6. Description of single steps to reproduce the problem.
  7. Description of the expected result (screenshots if possible).
    Performance issues require absolute measurement data and a description of how to reproduce them.
  8. If there is a crash in an NVIDIA module, the exact crash offset.

IMPORTANT: Our e-mail servers block ZIP attachments and executables. Please rename such extensions, replacing the last character of the extension with an underbar will do.

Thank you for the reply.

I am trying to recreate this problem in a simple delta3d application that will be straightforward to share and build if necessary. At the moment it is easiest to reproduce in a complex simulation environment.

I will prepare the other information you requested, I do have a few event traces of the problem as well.

Thanks again, I’ll be in touch.
Brad

Ok, well I have a modification to one of the delta3d example applications that will eventually cause the crash.

I am still gathering statistics on how often it happens, but it more or less requires gpu memory thrashing for about 1-3 hours. That is it essentially loads a map with around 500 MBs of GPU assets, deletes it all over 10 or 20 seconds and then starts over.

It will occasionally happen running the unmodified version of the demo, but it only creates the assets at startup so if it doesn’t happen when it starts up it seems to run indefinitely.

I am currently narrowing down which exact driver version the problem appears in and I will be putting together a submission for a bug report.

Thanks for the help,
Brad