So I am on Arch Linux and the libraries from the official repositories do not ship with debug symbols. To work around this in most debugging tools, one can use DEBUGINFOD_URLS=https://debuginfod.archlinux.org as an environment variable (e.g. DEBUGINFOD_URLS=https://debuginfod.archlinux.org valgrind ./myApp). I tried adding that environment variable both before launching nsys-ui and in the "Environment variables" section of "Collect CPU IP/backtrace samples", but both do not seem to add any debug symbols for system libraries.
Therefore I end up with loads of unresolved symbols as can be seen in the "Top-Down View".
As can be seen here there is a "Symbol locations..." option but that only allows adding local paths.
Is it possible to add the debug symbols via a debug info URL in Nsight Systems?
Specs: Nsight Systems 2022.4.2
Specifically for Linux, it is not currently possible to resolve symbols from symbol servers.
Answering the question more broadly, symbol resolution from servers is available for Windows.
You can also refer to Symbol Resolution at the Nsight Systems Documentation for more information.
To request features for Nsight Systems, please send feedback via the GUI (Help -> Send Feedback), or create a post at the appropriate forum category, https://forums.developer.nvidia.com/c/development-tools/nsight-systems.
Related
Process Explorer (aka procexp) require debug symbols to show kernel memory limits and a library that provide API for reading them. As I found, the symbols for currently running kernel (ntoskrln*) only are required, and the variables MmSizeOfPagedPoolInBytes and MmSizeOfNonPagedPoolInBytes are read from it. It is possible to acquire them from the kernel directly.
So why the debug symbols are required? Do they contain some information that impossible to get from the OS itself?
Because Process Explorer needs to know where in kernel memory those variables are located and it can different between each version of windows so symbols are the correct way to get this location. Microsoft publish public symbols.
not all kernel information is easily access from User space.
My scenario is I'm supporting a VB6 app at the place I work and in the last few weeks it has started crashing more often than it ever used to. It uses both a local Access MDB database and a remote SQL Server DB for different types of storage. The good news is we are writing a replacement app, the band news I need to support this one in the meantime and the vendor is long gone from this world.
What are some ways I could try and diagnose what is causing the crash? For example so far I've tried ODBC tracing (For the MDB component), SQL Profiler tracing and ProcMon on a client PC.
Is there anything else I could try to discover what the app was trying to do at the time of the crash?
You can also start in a debugger.
windbg or ntsd (ntsd is a console program and maybe installed). Both are also from Debugging Tools For Windows.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
Use db address (as in db 01244 to see what's at that memory.
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than seperate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
I don't even care if they are true "debug" versions, all I really want are the symbol files so that my callstack isn't rendered invalid when I break into the debugger.
AMD now publishes symbols for their drivers:
http://gpuopen.com/amd-driver-symbol-server/
NVIDIA published them as well (announcement) under the following URL:
https://driver-symbols.nvidia.com/
It is just binaries, not PDBs of course.
I am trying to debug a minidump crash dump. How can I get to know the OS so that I may download related Microsoft Symbols?
I am using Visual studio and windbg.
The dump contains enough information so that the symbol server client will load download and use the symbols that match the executable and dlls.
I.e. define environment variable _NT_SYMBOL_PATH to something like:
symsrv*symsrv.dll*h:\Symbols*http://referencesource.microsoft.com/symbols*http://msdl.microsoft.com/download/symbols
where h:\symbols is a writeable folder. The debugging tools will do the rest.
Note:
You need to do it this way because patches, including service packs, also change the version of the symbols.
The first download location is used for .NET with source server, if not working with .NET that can be removed.
vertarget will tell you the target machine of the minidump.
I haven't seen that syntax for the MS symbol server before, I usually just do:
.symfix h:\symbols
.reload
From within the debugging session. It automatically sets your symbol search path to point to the symbol server so you don't have to worry about remembering the path.
-scott
I'm compiling a vc8 C++ project in a WinXp VmWare session. It's a hell of a lot slower than gcc3.2 in a RedHat VmWare session, so I'm looking at Task Manager. It's saying a very large percentage of my compile process is spent in the kernel. That doesn't sounds right to me.
Is there an equivalent of strace for Win32? At least something which will give me an overview of which kernel functions are being called. There might be something that stands out as being the culprit.
Windows Resource Kit contains a tool called kernrate. It's a sampling profiler. It can profile entire system or a particular process. By default, its resolution is on a module level, but can be tuned down to several bytes. You should be fine with default resolution as you'll see which modules/drivers are consuming most of the time.
Here is some info regarding its use.
Not exactly strace, but there is a way of getting visibility into the kernel call stack, and by sampling it at times of high CPU usage, you can usually estimate what's using up all the time.
Install Process Explorer and make sure you configure it with symbol server support. You can do this by:
Installing WinDebug to get an updated dbghelp.dll
Set Process Explorer to use this version of dbghelp.dll by setting the path in the Options | Configure Symbols menu of Process Explorer.
Also in the same dialog, set the symbols path such that it includes the MS symbol server and a local cache.
Here's an example value for the symbol path:
SRV*C:\symbolcache*http://msdl.microsoft.com/download/symbols
(You can set _NT_SYMBOL_PATH environment variable to the same value to have the debugging tools use the same symbol server and cache path.) This path will cause dbghelp.dll to download symbols to local disk when asked for symbols for a module that doesn't have symbols locally.
After having set up Process Explorer like this, you can then get a process's properties, go to the threads tab, and double-click on the busiest thread. This will cause Process Explorer to temporarily hook into the process and scan the thread's stack, and then go and look up the symbols for the various return addresses on the stack. The return addresses's symbols, and the module names (for non-MS third-party drivers) should give you a strong clue as to where your CPU time is being spent.
VmWare support should be address that question. It's probably somewhere in the VmWare implementation.
You can use for example IrpTracker that give you an idea what is going on in the kernel.
Another option is using kernel debugger i.e WinDbg. If the cpu load very high just randomly breaking in the debugger and looking on the call stack can give you an idea who is the driver behind the cpu load. But as i stated i will guess that it will be some VmWare component. It worth to check if the problem persist on same computer on WinXP without emulation.