I can’t get the NSight Debugger to work at all in Visual Studio 2022 using .NET 6. I get the same exception for all of my projects.
The minimal example is:
I’ve tried creating a blank Hello World Console app, and running it from “Start Cuda Debugging (Next-Gen)”
If I set the target framework to “net48”, the program runs fine.
If I set the target framework to “net6.0”, I get the following error:
Unhandled exception at 0x00007FFC4BAF4B2C (KernelBase.dll) in HelloWorld.dll: 0xE0434352 (parameters: 0xFFFFFFFF80070002, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00007FFC25300000).
I have the Cuda ToolKit 12.2 installed.
Can you clarify what the application is doing? Is this a .NET app that has a native (CUDA) C++ component? And the only change is the target framework? Can you debug both framework versions with the built-in VS Debugger? It’s strange that the target framework would impact the CUDA debugger.
The original application is a .NET 6 application that uses GitHub - clSharp/Cloo to load a .ptx to perform some calculations. When trying to run with the Cuda Debugger, I would get the above exception.
I wasn’t sure if there was something wrong with my application, so I tried creating a new one, but even before I made any modifications to the “HelloWorld” template app in Visual Studio, the Cuda Debugger gave the same error when targetting .NET core (.net 6). The regular visual studio Debugger works fine for both.
I’ve had trouble finding good documentation for what is supported by NSight for Visual Studio. Is .NET (framework or core) supported at all?
There are substantial changes under the hood between the .net 4.8 (.net framework, which is endo of lifed) and .net 6 (.net core, which is a complete rewrite of .net) so it’s not entirely suprising that the behavoir is different between the two.
I have the same issue here. Is there a timeframe when .NET6/7 frameworks are supported ?
The issue is that this project type builds a .dll. Even though there is an .exe next to it, the Visual Studio project APIs indicate that the .dll is the build output, and that is what the Nsight debugger uses to determine what to debug.
For now there is an easy workaround, go to the Nsight User Properties, select
Launch external program, give it the full path to the .exe that is next to the .dll. Launch the Nsight debugger, now the external program setting will take precedence.