breakpoint will not currently be hit, why not?

Question

Sometimes I get the message that the breakpoint will not be hit, and no symbols will be loaded.

The red icon in vs.net changes color, and the debug mode just doesn't work.

what is the reason for this?

Answer 1

You may be running your project in Release mode. If so, then switch to Debug mode

Answer 2

1. for manage code only - theres a good answer for this problem on the following site: http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
2. for native + managed code - in the startup solution properties-> Debug tab make sure that "enable unmanaged code debugging" check box is checked

Answer 3

Do each bullet in the link below ONE AT A TIME, but repeat my steps below with each one you try.

http://web.archive.org/web/20140212130754/http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.) Stop debugging (press red square icon) in Visual Studio
2.) Clean Solution
3.) Build Solution
4.) [INSERT BULLET INSTRUCTION HERE]
5.) Tools > Attach to Process (or start with debugging)
6.) Start the program that you're attaching to, and run it such that your code will get hit

6 explained:

If attaching to nunit.exe, then open NUnit and run a test so your breakpoint will be hit

If attaching to w3wp.exe (IIS site), then open your site in the browser and go to the page that will hit your breakpoint

Answer 4

After trying several suggested fixes for this I did the following to get it working.

1. Right Clicked my Project in the Solution Explorer and selected "Properties".
2. Went to the "Web" section and made sure "Start Action" was set to "Current Page".

Spent 3 1/2 hours on that... I'm going to go get a drink now.

Answer 5

Next to the "Debug/Release" dropdown list, there is another one with "Any CPU/Configuration Manager...". Click "Configuration Manager...", and you will see some of your projects might be in Release mode. Change all of them to Debug.

Answer 6

This can happen if the symbol fiels are different from the assembly (remote debugging), or when there is no "direct path", so the assembly hasent been load, but might be loaded using reflection and loading of the required assembly at run time.

Answer 7

This can also happen if the debugger is not attached to the process for whatever reason. If it's the case, you can always go to Debug - Attach to Process... and choose the right process. Your breakpoints should return to normal once VS determines it can hit them.

Answer 8

I resolved this problem by selecting Automatic:Native Code for the "Attach to" field in "Attach To Process" form

Answer 9

What does it say when you hover the mouse over the disabled breakpoint? It will usually tell you the problem. My favorite is the old 'source code is out of date', especially when I'm debugging a DLL. Another favorite is when the file you're looking at isn't the one you're debugging (a copy in another folder?). If it's a case where you can breakpoint a caller routine, but not the callee, stepping into the callee will force VS to open the 'proper' source file and you'll be able to set breakpoints. Confusing, I usually swear at VS at this point, it seems to help.

Answer 10

I do not like to play with knives but the only thing that worked for me involved editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.

Answer 11

I had the same problem. Which I know is normally if the build versions are different, and something isn't matching up. I cleaned my project, rebuilt it, and then deployed and that got everything back in-sync.

Answer 12

I have tested with both deployed application and service, what I have found out that If the deployed code is different than a code in visual studio then breakpoint will not hit. Even small changes will affect and the breakpoint will not hit. So, It is better to debug the same version which is there on vs code and also in deploy application or service.