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.
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.
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
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'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.
I need to generate a list of all the files which are enough to run my application on any machine. I need this for a setup program. When i go to bin/release folder i'm able to see some pdb files and some configuration files, which i think will not be needed. I tried to disable generation of pdb files too but it still generates pdb for the other projects present in the solution.
So i need a way in visual studio 2008, which can get me all the files (the .exe and .dll and other files) required by my application to run.
Thanks.
Have you tried publishing the application (Build > Publish [app])?
This should just copy all the essential files to the specified folder.
The pdb files are used for debugging. Building in "Release" mode should exclude these files.
You can also create a setup project within the solution. Using that project it is possible to see a list of included files.
If you make a release build or publish the application then you should have a complete set of assemblies your application needs.
However, it can still rely on assemblies which reside in the GAC (Global Assembly Cache) of your machine. Check the references of your project if you think there are assemblies missing in the bin folder.
To solve this exact problem with our software, we wrote a simple console app that finds all the .vbproj & .csproj files in our projects directory, then changes all of the to Release mode (which does not create pdb files, documentation files etc).
This is then run by the build machine (CruiseControl.Net) before it starts compiling the projects.