GLSL Remote Shader Debugging in VS2017 + NSight 5.5 = Fail

Hello.

Remote shader debugging in NSight 5.5 under Visual Studio 2017 appears to be fundamentally broken. It is unknown if the problem exists in other editions of Visual Studio.

The target system is running a GT 730 (Kepler), NSight 5.5, with the recommended 388.59 drivers under Windows 8.1 Professional.

The host system is running Windows 10 Professional 1803, Visual Studio 2017 15.7.2, and NSight 5.5.

Similar to the many other reports in this forum, debugging a simple GLSL shader from an OpenGL sample application is proving highly problematic in this configuration. These are the symptoms:

On the first invocation, after Pause+Frame Capture and selection of a draw call in the Scrubber, I am able to open any of the linked vertex or fragment shader from the API Inspector just fine. On the first (and only the first) invocation, I CAN set a breakpoint in the shader program. However, after this point, I am unable to set any other breakpoints in ANY shader again for this application (including setting the same breakpoint in the same shader I set the first time) . Even after a full capture resume and pause, I cannot set a breakpoint. In fact, even after stopping the target application and restarting it anew, I cannot set a breakpoint.

This behavior is unique to remote debugging (and possibly VS2017). When debugging locally on the target system using Visual Studio 2013, I do not experience these issues. On the host system, I have tried both hardware and replay debugging and changing the debugging level from Full|Limited|Minimal with no success.

Other symptoms include: in the case where I have been able to set that initial breakpoint, resuming execution in a remote debugging context, will sometimes result in a 0x80004005 error and a message that the program cannot be resumed. Frequently, Visual Studio 2017 will also crash and restart after resuming execution from a breakpoint or resuming from a frame capture. Adding conditions to a shader BP will also occasionally crash VS.

One observation worth noting: in the the case where the breakpoint CAN be set, Visual Studio displays a popup on the host system about “loading project information” when the shader program is first opened and there is a noteable delay as something is communicated between the remote system and the target. In subsequent runs of the application, I do not see this popup nor do I see any delay. It’s almost “as-if” NSight is using cached/stale information at the remote debugger end and never attempts to establish a debug hook into the target application.

I’ve tried numerous configurations in an effort to get this to work to no avail. I can only conclude that GLSL remote shader debugging just isn’t working anymore and must rely on VNC to the target machine and debugging locally in Visual Studio 2013. Please make shoring up shader debugging in NSight v.Next a priority (including support for any of the last THREE generations of GPU’s).

Thank you.