locked
xperf fails to resolve symbols due to wrong registry entry RRS feed

  • Question

  • Hello,

    I'm profiling Windows 2008 server system (x64) to monitor performance of several drivers (some of which are not mine). After setting PATH and _NT_SYMBOL_PATH variables I run xperf (xperf -on latency+CSWITCH -stackwalk profile -BufferSize 1024 -MinBuffers 1024 -MaxBuffers 2048) for ~10 seconds, then open the ETL file in xperfview, click to Load Symbols and open the Summary Table. 

    All drivers except one have their symbols resolved and I can view the call stack, but there's one driver with all functions 'Unknown'. I looked it up in the system registry and strangely enough ImagePath for this driver is set up to '\device\harddisk0\partition1\...\' location. I realize that this is incorrect, I did try to change it to the correct path, where the driver and the corresponding pdb file reside, but when I change the registry the driver fails to work correctly with the rest of the system. Needless to say that this is one of the drivers that I don't own and can't really check where and why it breaks, when I chage the ImagePath.

    So my question is - is there a way to make xperf absolutely ignore whatever is written in the registry for a particular driver and instead always go with what's in _NT_SYMBOL_PATH? Thank you.

    Monday, May 21, 2012 12:42 PM

Answers

  • Ok, this is now solved. What needed to be changed was the ImagePath string in the registry. And it needed to be changed to a relative path to the driver, relative to SYSTEM_ROOT. After that the driver loaded OK and xperf was able to generate the ImageId for the driver and resolve its symbols.
    Tuesday, May 22, 2012 2:09 PM

All replies

  • Hello,

    we tried to investigate this further by dumping all the symbols from the ETL file and trying to make sense of what we saw (`xperf -symbols verbose dbghelp`). One thing that caught the attention was that in the whole ETL file there was no entry for ImageID for the driver whose symbols do not get resolved. What's insteresting is that if you read the cerr output for this same command, there's also no line for this driver where it says that symbol resolution failed (the "pdb not found" line). So this leaves us wondering if the lack of ImageID is somehow connected with xperf not even trying to resolve the symbols? And what would be the reasons for ImageID not being generated for this particular .sys file - I mean is it possible that we can work from these reasons and see what could be improved with this file location (pdb location, etc.) that the symbols finally get resolved. Thanks!

    Tuesday, May 22, 2012 11:38 AM
  • Ok, this is now solved. What needed to be changed was the ImagePath string in the registry. And it needed to be changed to a relative path to the driver, relative to SYSTEM_ROOT. After that the driver loaded OK and xperf was able to generate the ImageId for the driver and resolve its symbols.
    Tuesday, May 22, 2012 2:09 PM
  • H Anton,

    It would be great to get a copy of the "registry" path that anyone can understand in detail what does your solution mean.

    Thanks


    RPA

    Tuesday, May 22, 2012 5:52 PM
  • if this is a third party driver, deleted it 
    Friday, August 3, 2012 2:13 AM