I am using WinDbg to load a crash dump from managed code (C#, a console application built for Any CPU), and a crash dump is created on a x64 platform. I am debugging on a x64 platform. I have put the related PDB file into the symbol path.
But WinDbg always find the symbol from a strange folder. Here is an example (when I got from using !sym noisy):
SYMSRV: c:\MySymbols\FooService.pdb\4311207E2E2D442CB7473828D2488F941\FooService.pdb not found
My application is called FooService.exe and the related PDB file is named FooService.pdb. I have set C:\MySymbols as the symbol path and copied FooService.pdb to the directory C:\MySymbols. But why does WinDbg not find FooService.pdb in C:\MySymbols, but from a strange sub-folder, "FooService.pdb\4311207E2E2D442CB7473828D2488F941"?
In my scenario, in order to load the PDB symbol file, what is the best solution (do I have to create the sub-folder FooService.pdb\4311207E2E2D442CB7473828D2488F941 by myself manually)?
I believe the strange part of the path is used for versioning the PDBs in the symbol cache. As the cache can be used for many applications including different versions of the same application the symbol downloader needs to do something to keep them apart.
You can force the symbol loader to disregard any cached copy by using the .reload /fo command. Combined with the .sympath option you should be able to set up loading. An easy way to add your local path to the symbol path is .sympath+ <PATH>. After that do a .reload /fo to disregard any previously cached PDBs.
EDIT: I changed my answer quiet a bit as I believe I initially misread your question. I hope this update is more useful.
Related
I have followed the directions and I created and loaded my symbols into my local Symbol Server path. I added the path C:\SymbolServer to the .pdb locations in VS.
I also disabled Just My Code and Enabled Source Server Support. However, everytime I debug my program and look at the modules window it says it loads from the default path where the project is located.(C:\Users\mcgeedm\documents..) and I want it to load from C:\SymbolServer. I am using VS 2012.
That behavior you are trying to get seems odd.
When you run an application from Visual Studio it automatically resolves the assembly and it's PDB files from the application directory. If it can't find it, it will try to load it from another location, which includes the symbol directory. That's just the way it works and should work in my opinion.
In a C# project, I create minidump at UnhandledException.
In my Dev machine, project source and bin are under path K:\projects\*MYPROJECT*, if I manage to let it crash in my Dev machine, everything work perfectly, I can open the minidump file and correctly see source code, callstack, threads etc.
End-user program path will obviously be different; as an example, in our Test machine project is installed under C:\*MYPROJECT*. It's deployed with pdb symbol files. Anyway, when I try to open the minidump, generated on that machine, on my Dev computer (where I have the source files), Visual Studio try to find the executable and pdb file under "Test Path" (C:\*MYPROJECT*) without of course find it.
I tried setting Symbol path to include K:\projects*MYPROJECT* without any result, so I recreated the same Test directory structure, creating C:\*MYPROJECT* and copying .exe and .pdb files under that directory. Now, Visual Studio is be able to find them, but it's saying "No native symbols in symbol file", and it doesn't let me see any source code.
How can I accomplish to load the correct Symbols?
To change the directory, Microsoft describes to open the immediate window and type .exepath [path] to change it.
You can also use .srcpath [path] and .sympath [path].
Finally came across a solution.
After weeks trying to figure out what I were missing, I've found that on my development machine I have a different Framework version (in details, I have v4.0.30319.18444 vs v4.0.30319.17929 on test machine). I still don't understand why I shouldn't be able to debug my application without having the exact Framework version, but the solution was to copy mscordacwks.dll and mscordbi.dll (both of them found in C:\Windows\Microsoft.NET\Framework) from the Test machine to the folder where the minidump is.
Reference:
Managed Minidump Debugging in SP1
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.
Its always recommended to store the PDB files for each public build so that we can debug if there is any issue on Production server.
My doubt is if my source code is changed even due to addition of two lines whether i will be able to debug when i run the program and try to attach it to my debugger?
In my understanding since PDB contains the line no. and local variable only,if the source code is changed we can't debug , so how its helpful unless we go back to original source which created the dll but if we know the source file then why we need the original pdb since we can replace it our local pdb.
I am sure i am missing something here..Will be glad if you clear this.
When using a symbol server with a source server, you should be able to debug binaries (or a dump from a customer) without requiring access to the source that produced the modules and symbols. It is tremendously helpful.
We update both servers for every build, which allows us to debug an application in a QA environment even if we do not have the source code on disk.
PDB files on their own isn't too helpful if the source that produced them is missing.
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.