none
debugging and PDB file not quite right?

    Question

  • Hi there,

    This is the first time I've really played with this beyond stepping into the .net framework code (and asp.net code - stuff from the MS symbol server/source server) so be gentle please.

    I've been mucking around with various 3rd party (mostly nuget) things, but many of the modules I use are either poorly (or not as thoroughly as I need) documented and so I'd like to step into some of the code to see what's going on in a few situations.

    I'm not sure what the optimal workflow is but I searched for and downloaded a couple of tools ilspy and dotpeek, but I seem to be having the same problem with both/either.

    a) problem 1 is that PDB that is loading (even when I use dotpeeks "symbol server" function) seems to be the one in ASP.NET Temp folder... I've tried deleting all the temp files but it just goes again to (for example):

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\vs\d873c2ef\6d1debef\assembly\dl3\3b4cf985\7c555959_95a4d101\some.dll

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\vs\d873c2ef\6d1debef\assembly\dl3\3b4cf985\7c555959_95a4d101\some.pdb

    *I* feel this should be the PDB that the decompiler creates, not the one in this temp directory (where the source is also created), but it may cache these things immediately... Is this expected behaviour? is there a way to clear the "memory" of this on the local machine?

    In VS2015 (we use 2005/2008/2012 for various things) the "source search information" drop down shows something like this (done with common.logging):

    Locating source for 'c:\_oss\common-logging\src\Common.Logging.Portable\Logging\Factory\AbstractLogger.cs'. (No checksum.)
    The file 'c:\_oss\common-logging\src\Common.Logging.Portable\Logging\Factory\AbstractLogger.cs' does not exist.
    Looking in script documents for 'c:\_oss\common-logging\src\Common.Logging.Portable\Logging\Factory\AbstractLogger.cs'...
    Looking in the projects for 'c:\_oss\common-logging\src\Common.Logging.Portable\Logging\Factory\AbstractLogger.cs'.
    The file was not found in a project.
    Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src\'...
    Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src\vccorlib\'...
    Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\src\mfc\'...
    Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\src\atl\'...
    Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include'...
    Looking in directory 'C:\Downloads\'...
    Looking in directory 'D:\dev\decompile\Common.Logging\'...
    The debug source files settings for the active solution indicate that the debugger will not ask the user to find the file: c:\_oss\common-logging\src\Common.Logging.Portable\Logging\Factory\AbstractLogger.cs.
    The debugger could not locate the source file 'c:\_oss\common-logging\src\Common.Logging.Portable\Logging\Factory\AbstractLogger.cs'.

    I feel like there must be some kind of cache of some kind for this stuff that can be cleared/controlled somehow - as I'm sure I put in the D:\dev\decompile\... paths, but 1) I dunno how, and 2) I don't know how to control it/clear it/redirect it short of deleting the stuff I've manually directed to and trying again...

    b) even with these PDB files being loaded it often tells me that "someclassfile.cs not found" and wants me to browse to find it or show the disassembly... I thought that enabling "enable source server support" but this probably only works for Microsoft stuff that the source server "controls" - not sure if dotpeek or other tools are also supposed to decompile and "manage" the source for you...

    Does anyone have insight/experience into this stuff that they might set me on the right track for exploring this stuff?

    Any help appreciated.

    Thanks in advance


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Saturday, May 7, 2016 12:03 PM

Answers

  • Hi noJedi,

    As far as I know the ASP.NET is different from general apps, ASP.NET has the dynamic compilation.

    It seems that it would copy the dll file and pdf file to the temp path for the ASP.NET.

    Reference:

    http://serverfault.com/questions/89632/iis-copying-dll-and-pdb-files-in-temp-directory

    http://forums.asp.net/t/1600268.aspx?ASP+net+copies+my+dll+and+pdb+files+inconsitantly+to+temp+folders

    Like this thread:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/2e10bf24-6803-4af4-a6db-21e1c23d3a3d/pdb-missing-from-temporary-aspnet-files-when-debugging-on-remote-webserver?forum=vsdebug

    No PDB file in the temp folder which generated the debugger error, we also could know that it really has this feature (save the dll and pdb file to that folder in default for the ASP.NET app).

    Like this document here:

    https://msdn.microsoft.com/en-us/library/ms241613.aspx

    Where the debugger searches for .pdb files:

    1.The location that is specified inside the DLL or the executable file.

    (By default, if you have built a DLL or an executable file on your computer, the linker places the full path and file name of the associated .pdb file inside the DLL or the executable file. The debugger first checks to see if the symbol file exists in the location that is specified inside the DLL or the executable file. This is helpful, because you always have symbols available for code that you have compiled on your computer.)


    2..pdb files that could be present in the same folder as the DLL or executable file.


    3.Any local symbol cache folders.


    4.Any network, internet, or local symbol servers and locations that are specified on, such as the Microsoft symbol server if enabled.

    If it was not listed in the above options, we would add custom symbols folder and launch them automatically under TOOLS->Options->Debugger->Symbols.

    >>is there some way to manually direct to the correct PDB/decompiled things...

    But if you want to add it manually, we often use the module window, but we have to find it by ourselves. 

    https://msdn.microsoft.com/en-us/library/x54fht41(v=vs.100).aspx

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, May 10, 2016 10:28 AM
    Moderator
  • thanks jack,

    all this is (probably) correct... however after much stuffing around, I ended up reinstalling VS2015 and MANUALLY cleaning all the bin/obj folders from my project (as well as some additional custom build output directories) and then rebuilding the project and its now working as I expected it to... not sure what the root cause was, but at least I can continue working on this project withability to step into some things properly and see what's going on!


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Wednesday, May 18, 2016 11:31 AM

All replies

  • Hi noJedi,

    >>*I* feel this should be the PDB that the decompiler creates, not the one in this temp directory (where the source is also created), but it may cache these things immediately... Is this expected behaviour? is there a way to clear the "memory" of this on the local machine?

    As far as I know that the PDB file would be related to the symbols loaded under TOOLS->Options->Debugging->Symbols. For example, it would download the symbols from Microsoft symbol Servers to a local cache folder.

    But if the symbols files are local or third party files, it would search them in your project folder or you could add them manually.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, May 9, 2016 10:34 AM
    Moderator
  • Yep, that looks correct to me.

    However when I open Modules (Debug >windows >modules - Ctl+alt+U) I can see that the PDB is actually the one from the %windir%\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files directory, and NOT the symbol cache...

    This is what I would EXPECT to see, but am not... any ideas why?

    and for MOST I am seeing this path (presumably for all the thigns that come from the Microsoft Symbol Server) but for a handful of others the SymbolFile is not (guessing they aren't on the MS server)...

    but then why when I decompile can I not seem to get it to MANUALLY go to the location I decompiled to?

    if the "locateme.cs" dialog comes up I can point it to the correct SOURCE file, however the PDB in the "temp" folder must be different because I get "code has changed" dialog, and if you say "yes" then the code and the step through/breakpoints don't line up.

    is there some way to manually direct to the correct PDB/decompiled things...

    do I just decompile TO the "local/temp/symbolcache"?? (sounds very fragile!?)


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Monday, May 9, 2016 3:17 PM
  • Hi noJedi,

    As far as I know the ASP.NET is different from general apps, ASP.NET has the dynamic compilation.

    It seems that it would copy the dll file and pdf file to the temp path for the ASP.NET.

    Reference:

    http://serverfault.com/questions/89632/iis-copying-dll-and-pdb-files-in-temp-directory

    http://forums.asp.net/t/1600268.aspx?ASP+net+copies+my+dll+and+pdb+files+inconsitantly+to+temp+folders

    Like this thread:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/2e10bf24-6803-4af4-a6db-21e1c23d3a3d/pdb-missing-from-temporary-aspnet-files-when-debugging-on-remote-webserver?forum=vsdebug

    No PDB file in the temp folder which generated the debugger error, we also could know that it really has this feature (save the dll and pdb file to that folder in default for the ASP.NET app).

    Like this document here:

    https://msdn.microsoft.com/en-us/library/ms241613.aspx

    Where the debugger searches for .pdb files:

    1.The location that is specified inside the DLL or the executable file.

    (By default, if you have built a DLL or an executable file on your computer, the linker places the full path and file name of the associated .pdb file inside the DLL or the executable file. The debugger first checks to see if the symbol file exists in the location that is specified inside the DLL or the executable file. This is helpful, because you always have symbols available for code that you have compiled on your computer.)


    2..pdb files that could be present in the same folder as the DLL or executable file.


    3.Any local symbol cache folders.


    4.Any network, internet, or local symbol servers and locations that are specified on, such as the Microsoft symbol server if enabled.

    If it was not listed in the above options, we would add custom symbols folder and launch them automatically under TOOLS->Options->Debugger->Symbols.

    >>is there some way to manually direct to the correct PDB/decompiled things...

    But if you want to add it manually, we often use the module window, but we have to find it by ourselves. 

    https://msdn.microsoft.com/en-us/library/x54fht41(v=vs.100).aspx

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, May 10, 2016 10:28 AM
    Moderator
  • thanks jack,

    all this is (probably) correct... however after much stuffing around, I ended up reinstalling VS2015 and MANUALLY cleaning all the bin/obj folders from my project (as well as some additional custom build output directories) and then rebuilding the project and its now working as I expected it to... not sure what the root cause was, but at least I can continue working on this project withability to step into some things properly and see what's going on!


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Wednesday, May 18, 2016 11:31 AM
  • Hi noJed,

    Glad to know that this issue has been resolved, if so, would you please mark helpful replies as the answers? So it would be helpful for other members who meet the same issue, and I could close this case for you.

    Sincerely,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, May 18, 2016 11:45 AM
    Moderator