I'm trying to debug a C# application from a .DMP file and I have the executable, the DLLs and the PDBs all in a folder called "MyFolder." I set the directory containing the source code to C:\MyFolder\ but when I try to debug it tells me that:
"No symbols are loaded for any call stack frame. The source code cannot be displayed."
When I open the Symbol Load Information it states that the following PDBs could not be found:
C:\Windows\System32\kernel32.pdb: Cannot find or open the PDB file.
C:\MyFolder\kernel32.pdb: Cannot find or open the PDB file.
C:\MyFolder\symbols\dll\kernel32.pdb: Cannot find or open the PDB file.
C:\MyFolder\dll\kernel32.pdb: Cannot find or open the PDB file.
C:\MyFolder\kernel32.pdb: Cannot find or open the PDB file.
C:\Windows\symbols\dll\kernel32.pdb: Cannot find or open the PDB file.
C:\Windows\dll\kernel32.pdb: Cannot find or open the PDB file.
C:\Windows\kernel32.pdb: Cannot find or open the PDB file.
My PDBs are in the correct folder and they're timestamped with the exact same time and date. Does anybody know what's going on here? What's the proper way to load the symbols?
How do I verify my application's symbols are actually loaded (to eliminate them as the problem)?
I checked the Modules and it looks like all of the DLLs and the executable of my project are unable to load the symbols, specifically the symbol status is "No native symbols in symbol file"... when I right click on the item and I select "Load Symbols From -> Symbol Path" and I select the PDB C:\MyFolder\MyApplication.pdb then it tells me that "The symbol file for MyApplication.pdb does not match the module."
It sounds like the dump file is a native-code minidump, not a managed-code minidump, since the symbols for all those DLLs are usually not critical for managed debugging unless you debugging a mixed-mode app, debugging into Win32 calls or debugging across managed/unmanaged boundaries.
It depends on how the minidump was created. If it was on a different machine on a different operating system or service pack, then you may need the symbol path set up to get the exact PDBs of the system DLLs from the other machine, not your application assmeblies and symbols. Your managed debugging experience will improve if these unmanaged symbols are correct.
To further complicate things you have .NET "micro-versions" and native images to contend with to get the stack traces working.
You must ensure that:
Executables/DLLs and PDBs are of same build. PDB internally uses GUIDs to determine if associated EXE/DLLs are correct. Otherwise it won't load the symbols. It is not VS per se, but from DbgHelp.DLL.
Ensure you are having absolutely correct using set of source files. Even if "Source file must match" option is unset in VS Debugging options, VS doesn't care when loading .DMP files - it wont load the symbols if sources files don't match.
Related
My Visual Studio 2013 ASP.NET webform application has 3 DLL assemblies. When debugging, DLLs and PDBs are created in the same Temporary ASP.NET Files directory for only two of the three DLLs (the Project/VB module and a C# module. The third DLL is also a C# module, and the PDB is not being generated to the same directory as the DLL.
The symbols for that last problem module are not being found. When I attempt to load the symbol files manually selecting a PDB that was created on the same Date/Time as the DLL, I get the error "A matching symbol file was not found in this folder."
Why would PDBs be built in the DLL's directory for two modules and not for the third module? I've tried a variety of options on the Symbol Settings dialog, changing the Symbol file locations and cashe directory, cleaning and rebuilding the solution, and the results are not changed.
Did you check in the advanced build dialog (in your project properties(the one where the pdb is missing) and then, debug info : pdbonly or full ?
it must not be set to "none"
This problem was resolved. The C# module that was not producing a symbol file was an old copy of the DLL. Attempts to rebuild the module did not replace the old DLL.
All copies of that old DLL were deleted first and then the module was rebuilt. The next debug attempt showed a new DLL and PDB file were properly created.
I also suddenly got this error when I attempted to run a test after I made changes to the app.config of the test project. These changes turned out to be invalid.
I have read the questions that already on StackOverflow, but I still can't make it work.
I have
a mini dump file from a customer
the exact same version of our code that the customer has got
in the debug directory, .pdb files for the code.
I tried putting the mini dump file in the debug directory, then opening it in Visual Studio 2010.
I don't know if this was the correct thing to do, or what to do next.
"Start Debugging" is greyed out in the normal Debug menu.
There is a box with "Actions" in the top right hand corner of the Minidump File Summary tab. So I clicked on "Debug with Native Only" but all I get is "There is no source code available for the current location."
I must be missing something really simple - please can someone give me a hint?
Just to pull the various bits of information together into an answer:
Do you have .pdb files that were created when the program was built? Just rebuilding the same source doesn't work, you need to keep .pdb files for every build. – Alex Farber Feb 20 '13 at 11:05
"The debugger matches information like filename, timestamp and checksum when matching a PDB with a binary (DLL or exe)." (Saikat Sen, Codeproject article)
Following AlexFarber's hint, I copied the source code and release folder from the customer's build onto my computer (the whole build had been saved, including the .pdb and .exe files in the Release folder).
Then I copied the dump file into the release folder, and loaded the Microsoft symbols into the same folder.
Then I opened the dump file again into Visual Studio 2010.
I didn't see anything more helpful than before, which I assume is due to this - see the accepted answer on this SO question. I am using a C# and a .NET 2.0 assembly, and it seems that I can only view source code for a .NET 4.0 assembly.
I will try the WinDbg add-in called sos.dll recommended by Hans Passant on the same question next.
How to get round the need to use the pdb files from the same build:
I think you can get round this requirement for the same .pdb files if you use WinDbg. From virtualdub "If the debugger is stubborn and doesn't want to load symbols because it thinks they don't match, you can use .symopt+ 0x40 to set the "load anything" flag."
Also, if I understand correctly, you can use the chkmatch tool referred to by sergmat above, to match up the .exe and .pdb files.
As I understand it you have a minidump for a customer which I presume he is using a Release build of your application and a Debug PDB file.
That's your problem right there, Your PDB and the mini dump do not match. In order to view clear stack traces the PDB should have the same build configuration/platform as the one of the application that generated the dump file.
Using Visual Studio 2010 to remote debug a C# .dll -- getting .PDB file does not match - any yet it is absolutely the from the build...............
New info: [[ This problem is not resolved. I have three computers: a)XP sp3, b)XP sp3 and c)Vista sp1, I can build the simplest of test programs on a) and c), and using the module window -- select my test5.exe and load the .pdb that was created when it was created - same date same time same folder... and yet Visual Studio says "a matching symbol file was not found in this folder" -- all efforts to load the correct .pdb fail with not matching complaint.... be it: a) remote to b) or c) -or- c) remote to a) or b) --- HELP! ]]
I have set the location of the .PDB implicitly and explicitly - does not matter....
I have set the symbol settings to be unchecking that source files must match exactly....
I am seeing no Errs....
Just:
C:\POSWIN\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\Projects\SP\DBS.KGW.tst7STUB\DBS.KGW.tst7\obj\Debug\DBS.KGW.tst7.pdb: PDB does not match image.
C:\Projects\SP\DBS.KGW.tst7STUB\DBS.KGW.tst7\bin\Debug\symbols\DLL\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\Projects\SP\DBS.KGW.tst7STUB\DBS.KGW.tst7\bin\Debug\DLL\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\Projects\SP\DBS.KGW.tst7STUB\DBS.KGW.tst7\bin\Debug\DBS.KGW.tst7.pdb: PDB does not match image.
C:\Projects\SP\DBS.KGW.tst7STUB\DBS.KGW.tst7\bin\Debug\MicrosoftPublicSymbols\symbols\DLL\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\Projects\SP\DBS.KGW.tst7STUB\DBS.KGW.tst7\bin\Debug\MicrosoftPublicSymbols\DLL\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\Projects\SP\DBS.KGW.tst7STUB\DBS.KGW.tst7\bin\Debug\MicrosoftPublicSymbols\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\WINDOWS\symbols\DLL\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\WINDOWS\DLL\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
C:\WINDOWS\DBS.KGW.tst7.pdb: Cannot find or open the PDB file.
A couple of suggestions:
In visual studio, while you are attached to the process, open the modules debug window, Ctrl+D, M (or Debug -> Windows -> Modules from the menu) and find the dll that's causing issues. Right click it and select Load Symbols From and then Symbol Path locate the correct pdb file and see if it loads.
If you're app is asp.net, then you could try clearing the temp folder as it sometimes causes problems similar to yours. That folder should be located somewhere like this:
bootdrive:\%windir%\Microsoft.NET\Framework\v2.0.5 0727\Temporary ASP.NET
Depending on your .net version.
The solution is that for remote debug connections there are two ways to connect, authorized and unauthorized... For firewall issues, I defaulted to unauthorized. For VS 2010 C# solutions the complaint is merely the .PDB does not match. Having exhausted all options I could think of I went and reproduced my simple test solution in C++, the interface is different and better and there is a warning as you set this up that you will not get symbols unless you are on an authorized connection!!! -- Once I overcome the firewall issue -- and see my symbols via an authorized connection to the remote PC that is being debugged, I will post that confirmation...... btw, often it is warned that when you sign-on via an authorized connection the user ID and password for both the host and debugged computer must be the same, furthermore the user on the debugged computer must have "logon as service" right added to its user.....
I have got same problem and solution was so easy...
In my case, I have two VS solutions, first is main app with .exe and second .dll plugin project. When I tried to debug a dll project, I get a pdb not matching error (in module window). The reason was that pdb was actually not matching at all because:
When I was testing first solution, I copy .dll file from second solution to debug folder with .exe file.
Then when I tried to debug second (.dll) solution, it was using .exe file from first solution AND ALSO THE .dll file in that directory, but that .dll was outdated and didnt match with new pdb file. So copying a new .dll file from second project to .exe directory resolved my problem.
I have a project with multiple references to my own code in other dlls. One of the dlls loads its pdb file when I run the website, and the other doesn't.
From Output I see this:
LOTS_OF_TEXT\Shared.BusinessLayer.DLL'
LOTS_OF_TEXT\Shared.Visual.Utilities.DLL', Symbols loaded.
I double checked and they both have the corresponding pdb file in that "LOTS_OF_TEXT" location...but one of them loads the Symbols (and allows debugging) but the other doesn't.
Why? How do I get the Shared.BusinessLayer.DLL to load Symbols so I can debug it?
EDIT
For reference sake, I have Belvedere copying the pdb files to /AppData/Local/Temp/SymbolCache when they change...which is where my Debugging settings tell Visual Studio to look for Symbols.
Start a vsvars cmd prompt (or powershell) and browse to the LOTS_OF_TEXT folder. Visual studio ships with a tool called 'dumpbin.exe' that allows you to examine the structure of a .dll or .exe. To look for debug symbols, run dumpin in the cmd prompt by typing dumpbin /headers Shared.BusinessLayer.DLL and you should see the symbol path in the header information for the dll if it was actually built with symbols. As long as the symbols are there, or on the search path, they should be loaded.
That being said, check that visual studio is set to loading all symbols by going to Tools->Options->Debugging->Symbols and ensuring that the 'Automatically Load symbols for:' radio button is set on 'All modules, unless excluded' and that the exclusion list doesn't contain any relevant images.
A couple of months back I was running into an issue debugging a service I wrote remotely. I publish everything to the correct directory. Some how or the other, when I attempt to attach, the debugger tells me that I am missing a pdb file (not in so many words obviously). So what I do is, I go in and look a the missing modules. Look for the specific directory on my server, and just copy the pdb directly from the bin file to that directory. Does anybody know why I have to do that?
Thanks.
you don't get the pdb file if you build your dll or application in release mode of visual studio.try building the dll in debug mode you will get the pdb file.