Call stack missing in Nsight Visual Studio Edition 6.0 due to wrong module paths

We tried to set up Nsight Visual Studio Edition 6.0 for OpenGL profiling, which is partially working, but we cannot get the stack trace to work. We have the exact same issue as described in this thread two years ago, i.e., the call stack of an API call only shows the module name, but no function name, file name, or line numbers. In the Modules view, all modules have a wrong path in that the paths point to the D:\ drive, although all participating software, code base, and libraries reside on C:.

Our configuration:

  • Windows 8.1 Pro 64 bit, version 6.3.9600

  • Visual Studio Enterprise 2017, version 15.8.7

  • Nsight Visual Studio Edition 6.0.0.18260

  • Windows installation and code base resides on C:, but the machine also has a D:\ drive

  • Code base is written in C++17, using a 64-bit Release build with debug info

  • Graphics to debug comply to the OpenGL 4.5 core profile

  • Nsight Monitor is started as administrator

  • Visual Studio is started as administrator

  • No Task Manager or Process Monitor running

  • No changes to the default settings in VS | Nsight | Options | Analysis (i.e., “Using symbol server”, no Symbol Cache or Server Paths)

  • No changes to the Nsight Monitor options

  • Activity Type: Trace Application

  • Trace Settings:

    • checked System
      • checked CPU Thread Trace
      • checked Module Trace
    • checked OpenGL
      • checked API Trace, API Categories: All Categories, Call Stack Trace: Always
      • Workload Trace: checked all
  • No changes to Advanced Options

After capturing, the report does not include any symbols and the call stack for API calls only shows the module names, but not function, file name, or line, as already reported by user vdontsov in the thread linked above. Of course, it cannot find any symbols if it searches on the wrong disk for them.

I also tried deleting C:\Users***\AppData\Roaming\NVIDIA Corporation\Nsight, which did not change anything.

Could you please tell us how to set this up properly?

Here are two images to illustrate the problem.

The Modules view with wrong drive letter (the Windows installation is on C:)

The OpenGL API Calls view with no function names in the call stack

Thanks for the feedback, we are looking into this issue (DTCOMP-2413)

I have this exact same problem: wrong drive in Modules view (C: instead of D:), and no function, file and line information.
I’m using Nsight Visual Studio Edition 6.0 (fully updated) for CUDA.

Workaround is to provide a symlink, like this:

c:
cd \
mklink /D sources d:\sources

Is there a way to view progress of DTCOMP-2413?

We are still looking in the issue why the modules get directed to the wrong drive. (DTCOMP-2413)

In the meantime we want to provide two additional ways to resolve the symbol despite the wrong path.

  1. If you already have the corresponding .pdb on disk,
    • You can use the small action button on the left side of each row in the module page to manually resolve the debug information for this module.
    • A file dialog will pop up asking you to provide the path to the matching .pdb file.
    • Once loaded, the debug information for this module will be resolved.
    • We also automatically attempt to resolve all other modules with the same path mapping - to avoid having to repeat this operation multiple times for the modules in the report.
  2. Alternatively, you can also instruct Nsight VSE to automatically look for matching debug information on a symbol server.
    • The options for that are available at Nsight > Options > Analysis > Symbol Management.
    • For example, to automatically resolve Windows system files,
      • you set your Symbol Cache Path to

        and your Symbol Server Path to

      • In doing so, upon loading the report the modules are resolved using the specified symbol server.