I'm writing a library that compiles to a DLL which is ran by another C# app. I need some way to "see" some variables in my code. I don't have a console, and there's no way for me to output text to the other app.
I think I found before some program that would display all the Debug.WriteLine for all running porgrams... can't remember the name of it. Anyone know it? Or at least know some way for me to debug this?
If you compile your library in debug mode, it will generate a pdb file alongside with the dll. You can then step in through your methods calls in the dll if you have the pdb in the same folder. To do this you need to open the .cs files from your library and put a breakpoint on the code.
I do not know if I'm clear enough, but say solution A uses dll B. Make sure that where dll B is you also have a related pdb file. Then in VS just use the Open File from the menu to open the .cs file you need to debug in. If the debugging symbols have been loaded correctly from the pdb the breakpoint symbol will be full and you will be able to debug the code.
If your not already in a VS session, you can just start VS. Attach a debugging session to the process which is running yourt code, open the .cs code file(s) from the dll (again you will need the pdb file, and the pdb file will need to be in the same folder as the dll) and you can then put breakpoint in the code file.
Related
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.
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.
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.