locked
xperf fails to resolve symbols for one of my modules only RRS feed

  • Question

  • Hello,

    I have a moderately complicated software system implemented as a set of drivers that I need to profile. All of the .sys files have debug information and are stored in a specified location on disk C:. So I:

    1. specify _NT_SYMBOL_PATH accordingly (both my directories and windows debug info downloaded to the downstream storage);

    2. launch xperf (as `xperf -on latency -stackwalk profile`);

    3. collect and merge counters successfully (no events lost);

    4. open my ETL file in xperfview, check "Load Symbols" and then click on "Summary Table".

    As a result out of 5-7 of my modules being active and shown in the summary table as module.sys!function, there's ONE module displayed as ONE_module.sys!? - none of it's symbols get resolved.

    I read somewhere that sometimes it helps to substitute symsrv and dbghelp DLLs with the ones from Debugging Tools even though the two tools come in one package (SDK 7.1 for Windows 7, 64-bit). So did that - did not help.

    I decided to check that windbg can resolve the symbols of this particular driver, so I used Bang! to crash the system and analyzed the dump in windbg. `x ONE_module!*` listed the symbols I was looking for without any problems.

    Does anyone have an idea what I might be doing wrong/not doing in xperf? xperf does not seem to have an option to display troubles it ran into, while reading/resolving the data collected or does it?

    Thanks.


    anton
    Thursday, July 28, 2011 11:58 AM

All replies

  • Hi Anton,

    I can remember that I got a simular issue mounths ago.
    The first action was to download the current version 4.8. to get the whole W7 / 2008 support.

    Two idea's from my site --> based on my expirions with this nice tool (my opinion).

    1. Please have a look at your symbol configuration.
    I my case I separate the function with this one ";".
    and because of this, the xperf was not able to connect and load the symbol files.

    The second mistake from me was to add a wrong path to the importand "Symcache" folder. 

     

    Best regards

    Rainer

    Tuesday, August 23, 2011 10:05 PM
  • Rainer, thank you for the reply, it seems like I'm in much more trouble than you were a few months back. The version I'm running is 4.8.77something, it is the latest one. I checked and double checked the symbol paths configuration. The problem is not that xperf does not show any symbols, it does. It shows the correct symbols for the kernel and for 99% of the drivers I have in my system. The C:\SymCache directory has a bunch of .symcache files in it and a lot of them are for my drivers too, so we can safely assume that xperf was able to parse the _NT_SYMBOL_PATH and extract symbol information for those drivers. There's only ONE driver, which resides in the same directory as others too, which xperf seems to have no power over :) (it looks like it just skips it and goes ahead with the rest of the drivers I'm profiling). xperf is definitely a nice tool, but it's either missing a --verbose option to be able to tell me what is wrong with this particular PDB file or the --verbose is hidden so well that I can't find it...
    anton
    Wednesday, August 24, 2011 1:39 PM
  • Hi Anton,

    if your driver was provide from Micosoft you can expect theat you will get all public available symbol files. If the driver wasn't published from MS, may be difficult or impossible to get symbols for this.

    Two idea's around your specific issue:

    - Setup a new symcache folder
    - run the xperfviewer again and add the option for symbol cache
    - check the new symcache files
    - compare your results with the expected situation

    result A:
    You can't find any entry abourd you known driver --> so fare I know you can contact Microsoft (if you have a support contract) and ask for geting the specific symbols

    result B:
    You can find the expected file but the version don't match. --> I can remember that I had once this issue... I ask Microsoft and I got the information that I was using a special "hotfix" driver without published symbols. And I update this driver, use an published driver (from a higher service pack in my case) and I got it :).

    "kidding":
    You can try to use Procmon in parallel. And may be you can check what's wrong with the specific driver upload.

      

    Wednesday, August 24, 2011 6:51 PM