Shader Debugger just doesn't work -- all kinds of strange errors

Till now, after many trials with many graphics cards, the only thing Shader Debugger can do is spit out all kinds of strange errors.

Machine 1:

  • Windows 7 Professional, SP1, Build 7601

Machine 2:

  • Windows 10 Education, version 1803, Build 17134.48

Both machines:

  • Quadro K600
  • CUDA 9.1
  • Nsight 5.5
  • Visual Studio 2015 Update 3 version 14.0.25431.01

The code to be debugged is the first OpenGL example of the Red Book “OpenGL Programming Guide: The Official Guide to Learning OpenGL, Version 4.5 with SPIR-V (9th Edition)” with minor modification that should be irrelevant to the problem. I am debugging under remote mode and following instructions in the documentation regarding how to use Shader Debugger. On both machines, Nsight Monitor is run as Administrator.

If I use Machine 1 as host and Machine 2 as target, the error is that I cannot set the breakpoint. This is what I got after clicking the gutter of VS’s editor:

If I use Machine 2 as host and Machine 1 as target, the error changes to “Unable to launch because architecture type is Unknown. (System.InvalidOperationException)” at launch:

I was told that Shader Debugger works with Kepler cards. But the two Quadro K600’s are both Kepler, why are there still so many errors? How to fix? Is it true that only GK104 and GK106 can work with Shader Debugger? If so, under what version of Nsight and Windows? Looking forward to your help. Thank you.

PS: I didn’t impose any special configuration on the environment, so you can reproduce these errors without asking me for the OpenGL code (unless you insist).

Hello. Let me begin by affirming your broader presumption that GLSL shader debugging is very very brittle in its present state.

That said, I came across this exact error during one of my three dozen attempts to get the remote shader debugger to behave. If you right click on the target project, and select NSight User Settings, then select the Synchronization option on the left: uncheck “Synchronize files”. This will prevent Nsight from cloning the target executable folder to a temporary cache under %AppData% and will force it to run the code directly from the executable path you specified. It will also shorten your startup time.

I believe this “feature” was implemented to allow a host system to compile and build the target executable and then have itself and all of its supporting content copied across the network to a local folder relative to the target system. I just ended up mapping a common network share between both systems and skipped the copy and this error went away. Sadly, while I could get the graphical debugger to run, I was not successful in getting the shader debugger w/ breakpoints to work with any consistency via remote debugging (see my other thread in this forum).

Hope this helps.

J

Thank you for the reply. It gives me a good explanation of debugging a temporary cloned GLSL source instead of the original one. But I didn’t quite understand other parts of your reply.

  1. Are you only talking about the first configuration, i.e., using Machine 1 as host and Machine 2 as target?

  2. My understanding of the remote debugging is as follows. The client IDE sends a request to the remote Monitor (through port 8000 by default, right?). Then Monitor on the target runs the program to be debugged as requested. The execution of the program being debugged is controlled by Monitor through some inter-process communication mechanism (through port 8001 by default, right?). The debugging info like running status and variable values are requested and transmitted to Monitor, which are further returned to Visual Studio IDE on the host. Based on my understanding, if we don’t synchronize, how can the remote Monitor launch and debug the program? I tried disabling the synchronization, only to get errors like “Missing file on system”.

  3. So you think the culpret (of the first configuration) is setting a breakpoint to a source file which is actually not executed by the debugger, and this is further caused by incorrect synchronization configuration, right?

  4. I didn’t have problem in launching the Graphics Debugger in the first configuration. I encountered the error after the debugger had launched the OpenGL program successfully, not at launch time. The error is that the breakpoint I set does not work, not that the debugger fails to launch the OpenGL program (which is the error in the second remote debugging configuration).

I replaced the graphics card in Machine 2 with GeForce GTX 780 Ti today and the first debugging configuration works now (without any change of Nsight settings). But the “architecuture type is Unknow” error in the second configuration (use Machine 2 as host and Machine 1 as target) persists. I guess it may be because Quadro K600 is too old so Nsight discontinued support for it. Do you know what the matter is in the second config? Thank you.

My apologies. My response was referring to your second problem: “If I use Machine 2 as host and Machine 1 as target, the error changes to “Unable to launch because architecture type is Unknown. (System.InvalidOperationException)” at launch:”

Based on my understanding, if we don’t synchronize, how can the remote Monitor launch and debug the program?
I tried disabling the synchronization, only to get errors like “Missing file on system”.

If you’re using remote debugging and you disable synchronization then you MUST make sure the path to the executable you specify is visible/resolvable to both host and target machines. This is what I meant by mapping a common network share. For example:

If your target executable to debug is accessible via:

\server\volume1\dev\opengl\samples\spinnycube\spinnycube.exe

Then map a network share on both Machine 1 and 2 (let’s say Z:):

net use z: \server\volume1

…so that the path:

z:\dev\opengl\samples\spinnycube\spinnycube.exe

…references the same location on both machines. If you do this, no file copy will be required and you shouldn’t get that error.

The exception being reported is a .NET exception that is typically thrown when there’s a 32-bit/64-bit mismatch (i.e. launching a 64-bit process from a 32-bit app or visa-versa, or the executable doesn’t match the target platform). I don’t know what is causing the error to begin with. It’s nothing to do with your graphics card. Possibly a bug in the file replication process, a Windows permissions issue, Windows “SmartScreen” technology blocking an “unsafe” executable from running, etc. I didn’t bother to investigate since the above trick of mapping a common network share does the trick. You could try building a 32-bit version of your program and see if the problem resolves.

Hope that is more clear.