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
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.
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.
I've been using a library in my code base for a while now, and I wanted to debug right into the library level. To do that, I downloaded the source code and included the project as an existing project into my C# solution. I then had my other projects reference that project instead of the downloaded .DLL.
Once the project was referenced instead of the DLL, I ran my solution through the debugger and tried to step into a function call that would have called into the external project, but it stepped right over it. While debugging, I opened up the "Modules" window and saw that the DLL's Symbol Status read "PDB does not match image", which is the likely cause of not being able to debug this project.
My question is simple, why does the PDB not match the image if my project is directly referencing the .csproj file as a reference? There should never be any ambiguity as to what version to run.
I've run into this issue before when I have another project open that also references the DLL and uses its debug info (PDB). Basically the other project puts a file lock on the PDB in the referenced project and when you compile or debug the referenced project, it quietly fails to generate an up-to-date PDB file.
If this is what is going on, make sure you have no other apps running or instances of VS open that reference your DLL, and then seek out and delete all copies of the PDB from beneath the BIN and OBJ folders, then recompile it.
I hope that helps.
Sometimes it happens because you might have build the project as a release.
Right click on the solution and click on "Batch Build" > Check all your projects and click "Clean"
For me this happened for an Excel Add-In. I went to the modules window to see why it wasn't loading for my dll. I looked at the folder where the .dll was located and went to that location. There was an .ini file in that location. Opening it revealed the install location of my application, which turned out to be in "C:\Program Files\" as opposed to the bin\debug location of my project.
Basically I had an old version of the add-in already installed that was getting loaded up upon me trying to debug the project. I uninstalled the old project, deleted the old .dll location in "C:\Users[user]\AppData\Local\assembly\etc..." and voila, the debugger loaded up the newly compiled dll.
Faced same issue, it was due to old assembly and latest PDB. There was mismatch between both.
The assembly was built properly, but again my post build dll copy script was overwriting it with older one.
Removing the dll from post build script resolved issue.
Need to ensure that dll or pdb are up to date when debugging finally commences.
This happened to me today while I was trying to debug notepad++ dll plugin , I had to change build output directory to notepad++'s plugins directory and set the Debugger to launch notepad++ instead of the current project dll to proceed with set breakpoint. This had me nuts as Visual Studio 2019 was telling me that SYMBOLS were not loaded for the plugin dll which I was trying to debug.
Finally checking the modified date and time as others here suggested, made me realize the pdb was not up to date with the the build output dll timestamp. I tried rebuilding the solution but the pdb generated has same older timestamp though I delete them manually and initiate build. So all I had to do was to make a change in the source code by deleting a white space and rebuild. Voila! this time I got the debugger to load the symbols for my dll automatically and hit the set breakpoint.
Maybe cleaning the solution also might have worked.
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.