A breakpoint could not be inserted

I have NSight running in visual studio 2017 (15.9.5). When I try to add a breakpoint into a frag shader I get a message in the status bar stating in “A breakpoint could not be inserted at this location”.

I’m running a Quadro M4000 which according to (https://developer.nvidia.com/nsight-visual-studio-edition-requirements) looks like it should be supported.

NVidia Driver version 411.63.

Unfortunately, Shader debugging is not supported on this Maxwell family GPU.
Please note the footnote on the page you referenced:
“[2] Shader debugging is supported on Kepler family GPUs for Direct3D 11 and OpenGL. Note that Kepler based GPU support and shader debugging has been deprecated and will be removed in an upcoming release.”

I swapped out the M4000 for a 1080 and got a different message - “The breakpoint will not currently be hit because the GPU is not supported.” Or something to that effect. I was able to add the breakpoint but it had the icon of a breakpoint that wont be hit.

So now I have a P1000 installed. I get a few more options in the HUD (and hitting SPACE to pause actually works now), but I still can’t add a breakpoint in the frag shader. Same error as on the M4000: “A breakpoint could not be inserted at this location”.

Hi Tom,

We looked into this a bit. Would you be able to post a screenshot of the error you are getting?

Also, Do you see the same results when using Nsight Graphics?


This is the error message in visual studio with the P1000: https://imgur.com/a/EPv0UdV

I don’t seem to be able to add a breakpoint in NSight Graphics. I’m trying to add them as I would in visual studio, is this correct? I fire up the linked shader source and click to the left of the line in question - nothing happens, no error message as far as I can tell… I may not be looking in the right place, and no breakpoint marker added.

I have the same issue with the P4000

This is the original error message: https://imgur.com/a/hBHZHHH

Hi Tom,

Thank you for sharing the error messages!

Sorry, I may have misled you a bit. I had forgotten that Shader Debugger had been removed from Nsight Graphics and is deprecated in Nsight Visual Studio.

I’m circling with the development team to see if there is a workaround for your issue. They may need more information including a copy of the application you are trying to debug. Is it possible to DM a link?

Sorry again for the thrash.


Hi Tom,

Additionally, I just reviewed the support matrix for shader debugger and it does mention Kepler GPUs.

1080/P1000 = Pascal
M4000 = Maxwell

So we are unfortunately in unsupported territory here. Let’s still see if we can get you a workaround though. :)



I tried a K4200 and saw the same error… But I see now that you’re saying the feature is completely deprecated in NSight Graphics and NSight Visual Studio edition.

You mention a workaround - what do you mean by this?

Unfortunately I wont be able to share the application without an NDA being signed, but it’s a fairly straight forward core 4.6 OpenGL application.


Unfortunately, the prognosis is not good. NSight GLSL shader debugging is VERY VERY brittle. No doubt NVidia is retiring this feature because the cost of supporting it across different architectures is prohibitive. This feature has become progressively more broken with each 5.x release and beyond. CUDA and Vulkan are NVidia’s focus; GLSL is not.

To date, I have only gotten it to work with the most basic of OpenGL samples. God help you if you’re using a GL toolkit of any kind. Some quirks I have noticed is that if you have a multi-GPU setup, even if one of your GPU’s is a Kepler card, you can’t set breakpoints unless you disable all other GPU devices (or physically remove them from the system). Also, the Visual Studio NSight plugin has a bug which took me months to puzzle out: namely, once you open a shader program you CAN NEVER CLOSE IT…doing so, will unload whatever binding the plugin has with the debugging engine. The only way to overcome this latter is to restart Visual Studio to reinitialize the plugin. Occasionally, I’ve had to purge the contents of %AppData%/Temp as well on the client. If your shader has a #line directive in it, it won’t work. If your shader program is compiled and loaded from a binary, you can’t debug/edit it either. Half the time I try to edit/compile a shader using DSE, NSight bombs out with an Internal Error. Bizarrely, Windows 7 and Windows 10 are supported but Windows 8/8.1 are not and sometimes you will need to run the target application in compatibility mode to have NSight not get angry. Multiple contexts? False. The list goes on and on. It truly is a house of cards. It’s just broken and it ain’t gettin’ fixed.

Unfortunately, we have regressed over the last decade where shader debugging is concerned (probably due to rapid advancements in pipeline architectures and processor design). There used to be 2 or 3 different open source solutions to shader debugging 5 or 6 years ago, but they’ve all dried up and died on the vine. NSight was the last bastion and its tower has also crumbled.

Your best avenue is to fallback to printf style debugging and using graphical methods to inspect the behavior of your shader. Also, NSight Graphics (standalone) is operationally superior and vastly more reliable than the VS plugin. You won’t be able to do step-wise shader debugging in that, however.