Nsight Graphics GPU Trace crashes after fresh Windows install

Hello.

After updating Windows from 22H2 to 24H2 by reinstalling it, Nsight Graphics crashes when attempting to collect GPU Trace:

Reason:    Unhandled C++ Exception
Address:   0x7ff880ab9f0a
Assertion: Unknown assertion type 0x00000000

Thread 0 (crashed)
 [0]  KERNELBASE.dll + 0xc9f0a
 [1]  VCRUNTIME140.dll + 0x5637
 [2]  KERNELBASE.dll + 0xc9f0a
 [3]  WarpVizPlugin.dll + 0xa23560
 [4]  VCRUNTIME140.dll + 0x192e0
 [5]  VCRUNTIME140_1.dll + 0x32c1
 [6]  VCRUNTIME140_1.dll + 0x2621
 [7]  TPSConnectionPlugin.dll + 0x1758f0
 [8]  ntdll.dll + 0x806e0
 [9]  TPSConnectionPlugin.dll + 0x1758f0
 [10]  VCRUNTIME140_1.dll + 0x2490
 [11]  ntdll.dll + 0x126c56
 [12]  TPSConnectionPlugin.dll + 0x17ef28
 [13]  TPSConnectionPlugin.dll + 0x77659

Thread 1
 <no frames> 
Thread 2
 <no frames> 
Thread 3
 <no frames> 
Thread 4
 <no frames> 
Thread 5
 <no frames> 
Thread 6
 <no frames> 
Thread 7
 <no frames> 
Thread 8
 <no frames> 
Thread 9
 <no frames> 
Thread 10
 <no frames> 
Thread 11
 <no frames> 
Thread 12
 <no frames> 
Thread 13
 <no frames> 
Thread 14
 <no frames> 
Thread 15
 <no frames> 
Thread 16
 <no frames> 
Thread 17
 <no frames> 
Thread 18
 <no frames> 
Thread 19
 <no frames> 
Thread 20
 <no frames> 
Thread 21
 <no frames> 
Thread 22
 <no frames> 
Thread 23
 <no frames> 
Thread 24
 <no frames> 
Thread 25
 <no frames> 
Thread 26
 <no frames> 
Thread 27
 <no frames> 

Minidump is attached. (33.3 KB)
This happens with any OpenGL/Vulkan app (haven’t tried DX12). Attached crash message is the result of attempting a GPU Trace on vkcube.exe.
Older versions(2024.2 - 2025.2) do not crash, but they get stuck on “Preparing data for transfer…”.
2024.1.1 works without any issues.

GPU: RTX 3060 12GB
OS: Windows 11 Pro 24H2
Driver: Game Ready 576.52
Nsight: 2025.3.0

The minidump is not one of the target application, but of the ngfx-ui host.
Can you upload one for the stacktrace you show?

Hello, AMAMODE!
Sure, here is the minidump of vkcube and crash info related to it.

Reason:    Unhandled C++ Exception
Address:   0x7ffa7dff85ea
Assertion: Unknown assertion type 0x00000000

Thread 0 (crashed)
 [0]  KERNELBASE.dll + 0xc85ea
 [1]  VCRUNTIME140.dll + 0x5637
 [2]  KERNELBASE.dll + 0xc85ea
 [3]  WarpVizPlugin.dll + 0xa23560
 [4]  VCRUNTIME140.dll + 0x192e0
 [5]  VCRUNTIME140_1.dll + 0x32c1
 [6]  VCRUNTIME140_1.dll + 0x2621
 [7]  TPSConnectionPlugin.dll + 0x1758f0
 [8]  TPSConnectionPlugin.dll + 0x1758f0
 [9]  VCRUNTIME140_1.dll + 0x2490
 [10]  ntdll.dll + 0x126606
 [11]  TPSConnectionPlugin.dll + 0x17ef28
 [12]  TPSConnectionPlugin.dll + 0x77659

Thread 1
 <no frames> 
Thread 2
 <no frames> 
Thread 3
 <no frames> 
Thread 4
 <no frames> 
Thread 5
 <no frames> 
Thread 6
 <no frames> 
Thread 7
 <no frames> 
Thread 8
 <no frames> 
Thread 9
 <no frames> 
Thread 10
 <no frames> 
Thread 11
 <no frames> 
Thread 12
 <no frames> 
Thread 13
 <no frames> 
Thread 14
 <no frames> 
Thread 15
 <no frames> 
Thread 16
 <no frames> 
Thread 17
 <no frames> 
Thread 18
 <no frames> 
Thread 19
 <no frames> 
Thread 20
 <no frames> 
Thread 21
 <no frames> 
Thread 22
 <no frames> 
Thread 23
 <no frames> 
Thread 24
 <no frames> 
Thread 25
 <no frames> 
Thread 26
 <no frames> 
Thread 27
 <no frames> 
Thread 28
 <no frames> 

Thanks. The target is just waiting for the ngfx-ui at that point - nothing helpful there. The ngfx-ui crash dump itself doesn’t match with your stack trace, however. It looks like it was generated at a point where we catch the exception, rather than where it was thrown, we’ve lost the context of the crash at that point. I’m not sure how the dump was generated, but if you can attach a debugger to ngfx-ui and generate a dump at the time of the crash that would be helpful.

Sure.
ngfx-ui.zip (26.1 KB)

Thanks again. However, that dump doesn’t look like it’s at the time of the crash. Everything looks more or less idle.

Sorry if I did something wrong, I’ve never generated dumps before. Visual Studio does not catch the exception automatically, so I “stepped into”, until the crash window popped up, then generated the minidump.

Hi lipesto,

I don’t mean to interrupt, but I just had a sudden thought. I noticed the TPSConnectionPlugin.dll in the call stack, and since you reinstalled Windows, maybe it’s worth checking the firewall settings? It might not make a difference, but it’s definitely worth a look.

Thanks
An

Hello AYan, thank you for your reply!
All rules for ngfx-ui.exe and vkcube.exe allow connections. Also, disabling the firewall does not make any difference.

Visual Studio does not catch the exception automatically, so I “stepped into”, until the crash window popped up, then generated the minidump.

By the time the window pops up, we’ve lost the context. You need to attach a debugger and set it to “break when thrown”.

Hello, here is what I believe is a minidump with the same call stack Nsight Crash Reporter displays
ngfx-ui.dmp.zip (31.1 KB)