none
Automatic download of debug symbols by CLR when _NT_SYMBOL_PATH is defined? RRS feed

  • Question

  • Hello, I'm an end-user facing a peculiar problem with a 3rd-party .NET program: when the environment variable _NT_SYMBOL_PATH is defined, this program attempts to connect to Microsoft's public symbol server msdl.microsoft.com and download symbol files for all system components it loads.

    As I have no way of changing this program, the work-around is simply not to define that variable in the environment. I am simply interested if any of the .NET experts here can shed light on why this is happening.

    I discuss the details of the problem on Lenovo's public forums at http://forums.lenovo.com/t5/ThinkVantage-Technologies/Fingerprint-Logon-Delay/m-p/219819#M10445

    A quote (the full thread has all the other details I refer to):

    1) After upgrading the Lenovo factory Vista Business image to Windows 7 and installing all the Windows 7 Lenovo programs, I installed other programs, one of which repeatedly crashed. I wanted to get some idea of what was causing the crash, so I installed Microsoft's "Debugging Tools for Windows" and set the environmental variable _NT_SYMBOL_PATH=srv*c:\mysymbols*http://msdl.microsoft.com/download/symbols to download and cache the debug information for Windows 7 system executable files.

     

    2) It was a while before I noticed that the authentication UI application for the fingerprint reader was taking around a minute to display after being started, whether at the logon screen or via the FPApp.exe program that is used to collect the fingerprint while a user is logged on.

     

    3) I searched the support site of lenovo and found the link referred to in my first post, but the suggested solution did not work. connections

     

    4) Eventually I noticed--when I was looking up the Internet sites that the FPApp.exe was making connections to when starting--that Microsoft's symbol server at msdl.microsoft.com seemed to share an IP number with crl.microsoft.com, Microsoft's PKI server.

     

    5) So I experimented by removing the symbol path environmental variable I had set from the environment in which FPApp.exe and other fingerprint program components will start up in. Bingo! The start-up time reduced to 10-15 seconds maximum, which is normal.

     

    6) What I noticed just a day or two ago, is that the delay with the environment variable present is largely due to the system fetching all of the debug symbol modules for the Microsoft system components that FPApp.exe uses, 117 MB worth, 100 .pdb files, and cacheing them in the local path specified in the symbol path environment variable (this takes about 3 minutes). And every subsequent invocation of FPApp.exe checks these symbol files (which takes roughly a minute).

     

    7) So something is very funny in the configuration of FPApp.exe and friends: the presence of a symbol path in the environment should never normally lead to fetching debug symbols, except when the executable is run under a debugging program. I just don't know enough to diagnose the problem.
    No Signature Yet
    Saturday, April 3, 2010 8:49 PM

Answers

  • One obvious solution is (as you mentioned) not setting _NT_SYMBOL_PATH machine-wide. I personally set it only in command windows where I use windbg.

    If you are interested in finding out what happened, then:
    1) Confirm that FPApp.exe is managed application.
    2) Attach debugger when it takes too long and get several call stacks - that way you will find out which component is downloading the PDBs.
    Alternatively you can use sampling profiler on the application and compare 2 profiles where one takes long and second is fast. Again you should see where the time is spent most in the "long" run from the callstacks.
    3) Contact FPApp.exe support and ask them.

    I think that you will likely find that it is FPApp.exe's fault. That it uses either some debugging API (e.g. PDB reader/writer), or downloads the PDBs explicitly. In such case I don't think that you will be able to do anything about that anyway, except contact their support and ask them for a fix.

    -Karel

    • Marked as answer by SamAgain Friday, April 16, 2010 7:44 AM
    Saturday, April 3, 2010 9:42 PM
    Moderator
  • Because you are using Windows 7 , you can use XPERF and ETW to get call stacks for actual issue and where in the code is . Here is an MSDN article on this and to use ETW to get managed call-stack  I wrote a some post on this

    Hope this helps.

    Thanks Naveen http://naveensrinivasan.com
    • Marked as answer by SamAgain Friday, April 16, 2010 7:44 AM
    • Marked as answer by SamAgain Friday, April 16, 2010 7:44 AM
    Wednesday, April 7, 2010 12:27 AM

All replies

  • One obvious solution is (as you mentioned) not setting _NT_SYMBOL_PATH machine-wide. I personally set it only in command windows where I use windbg.

    If you are interested in finding out what happened, then:
    1) Confirm that FPApp.exe is managed application.
    2) Attach debugger when it takes too long and get several call stacks - that way you will find out which component is downloading the PDBs.
    Alternatively you can use sampling profiler on the application and compare 2 profiles where one takes long and second is fast. Again you should see where the time is spent most in the "long" run from the callstacks.
    3) Contact FPApp.exe support and ask them.

    I think that you will likely find that it is FPApp.exe's fault. That it uses either some debugging API (e.g. PDB reader/writer), or downloads the PDBs explicitly. In such case I don't think that you will be able to do anything about that anyway, except contact their support and ask them for a fix.

    -Karel

    • Marked as answer by SamAgain Friday, April 16, 2010 7:44 AM
    Saturday, April 3, 2010 9:42 PM
    Moderator
  • Because you are using Windows 7 , you can use XPERF and ETW to get call stacks for actual issue and where in the code is . Here is an MSDN article on this and to use ETW to get managed call-stack  I wrote a some post on this

    Hope this helps.

    Thanks Naveen http://naveensrinivasan.com
    • Marked as answer by SamAgain Friday, April 16, 2010 7:44 AM
    • Marked as answer by SamAgain Friday, April 16, 2010 7:44 AM
    Wednesday, April 7, 2010 12:27 AM