1

I have been fighting tooth and nail with xperf to get symbols for a tool I'm profiling. My code that runs within the tool is split between the .exe and a .dll -- the important stuff to profile being in the .dll. I ran xperf:

xperf -on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE -stackwalk profile

And then I ran my tool for a bit, and then

xperf -d profile.etl

Then I tried xperfview. I loaded up the profile, toggled "load symbols" on, and opened the summary table. No symbols at all -- literally module came up "unknown" in the function column. I've scoured other threads on this and here's what I've tried:

  1. I set my environment variables, _NT_SYMBOL_PATH and _NT_SYMCACHE
  2. I cleared out my symbol cache and run xperf -symbols -i profile_results.etl.
  3. I copied over dbghelp.dll from a recent version of Windows Debugging Tools and repeated the above.

After doing all this I now get function names showing up properly for most of the modules that are not my own code, but I can't get my dll to show up. The dll is being compiled in release mode (with optimization) but I set the Visual Studio project specifically to create a pdb, I've verified that the pdb exists and that it is within a directory on my _NT_SYMBOL_PATH. Does anyone know how I can fix this, or at least debug it further?

Paul Eastlund
  • 6,713
  • 4
  • 18
  • 20
  • Do you have a solution for this problem? It seems it is all over the internet, but there is not guide how to fix this issue – Aleksei Poliakov May 20 '14 at 10:04
  • Sadly, no. I never got this working. I quit the job I was working on this for and joined a startup working on distributed backends in Python. It was glorious. Then we got acquired by Yahoo. Anyway, the issue remains unresolved. – Paul Eastlund Aug 29 '14 at 15:38

4 Answers4

2

You can set some environment variables to enable diagnostic logging during symbol loading:

  • DBGHELP_DBGOUT = 1
  • DBGHELP_LOG = C:\dbghelp.log
Luke
  • 11,211
  • 2
  • 27
  • 38
1

I just encountered the same problem... tried all the same steps... browsed all the (apparently) similar advice...

Additionally, I tried launching symchk using the same dbghelp.dll/symsrv.dll DLLs I had copied into my WPA 'bin' folder, to make sure that my PDB is locatable. (still thinking I'm going crazy...)

I should note: my _NT_SYMBOL_PATH value contained servers with lcl cache & straight up local locations: _NT_SYMBOL_PATH=srv*D:\SymbolCache*http://msdl.microsoft.com/download/symbols;D:\GitHub\....

Then it dawned on me that my DLL, used by my "partner" EXE, is loaded dynamically via LoadLibrary()/GetProcAddress() ... could this be an issue for XPerf ?????

I hesitated even trying this...

I added a useless export in my DLL, and I invoke it directly in the EXE (to trigger an Import Table entry for my DLL) So now the EXE depends on the DLL to even load.

Turns out...

.............then XPerf loaded all the symbols :).

Edit: I just found this URL on MSDN, where someone posted code back in '11 that demonstrates a similar (the same?) problem

EDIT:

I recently discussed this with a collegue, and learned that XPerf will properly "decide" to load symbols for DLLs loaded programmatically ... IF the DLL remains loaded until the termination of the process.

So, for DLLs that are Loaded and Unloaded during the execution, and are unloaded at termination... XPerf will skip the attempt to load those symbols.

CrashNeb
  • 394
  • 3
  • 12
0

Try using wpa instead of xperfview. It uses the same system for loading symbols that xperfview does but it also has a Diagnostic Console which lets you see symbol loading messages which can be helpful.

Also, you should tell us what you have _NT_SYMBOL_PATH set to. There are many ways that it can be incorrectly set.

Also, in _NT_SYMBOL_PATH you should specify a local cache for your PDB files -- you can then check there to see if your PDBs have been copied to the local cache.

You can also look in the SymCache Path (pointed to by _NT_SYMCACHE_PATH, defaults to c:\symcache) which is where the WPT .symcache files are stored. The PDB files are converted to this format and the .symcache files are what are ultimately loaded by WPA and xperfview.

For more information see:

http://randomascii.wordpress.com/2012/10/04/xperf-symbol-loading-pitfalls/

Bruce Dawson
  • 3,284
  • 29
  • 38
0

I'm not sure if this helps, but in here is one more detail I came across today in addition to the Q&A at xperf can't load my DLL's symbols:

For me, xperfview doesn't like PDB files on mapped network drives: as I was running xperf and xperfview on a different machine from where the code was built, I was getting both executables and PDB files off a network share, which I mapped to a drive letter to recreate exactly the same absolute paths as on the build machine - no luck. Even adding the folder with the PDB files to the symbol path didn't help.

Everything worked as expected once I made sure the .pdb file was in a local folder.

Community
  • 1
  • 1
Marcus Gröber
  • 11
  • 1