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.
Related
I am using C#.net for application development.
To log and debug exceptions, I use the stacktrace.
I executed my application on another machine, but when errors occur it refers to the path of my development machine.
Ex: D:\Projects\xyz.CS line no :12 _Error_message_here.
Why does it trace to the path on my development machine path even though I am running the application on another machine?
The original compiled path is stored in the debug information within the PDB files.
Because it's telling you where to find the problem in your source code. So when you see this, you can go to your machine and open the file reported (e.g. "D:\Projects\xyz.cs"), go to the reported line (e.g. 12) and fix the problem.
Explanation
When you do a Debug build, it includes source information in the compiled files to enable debugging, e.g. pause, step over, etc.
Solution
If you don't want the source information to be included perform a Release build and deploy that to the other machine.
same GitHub issue here.
the solution of
https://github.com/kerryjiang/WebSocket4Net
did generate two files
WebSocket4Net.dll
WebSocket4Net.pdb
but WebSocket4Net.dll didn't contain Debug Table.[checked with PE viewer].thus no pdb file location info is contained. thus vs debugger refuse to load the pdb. even manually.
The catch is;
the project is set to debug.
optimize is off.
output debug info is set to full.
Is there anything else need to be set?
Oh! I tricked myself.
I copied the dll and pdb to my project's output dir.
but every time the my project build. it would be overwritten by project's dll. thus I would see a dll without debug info.
Hope this would help someone. There's no other config needed. check the simplest assumptions that taken for granted.
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.
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.