I'm trying to remote debug my webpart. I can successfully attach to the remote process but my breakpoints do not load. Can anyone help me?
PS I've checked the "modules" but my assembly is not loaded there.
PPS My .dll is GAC deployed and I am the admin of both the dev and server.
PPS The .pdb files are on the bin folder of the application: inetpub/.../9090/bin
I was wondering if I can force the "modules" to load a given .dll. Is it?
Is debugging enabled in the web.config of the target web application?
http://msdn.microsoft.com/en-us/library/e8z01xdh%28v=vs.80%29.aspx
UPDATE
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
The section on PDB loading says:
The first place searched is the directory where the binary was loaded.
If the PDB file is not there, the
second place the debugger looks is the
hard coded build directory embedded in
the Debug Directories in the PE
file.If the PDB file is not in the
first two locations, and a Symbol
Server is set up for the on the
machine, the debugger looks in the
Symbol Server cache directory.
Finally, if the debugger does not find
the PDB file in the Symbol Server
cache directory, it looks in the
Symbol Server itself.
You need to move the PDB into the same folder in the GAC, or into the same path that you built the assembly from.
Use this method to enable viewing the GAC folders
http://blogs.msdn.com/b/johnwpowell/archive/2009/01/14/how-to-copy-an-assembly-from-the-gac.aspx
Related
I try to debug my product with a PDB file.
When the process is running, I am attaching the visual studio to the process, and then I am trying to load the relevant PDB File.
When I Right click on the DLL, and Load Symbols, i expect to get a File dialog to chose my PDB file, but for some reason, the visual studio found the PDB file in temp folder:
C:\Users..\AppData\Local\Temp\SymbolCache...
I tried to delete this folder, to remove all the folders from the symbols settings, but for some reason, it still detect the DLL on the temp folder.
Even if i try to load a different DLL, it create new folder inside the symbol cache, and it think that the PDB file is existing over there.
Offcurse that i am not able to put breakpoint because it dosent find the real PDB file...
Anyone have any idea how i change it so i will get the File Dialog to chose the right PDB file?
note: I am using Visual studio 2013.
Thanks for the help!
I'm having a problem where I have set the solution platform to x86, but the dll files at bin folder are loaded instead of bin/x86/debug. Whenever i want to debug a web application, I have to copy the dll files and pdb files from bin/x86/debug to bin folder to enable the debug mode. Otherwise, it will show
Breakpoint will not currently be hit. No symbols loaded for this
document.
I have been suffered from this issue since couple of weeks ago.
Check the build destination in the project properties.
I have a *.dmp (dump) file of my crashed application. Now, I want to analyze the crashed process on a different machine. That is, the app crashed on one machine, and I have Visual Studio on other machine.
Now, what do I need to be able to see stack trace and all symbols of my app? Is *.exe file and the *.dmp file sufficient?
Or do I need also the source code and PDB file?
If so, should the source code and executable file be placed in the same directories structure as it is on the machine the process was running?
How to attach PDB file to crash dump file in Visual Studio?
No, you definitely need the .pdb files to get decent stack traces. By far the simplest way is to do this from the machine on which you built the program, the source code and .pdb files will be in the right place.
Next best thing is to copy the exact same executables into the exact same folder in which it was installed on the failing machine. Copy the .pdb files into that same directory, that's where the debugger looks next if it can't find them in the original build location. Once the debugger lands on a statement with source code and the .pdb wasn't stripped then it will prompt you to give the source code file location.
Next best thing is Tools + Options, Debugging, Symbols and add the path to the directory that contains the .pdb files.
In that same dialog, also turn on the Microsoft Symbol Server (http://msdl.microsoft.com/download/symbols). That gets you the symbols for the Windows DLLs and lets you accurately trace back to your own code if the crash occurred in a Windows DLL.
I have read “What is the difference in TFS 2010 between a source server and symbol server?”
I have tried to set up my TFS build definition to generate source and symbol server.
Like this:
However, for me the result looks not like a proper symbol server.
When I open a crash dump, I still need to set symbol path to the correct drop folder where the dll’s (and also another .pdb ) reside.
In the selected “Path to publish Symbols” I see folders for the .pdb, but not for the .dll.
To be able to debug a dump I know that also the dll’s are needed.
Therefore I suspect my tfs to make only a source server, how can I then also have a symbol server.
TFS is only a Source Server. By specifying a shared path as your symbols store you setup for yourself a Symbols Server where Tfs Build publishes your projects' .pdb files to. The Symbols Server does not contain the binaries. The binaries should either be on the machine where you debug your application or from the build drop location.
In Resharper, there's an option to navigate to sources from symbol files. If I enable downloading, the navigation works - I can step into the code of Console.Writeline and so forth.
However, I have already downloaded the entire reference source - is there a way to direct Resharper to that source, so it doesn't download unnecessarily?
I've configured the reference source according to the instructions on the site
It's not possible at the moment. Please vote/watch http://youtrack.jetbrains.net/issue/RSRP-126489
I was able to get this working with Visual Studio 2015 RTM and ReSharper v9.1.3 (and Visual Studio 2013). This is what I did...
NOTE: This is quirky. I'm not sure why, but sometimes the downloaded symbols have source code info in them and sometimes they don't. I had to repeatedly delete symbols from my cache and try to get the appropriate ones by attached the debugger to apps/websites and go to the Tools->Options->Debugging->Symbols and clicking Load All Symbols. I also did some source-stepping, and I had to copy the PDB files from my Symbol Cache into directories in the GAC and in C:\Program Files (x86)\Reference Assemblies. Finally, I went to the properties of the Visual Studio project and add F:\dd to the list of Reference Paths. I'm now able to right-click Navigate to Sources to most classes.
Short version:
You have to use http://referencesource.microsoft.com/symbols as your symbol server instead of the default Microsoft Symbol Server
The symbols expect to find the Reference Source files in F:\dd.
Delete all cached symbols so it pulls them fresh from the newly added symbol server.
Long version:
Configure Visual Studio according to the instructions found on the official .NET Reference Source site.
Go to Visual Studio's Tools->Options->Debugging->Symbols, stop using Microsoft Symbol Servers and use the Reference Source Symbol Server (http://referencesource.microsoft.com/symbols) instead.
Delete all of your cached symbols! The PDBs in your cache do not have any information about the source code files. Visual Studio may have locked some of them, so you may have to close it first.
Download the zipped up Reference Source file for the .NET Framework version you're working with.
.NET v4.5.1
.NET v4.5.2
.NET v4.6
Here's the tricky part. The zip file you downloaded contains a folder called Source. The symbol files will expect that folder to be F:\dd. You can open up one of the PDBs retrieved from the new symbol server you added to see what I mean:
If you have an F:\ drive, it's easy: extract the Source folder from the zip file to F:\ and rename it to dd and you're good to go.
If you don't have an F:\ drive, you create an F:\ partition or load a virtual disk. I used a mapped network drive by extracting the Source folder into the shared folder C:\Code.
Then I mapped a network drive to \\MYPC\Code:
I didn't want to rename the folder to dd, so I named it ReferenceSource and created a directory junction using Command Prompt (must run as Administrator):
cd C:\Code
mklink /j dd C:\Code\ReferenceSource
Voila. Now I have an F:\ drive mapped to C:\Code and a junction dd that points to C:\Code\ReferenceSource.