xperf can't load my DLL's symbols

Question

I'm trying to use xperf to profile my DLL, but it refuses to use my DLL's PDB file. Running xperf on the .etl with -symbols, I get:

DBGHELP: mydll- private symbols & lines
         C:\mydll\debugu\mydll.pdb - unmatched

Which leads me to believe it thinks my PDB doesn't match the DLL the application is using. This is wrong; it does match. I've confirmed the path of the DLL the application is linking with using procexp, completely rebuilt the project, and so on. It still thinks it doesn't match.

Any ideas on what could be wrong?

Answer 1

Try setting a SYSTEM environment variable _NT_SYMBOL_PATH to point to your .pdb file _NT_SYMCACHE_PATH to point to c:\Symbols. See the docs on XPerf symbol handling at http://msdn.microsoft.com/en-us/library/ff191023(VS.85).aspx

There is also a good blog article titled "Under the covers with XPerf" on WindowsItPro dot com that covers symbol handing in XPerf.

Note that I needed to set a system environment variable with the correct values, setting the environment in a batch file was not picked up by xperfview (check Trace, Configure Symbol Path menu option immediately after starting XPerfView)

Answer 2

Sorry, I asked this question and forgot about it.

There were actually two problems.

The first is that xperf was actually using an older cached version of my symbols. This was fixed by deleting it from the symbol cache.

The second was that when I loaded symbols in xperfview, it didn't actually put my up-to-date pdb into the symbols cache. The pdb was in a directory that I confirmed was included in the _NT_SYMBOL_PATH variable, however. Unfortunately, I don't remember the exact command used to fix this, but I believe it was an 'xperf file.etl -symbols' variant. This command correctly parsed the etl and loaded/cached all of the relevant symbols as it encountered them. After this, xperfview could correctly show my symbols.

Note that I had to re-run the command any time my pdb changed, because xperfview still wouldn't touch anything that wasn't already in the symbol cache. I'm still not sure why it behaves this way on my machine, other people don't seem to have this problem.

Answer 3

I just posted an answer to a similar question on SO that could be related to the problem experienced here...

Basically, if the DLL is dynamically loaded, it can cause trouble for XPerf with regard to symbol loading.

Personally, I am guessing it is about logic within XPerf deciding whether to even try to load symbols for a given module. e.g. "load all EXE's and their IAT entries" (which would skip all dynamic DLL's - which doesn't appear to be the case, but something similar is going on)

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.