I am developing a DLL using C# .NET 2.0 and Visual Studio 2008 Professional. I would like to debug (i.e. set a breakpoint in) it using Attach to Process and attaching it to the application's executable. I think this is working; at least, I'm not getting any error messages. However, any breakpoints that I try to set get disabled with a little warning message on them stating, "The breakpoint will not currently be hit. No symbols have been loaded for this document." Any thoughts on how I can get debugging with breakpoints working would be much appreciated. Unfortunately, I cannot simply run the application from VS because of the complex nature of its install process; I need to somehow attach the DLL to the installed executable (I can switch the file out, if need be) and debug with breakpoints. Thanks.
Make sure you have a debug version of the code you're trying to attach to. If it's a release version with no pdb files you will get the error you're describing. Also make sure you have have the correct type selected in the "Attach to" selector. The selector should be set to Automatic or Managed.
Enjoy!
If you are sure you have a debug build and the source code matches the build you are attaching to, then check your Debug - Windows - Modules window, and check all the locations for the assemblies you are debugging, their versions, and pdb locations. This will help you narrow down the issue.
Related
I have one solution in VS 2017 pro, where i am unable to attach process and debug properly.
For start, even though my application is loading/running properly, visual studio attach to process screen always shows 0 Sessions against that app-pool/application.
If i then select it, it never hits any of the C# code (weird).
I manage to hit some razor view cshtml files to be debugged, but never the c# code
any ideas?
My first question if you have started process/service. Then build code do you get error message that exe is already in use?
If not then you are not sure about the correct code.
If then aleast run against your code alomst for sure.
If that not solve your problem. We need to see where you have installed and how to service. Also what the code for the service looks like. It help see where you have your first breakpoint in the code.
Usually if it not reaching the breakpoint or the code is grayed out. It is because the binary is not found or it does not match the code. T
The service you are trying to debug are it installed in your building directory so you are sure is lastes version?
I'm getting the subject error for breakpoints set on a vs 2010 website project.
When I view the modules window under Debug-->Windows-->Modules I see that it cannot find or open the PDB file for WebDev.WebHost40.dll -- it skips loading symbols for all other dlls. I tried to fix this by using Tools-->Options-->Debugging-->Symbols and checking Microsoft Symbol Servers, this fixed the cannot load symbols message in the module window, but it still wont debug and gives the same error message. I've also tried deleting the temp Visual Studio files, rebuilt the project, closed and re-opened visual studio, and also rebooted machine. Any other suggestions? Has my project perhaps been corrupted and I start fresh with a new project?
Thanks
A few things to check - in Visual studio - right click the project and go to the build tab. Make sure you are running under debug mode. Also check the debugging settings and target platform are OK. There are also adanced build settings worth checking in this tab. You mention that the pdb file isnt being created? If it is, try deleting it and then it will be recreated by VS. If it isn't there is something wrong with the build settings. I would try some changes in the build tab to see what works.
Try creating a brand new solution, if you can debug that then there's something wrong with one of your projects. You then need to work out what's different between the working project and the broken one.
If you can't debug a new project either, then at least you know it's not your project, and time to reinstall VS (boo).
I'm trying to debug an application built in Visual Studio C# under MonoDevelop in Linux.
I have the source code, so I followed instructions that appears at Icaza's blog at http://tirania.org/blog/archive/2010/Feb-20.html without success (which basically consists on create an empty solution and set the Execute command to the already compiled application)
The application is executing correctly but when I load the source code file, and set a breakpoint, it never stops.
pdb's were also transformed to mdb's using pdb2mdb command.
What am I missing?
BTW, load source code into Monodevelop and build the application under Linux is not an option right now, due to the big size of the application and lots of tweaks in the build process. Just wanted to debug the compiled assembly.
There is a command line utility for soft debugger, have a look it, this might be what you are looking for.
I have problem with debugging SolidWorks Enterprise PDM addin. I don't know how the addins are handled within EPDM, but the problem seems to be related with Visual Studio - maybe someone else has similar problem with other platform's addins.
Adding a debug addin (so that latest source is used):
In Visual Studio 2010 Express there's no problem - kill explorer, start it, attach to it and:
I couldn't achieve the same with Visual Studio 2012 Express. Although it seems that it is debugging explorer (files are read-only, stop debug button is shown), it doesn't hit breakpoints:
I work on Windows 7 Professional x64. Addins are built with .NET 3.5. I've used both VS2010 and VS2012 solutions with the same problem.
I do restart explorer.exe, so the latest version of addin is loaded. Project uses start action "explorer.exe":
<StartAction>Program</StartAction>
<StartProgram>$(windir)\explorer.exe</StartProgram>
<StartArguments></StartArguments>
I don't know why the breakpoints are not hit, any help much appreciated.
Thanks!
UPDATE 1
I've checked what Hans suggested - there are two other processes starting, but attaching to them didn't result in anything.
That pointed out one more thing - when I was attaching to those processes there was an information within VisualStudio, that the breakpoints will not be hit, because no debug symbols were loaded - notice that in the third image attached the debug symbols are loaded (the red circle is filled and without the exclamation mark).
UPDATE 2
When I attached VisualStudio to the managed explorer.exe - the breakpoints were hit!
It seems that explorer.exe is running in Managed mode only sometimes:
It can even be running in both modes side by side:
So the question is how to force VisualStudio starting explorer.exe in managed mode?
UPDATE 3
Is it possibly a VisualStudio 2012 bug?
When debugging with VS2010 the explorer is started in normal mode, but as soon as the addin is loaded, it is switched to managed mode and VS2010 stops at the breakpoints.
With VS2012 it is different - when the addin is loaded, explorer.exe is not switched to managed mode and (therefore? is it connected?) breakpoints are not hit.
But when VS2012 is attached to the explorer.exe that already is in managed mode, it stops at breakpoints.
UPDATE 4
I've managed to reach the essence of the problem - when attaching VS2012 to another process (e.g. explorer.exe) with "Automatically determine the type of code to debug" selected" and the process is started in native mode and some time later loads managed code - the debugger doesn't stop at the breakpoints. When the process is already in managed mode when attaching to or when attaching to with code type(s) explicitly selected ("Managed (v3.5, v3.0, v2.0)") - the debugger stops at the breakpoints.
Already posted on connect - awaiting solution. Please vote if you experience the same problem as described in this update.
UPDATE 5
I've just tested it on a simple managed shell extension so it is not SolidWorks Enterprise PDM - related.
I've also posted a more precise bug on connect.
UPDATE 6
As of the beginning of 2013 Microsoft claims that it is a design decision that the debugger is not behaving as expected. More details in the first connect bug report.
When you're building a .dll (I assume this way it's loaded into explorer) breakpoints had always problems (at least in my experience), because you have no way of knowing in advance where file will be loaded in memory, therefore it's hard to add a breakpoint.
You may try to add manual breakpoint invocation inside your code (which is int3). In C++ this would be:
asm {
int 3;
}
In C# there's a method for that:
System.Diagnostics.Debugger.Break()
Try to adding to the beginning of your function/code part (don't forget co compile in debug mode).
Then you'll just start debugging application (.exe) which loads .dll file and loaded library should trigger a break point.
I am debugging a windows application in visual studio 2010, the application was developed and upgraded from .net framework v2 and VS 2005.
Originally, windows forms could be open on debugging mode. However, several times later without editing (as I was just tracking possible bugs before fixing), those forms become unable to open. Whenever, I tracked the bugs until the code which shows the form, then the debugger will just stop tracking without any messages. Does anyone know what problems could cause this situation? Thanks a lot.
Usually if you are unable to debug step into code then this usually indicates that there is no debug information available due to missing source and/or a missing debug .pdb file for that item.
Check the build configuration to ensure that you are attempting to debug a debug build, it is easy with solutions containing multiple projects to accidentally set the configuration manager to build a project in release mode, whilst the project that you're stepping from is in debug mode.
Also in multi-project solutions check that you are referencing the project and not the project output where required, otherwise setting the configuration manager to build a project in debug mode will have no effect if you're referencing a release build output for that project.
If the Winforms reside in a third party DLL then ensure that you have referenced a debug version of the library before attempting to debug.