While capturing, app crashes inside Nsight DLLs!

Developer Tools Nsight Visual Studio Edition
1

I’m trying to use Nsight to profile and optimize a project I’m working on, but I’m consistently getting a crash inside the Nsight DLLS that are intercepting the D3D11 API calls. Specifically, it’s crashing trying to unmap a buffer that is a staging resource that had data copied to it last frame. The data is being created by a compute shader. It’s very rare, but this same crash also seems to happen on other coworkers’ machines (who are just running the game normally, without Nsight), but not with any sort of consistency. I’ve run with D3D’s debug layer and it doesn’t report any API misuse, so I’m at a loss about how to fix this. If I comment out the buffer copy the crash goes away, but obviously so does the data it was calculating for me! :)

Here’s the call stack of the crash (function names removed as per NDA); the function at the very bottom is just calling ID3D11DeviceContext::Unmap() through our wrapper:

EXCEPTION_ACCESS_VIOLATION: Read of address 0x0000000000000378

Nvda.Graphics.Interception.dll!000007feec7830a0() 	[CreateNexusExperiment + 0xB100]
Nvda.Graphics.Interception.dll!000007feebda1a6c() 	[GraphicsInterceptionDummy + 0x1EBCBC]
Nvda.Graphics.Interception.dll!000007feebda15ab() 	[GraphicsInterceptionDummy + 0x1EB7FB]
Nvda.Graphics.Interception.dll!000007feebd9e4b5() 	[GraphicsInterceptionDummy + 0x1E8705]
Nvda.Graphics.Interception.dll!000007feebd50af3() 	[GraphicsInterceptionDummy + 0x19AD43]
Nvda.Graphics.Interception.dll!000007feebd43449() 	[GraphicsInterceptionDummy + 0x18D699]
****.exe!****::DeviceContext::UnmapBuffer(****::Buffer * pBuffer)

Interestingly, 0x378 is almost the exact size of the buffer I’m mapping!

Is there maybe some “gotcha” about the way I’m using the compute shader to fill the buffer and then how I’m copying it to the staging resource or something that can cause problems like this? I can go into more detail about what I’m doing if it would help.

Thanks!

  • Dylan
2

Hi Dylan,

We shouldn’t crash like that but the fact that it crashes similarly on another machine without Nsight seems to indicate that there may be something bad (outside of Nsight) going on here. Could you tell me the Nsight version, driver version and GPU that you are running this app on? What about your co-worker’s driver & GPU where you reproduced a similar crash?

Is there a way to get a binary that we can reproduce? Do you know if we have an NDA in place, having an NDA will make things easier, if you can PM me offline we can try to get things going.

Thanks

3

Thanks for the response, rafi! I believe the crash was due to some… suspect locking and atomic operations that I was previously doing in the compute shader; I’ve since changed the algorithm to no longer require a lock and I haven’t seen any crashes from anyone at the office since.

I submitted a support request with this information as well, but in case you don’t have access here’re the specs. Everyone here is using the same machine and driver (I am the only one who upgraded to 331.65, everyone else is using 327.23).

  • Windows 7 Professional 64-bit
  • Nsight Visual Studio Edition 3.2 (build 3.2.0.13289)
  • Driver 331.65 (version 327.23 also crashed)
  • Nvidia GeForce GTX 680

    • I’ll PM you with this information offline as well. Thanks again!

    • Dylan
    4

    Was there a resolution to this issue which didn’t involve a change in the shader? We are seeing the same crash and callstack with UnmapBuffer. The buffer is a staging buffer that we use to read back the results of a compute task.

    Windows 7 Enterprise
    Nsight 3.2.2.13351
    Driver 331.82
    GeForce GTX 570

    5

    Hi,

    Is there a way to get a binary from you that reproduces the issue?