50

I'm trying to debug a large ASP.NET application.

I set a breakpoint on the first line in Page_Load in Default.aspx.cs.

When I start the application, my breakpoint briefly turns into a red round outline with an exclamation in it, then turns back into a regular breakpoint, then the application starts without ever stopping at my breakpoint.

MSDN tells me that this symbol means "the breakpoint location has not been loaded". So how can I get the breakpoint location to load? It was working a couple weeks ago. What kinds of things could cause a breakpoint to "not be loaded"?

What can I do so that the debugger stops at my breakpoints again?

Addendum:

I still can't get debugging to work by pressing F5, but I can start the website, then do debug/attach-process to get into debugging mode. If anyone knows why this would work but when I press F5 it would not work (the debugging buttons don't even show up on F5), any ideas would be welcome.

Improve this question
1
  • In my case, the same ASP.NET app runs on several domains and uses the domain from the request to choose the content to serve. It is set to run on local IIS and via the hosts file, the domains are resolved to 127.0.0.1. The app ran OK, but the debugger did not stop on breakpoints till I set project properties > Web > Server > Project Url to the domain used to make the request. (It contained another domain that the app is available under.)
    – Palec
    Commented Jun 19, 2018 at 8:58

17 Answers 17

Reset to default
55

Try doing a full rebuild on the application. Pay attention that it's in the "Debug" configuration.

As far as I understand (but I'm not an expert in these things), this can happen when the debug info files (.PDB) are out of sync with the real compiled thing.

Improve this answer
6
  • I deleted all the .pdb files in the ../debug/bin, but that didn't help.
    – Edward Tanguay
    Commented May 13, 2009 at 8:48
  • 3
    Deleting isn't the thing. You have to recreate them. Did you try to "Rebuild Solution" in Visual Studio?
    – Vilx-
    Commented May 13, 2009 at 14:10
  • 3
    Fool of me, I had the build option to release, not debug!
    – CJLopez
    Commented May 4, 2017 at 14:12
  • 1
    Doh! I had the system in Release rather than Debug build. Thanks for the heads-up to check the obvious thing first!
    – Steve Hibbert
    Commented Aug 23, 2017 at 15:57
  • The Rebuild works for me, but sometimes I have to do a Clean first and then a Rebuild.
    – dan-gph
    Commented Nov 21, 2017 at 8:28
17

People.... I found other solution for breakpoint dont stop. In Attach to Process window on Visual Studio 2010 and using Framework 3.5, by default automatically determines the code types to debug (v2.0, v1.1, v1.0) and (v4.0).

Visual Studio gets confused and automatically determines 2.0 managed code as 4.0 managed code sometimes.

In this case you need to click in "Select..." button on "Attach to" field and select Manage (v2.0, v1.1, v1.0).

Regards

Improve this answer
3
  • Well whad'ya know. This actually worked for me. =) Thanks man! (+1)
    – Knots
    Commented Jul 17, 2013 at 13:01
  • @Augusto Mazzoni Pierzynski Only code in CS files is being hit and not Java script code. In The select code type window I tried to check both Managed(4.0) and Script however Visual studio does not allow. It says "SCript debuggiing is not compatible with Managed(v4.0). Would you like to uncheck Managed(v4.0) ? " Any ideas how to resolve this?
    – Hari
    Commented Dec 9, 2015 at 4:59
  • Thank you a lot! This was an issue for me. I guess due to the projects misconfigurations, the debugger couldn't properly determine the correct code type, until i manually selected the .NET version AND the additional "Managed Compatibility Mode".
    – Mladen B.
    Commented Sep 5, 2016 at 10:47
6

VS Debug Problem with IE8

Since this is my first post on Weblogs, I decided to write about a problem that has been opened frequently on the ASP.NET official forum which is the VS debugger crashes with IE8.

I had answered the same problem 4 times, so I hope that some one will find this post very helpful if he is facing the same problem.

How could the VS debugger crash with IE8?

If you opened multiple instances of IE8 and you attempt to debug your project, you will mostly have the issue where the VS debugger just stops and ignores your break points!

Why was that?

IE 8 has a feature called Loosely-Coupled Internet Explorer (LCIE) which results in IE running across multiple processes. http://www.microsoft.com/windows/internet-explorer/beta/readiness/developers-existing.aspx#lcie

Older versions of the Visual Studio Debugger get confused by this and cannot figure out how to attach to the correct process.

To overcome this issue, you need to disable the process growth feature of LCIE by following the below steps:

1) Open RegEdit 2) Browse to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet Explorer -> Main 3) Add a dword under this key called TabProcGrowth 4) Set TabProcGrowth to 0

If you run into the same problem on Vista or newer, you will also need to turn off protected mode.

And then go ahead and start debugging your code :)

Improve this answer
5

You could also try the following:

  1. Close the solution and visual studio.
  2. Run iisreset /stop
  3. Delete everything under C:\windows\microsoft.net\framework\v2.0.50727\Temporary ASP.NET Files. If you have issues deleting some of these files you may have a version of visual studio or it's debugger still running.
  4. Run iisreset /start
  5. Open the solution in VS
  6. Set the build to Debug
  7. Run Rebuild all at the solution level
  8. Hit F5
Improve this answer
3
  • 1
    I did everything on this list (even though I'm not running IIS locally but instead the localhost/port webserver), but I still get the problem. I deleted all .pdb files, no change. The build configuration for all projects is "debug".
    – Edward Tanguay
    Commented May 13, 2009 at 8:47
  • Maybe try running it under IIS then.
    – Jonathan Parker
    Commented May 13, 2009 at 23:23
  • 1
    That worked for me, although the folder was v4.0 instead of V2.0
    – Daniel Valadas
    Commented Dec 12, 2013 at 22:08
4

If you're using Visual Studio 2005 and IE8 I might have an explanation: IE8 introduced a new feature called Loosely-Coupled IE (LCIE) which causes known problems when debugging VS2005 ASP.NET applications. See this thread on SO for more details and some solutions.

It turned out all my debugging problems went away when I shut down all running instances of IE8 before I started a debugging run in my ASP.NET project.

Another reason I'm posting here is to share a blog I found that lists a large number of potential solutions to the 'breakpoints not working' problem. It's nice because the blog lists in one place most of the solutions I found scattered about the Internet. Anyway the blog's author is George P. Alexander; I'll copy and paste the juicy parts here in case something happens to the article:

  1. Using precision guided missiles: Delete the .pdb files in your obj and bin folders. Recompile. Run.

  2. Carpet bomb all .dlls: Delete and reload all the referenced .dlls (Like your class projects)

  3. Release a WMD: If #1 & #2 didn't work, delete the contents of the very obj and bin folders itself so that all .pdbs and .dlls are annihilated. Reload the .dlls required and give it a shot.

  4. VS.Net magic: Close VS.Net and restart. Rebuild. Run. Yes, it sometimes does work.

  5. Windows magic: Shutdown your computer and restart. Rebuild. Run.

  6. Execution mode: Make sure that VS.Net execution mode is set to "Debug" and not "Release"

  7. Web.config settings: Make sure that the XML Element "compilation" tag in your web.config file has an attribute with debug = "true". Only if this is enabled will web apps and services have their .pdb files generated with the .dlls

  8. Project properties #1: Make sure that Project Properties --> Debug --> Enable "ASP.Net Debugging is true" or "Enable the Visual Studio Hosting Process" (depending on the version of VS.Net you are using).

  9. Project properties #2: Make sure that Project Properties --> Configuration Properties --> Build --> "Generate Debugging Information" is set to "True".

  10. Wrong process attached: Your debugging session may not be attached to the right process. You may have to step-in to manually attach the process. This is possible with Web Services. The option to attach a process is within the debug menu.

  11. Script and unmanaged code debugging: Can't debug scripts or unmanaged code? Make sure that Project Properties --> Debug --> "Enable ASP Debugging" or "Enable Unmanaged Debugging" (depending on your version of VS.Net) is set to true.

  12. @Page directive #1: Make sure that the AutoEventWireup attribute in your .aspx document's @Page directive set to "true".

  13. @Page directive #2: Make sure that the Debug attribute in your .aspx document's @Page directive set to "true". If you do not find the attribute, it's okay. By default it is true.

  14. Rogue .DLLs: Make sure that you do not have another instance of the .dll running which lies else where from your intended Project path.

14.1 Rogue .dlls sleeper cell #1: Did you install your project .dll in the GAC folder? You could be running the .dll hosted in your GAC folder instead of the one in your bin folder. Remove/Uninstall the .dll from the GAC and then try again.

14.2 Rogue .DLLs sleeper cell #2:

C:\Documents and Settings[UserName]\VSWebCache[Machine Name]:

Release a WMD (#3) on the folders that are related to your project.

14.3 Rogue DLLs sleeper cell #3: .dlls from your project that are lying else where but are instead referenced in your project. You can find these out by examining project properties. In short, VS.Net is referring some other .dll and not the one loaded in your dev environment.

14.4 Rogue .DLLs sleeper cell #4: Hopefully you won't have to play with this folder by the time you finish with the above points...

Introducing C:\WINDOWS\Microsoft.NET\Framework[.Net version]\Temporary ASP.NET Files\

This folder could contain older versions of .dlls stored in your Windows folder which might get referenced while running from VS.Net. If this happens, it sucks. You can delete as many folders and contents as you can PERTAINING TO YOUR PROJECT. There might be read-only locks which you would need to disable by closing processes. This is more of a last ditch effort. Don't do this if you've never played around with your Windows folder. In most cases something done above before this point usually does fix it. So ideally, you don't have to read this point by the time you're done with the above pointers. And just for the record, I do not recommend anyone to explore this option or play around with your Windows folder if you do not have a Phd in Physics, Mathematics, Windows and .Net.

Other tips:

  1. Module Window: The module window can be viewed while your application is running from VS.Net (Debug --> Windows --> Modules). All modules from your project should be listed there. If your project's .dll is listed and the status of the Symbols is "Symbols Loaded", you've got no problem.

If it's a message related to your .pdb file, goto "Select Symbols" and the appropriate .pdb file. You might have to restart debugging or load VS.Net again. The status should now change to "Symbols Loaded".
2. VS.Net Options: Tool --> Options --> Debugging In VS.Net 2005 onwards, there is one more node called "Symbols" where you can ask VS.Net to look for symbols. This can be accessed via the Module Window when debugging too.

Improve this answer
0
3

Did you set <compilation debug="true"> in your web.config?

Improve this answer
1
  • yes, in my web.config I have: <compilation debug="true" defaultLanguage="c#">
    – Edward Tanguay
    Commented May 13, 2009 at 7:57
2

I had a similar problem with breakpoints not working and, at the same time, in the IIS Console I was not able to edit the configuration for my project, i.e. the Edit Configuration button was greyed out.

[To find the Edit Configuration button: Start | All Programs | Administrative Tools | Internet Information Services, then expand the required computer, expand Web Sites, expand Default Web Site, locate and right click on your required project, select Properties and then the ASP.Net tab.]

I discovered that in IIS, the ASP.Net version for my project was set to 4.0.30319. Once I set it to 2.0.50727, the Edit Configuration button became available (clickable) and my breakpoints worked again.

I also realised that it might be worth checking the ASP.Net version set in IIS for "Default Web Site" [in the IIS Console, expand Web Sites, right click on Default Web Site and select Properties then the ASP.Net tab], so that any new projects created in Visual Studio acquire the Default Web Site setting.

Improve this answer
2

Always look for Solution Configurations to be Set As "Debug" for debugging. It may change to Release configuration after publishing.

Improve this answer
1

I had this problem recently (WinXP, VS2003), and tried many of the solutions above with no success. Then, I realized that there were multiple versions of the .Net runtime installed. So, I brought up IIS 5.1, located the proper virtual folder, went into properties and then the ASP.NET tab, and changed the ASP.NET version from 4.? to 1.1, and it appeared that this solved the problem. It could be that the solution is this, PLUS one or more of the things above.

Also, all of the above make up a "kitchen sink" of different things to try. This is like throwing a bunch of spaghetti noodles against the wall, hoping that some of them will stick. And, some of these "solutions" may cause other problems in your program. For example, the suggestion of setting AutoEventWireup="true" may cause some of your events to fire twice!!! (see http://support.microsoft.com/kb/814745).

Improve this answer
1

In my case, the issue ending up being related to both using full IIS (not Express) and having a debug build where it included full debug symbols but also had project properties, Build, Optimize code checked.

Under Express, this works fine, but under full IIS this doesn't work. Visual Studio attaches to the w3wp process correctly, but it does not load symbols for the optimized dll. In Visual Studio you can go to Debug, Windows, Modules then scroll for the specific dll and see if under the Symbol Status column it shows Skipped Loading Symbols.. Right-click on it and select Load Symbols to make it work.

One additional setting that can affect this is if Visual Studio is set to only debug user code under Debug, Options and Settings, Debugging, General, Enable Just My Code. When optimized, the dlls will be marked as not user code when running under full IIS, so when Just My Code is enabled any breakpoints in them will be skipped. You can either set VS to debug non-user code or set the build to not optimize to allow breakpoints to be hit.

Improve this answer
1

In Visual Studio 2022, Go to the 'Project' tab at the top. Then click 'Configure Startup Projects'. Select 'Configuration Properties'. Set Configuration to 'Debug' from Release or other. Breakpoint work again, and a window showing variable values thoroughly appears

Improve this answer
0

For me, the Project Properties had been reset by another dev to use IIS Express and not my Local IIS with. So the project ran OK but nothing was being hit.

Right click on the Project > Properties > Web > Servers - change to Local IIS. I know this won't work for everyone but hope this helps someone.

Improve this answer
0
  1. Go to your solution properties.
  2. Inside Configuration Properties,Set build configuration set to 'Debug' instead of 'release'for all projects in your solution.
  3. Click on Apply and then OK button.
Improve this answer
0

This drove me nuts for a week until I finally noticed a missing setting. This builds on Jay Riggs's answer, but for Visual Studios 2010 instead of 2005. In project properties -> Web -> Debuggers, make sure that the ASP.NET debugger is checked.

Improve this answer
0

Debug=>Options=>General => Remove the check mark for "Enable Just My Code"

This worked for me

Improve this answer
0

Sounds silly, but put a breakpoint earlier in the process: maybe the process doesn't reach the breakpoint.

Improve this answer
0

Just a little add from something that happened to me in C# WPF but I think that it applies here as well. I tried the above answers but none worked.

Code ---> Thread ---> Function START - breakpoint - END

That might not be your case but I hope that this might help someone. From my code I was launching a thread from which a launched an external function. So try as I might I could not get the breakpoint to work from the external function. And the behaviour (despite my rebuilding or changing options) was exactly what explained in the question.

So I had to move the breakpoint from the external function to the thread and that worked. When stopped I proceeded with F10-F11

Code ---> Thread breakpoint ---> Function START - END

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.