Why would the debugger not be stopping at a breakpoint in my ASP.NET application?

Question

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

Answer 1

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

Answer 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.

Answer 3

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

Answer 4

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

This worked for me

Answer 5

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.

Answer 6

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.