Microsoft Knowledge Base Article
This article contents is Microsoft Copyrighted material.
©2005-©2007 Microsoft Corporation. All rights reserved.
Terms
of Use |
Trademarks
Article ID: 316970 - Last Review: July 15, 2003 - Revision: 2.6
PRB: Debugger Fails to Hit the Breakpoint When You Debug an ASP.NET Web Application a Second Time
This article was previously published under Q316970
When you debug an ASP.NET Web application, the debugger may
successfully hit the breakpoint (on an erroneous line of code) only the first
time. On subsequent runs, the debugger may fail to hit the breakpoint, and you
receive a server error page.
For performance reasons, the ASP.NET worker process,
Aspnet_wp.exe (or W3wp.exe for applications run on IIS 6.0) caches the error
information after the first debug session. If you try again to debug and do not
make any changes in the code, the breakpoint is skipped. This
behavior occurs because Aspnet_wp.exe determines that the code is redundant and
then Aspnet_wp.exe displays only the cached error page.
To resolve this issue, you need to force a reload of the
pertinent .dll file into aspnet_wp.exe (or w3wp.exe for applications run on IIS
6.0). To do this, recompile the project before you debug again. However, the
project cannot be recompiled unless you make changes to the code. Therefore,
restart Microsoft Visual Studio .NET, and then click
Rebuild All. (Alternatively, you can run the
iisreset command from the command prompt.) Now, when you run the debugger
again, it hits the breakpoint.
Steps to Reproduce the Problem
- Start Visual Studio .NET.
- On the File menu, point to New, and then click Project.
- In the New Project dialog box, click Visual C# Projects under Project Types. Under Templates, click ASP.NET Web Application.
- In the Location box, type TryDebug. If you are using the
local server, you can leave the server name as http://localhost, so that the Location setting is http://localhost/TryDebug. Click OK to create the project.
- In the Solution Explorer, right-click WebForm1.aspx, and then click View Code.
- Copy and paste the following code after the Page_Load event handler in the WebForm1 class:
private static System.String ss = WebForm1.StaticMethod();
public static String StaticMethod()
{
String s = null;
s.CompareTo( "hello" ); //put Break point here
return "Hello";
}
- Insert a breakpoint in the following line of code:
s.CompareTo( "hello" ); //put Break point here
To do this, select the specified line of code, and then press
F9. - Press F5 to run the debugger. When you hit the breakpoint,
press F5 again. In the Exception dialog box, click Continue.
You receive the error page in the browser. - Stop the debugger.
- Press F5 to run the debugger again.
This time,
the debugger may not hit the breakpoint. Instead, you receive the cached error
page in the browser. On subsequent debug attempts, you continue to receive the
cached error page.
For additional
information about how to debug ASP.NET Web applications, click the article
numbers below to view the articles in the Microsoft Knowledge Base:
306172Â
(http://kbalertz.com/Feedback.aspx?kbNumber=306172/EN-US/
)
INFO: Common Errors When You Debug ASP.NET Applications in Visual Studio .NET
306169Â
(http://kbalertz.com/Feedback.aspx?kbNumber=306169/EN-US/
)
PRB: Visual Studio .NET Debugger Does Not Stop on Breakpoints When You Debug ASP.NET Pages
APPLIES TO
- Microsoft ASP.NET 1.1
- Microsoft Visual Studio .NET 2003 Professional Edition
- Microsoft Visual Studio .NET 2003 Enterprise Architect
- Microsoft Visual Studio .NET 2003 Enterprise Developer
- Microsoft Visual Studio .NET 2003 Academic Edition
- Microsoft ASP.NET 1.0
- Microsoft Visual Studio .NET 2002 Professional Edition
- Microsoft Visual Studio .NET 2002 Enterprise Architect
- Microsoft Visual Studio .NET 2002 Enterprise Developer
- Microsoft Visual Studio .NET 2002 Academic Edition
| kbdebug kberrmsg kbhttpruntime kbide kbprb KB316970 |
Community Feedback System
Very often, it takes hours to solve a problem. Very often, you've looked high
and low, and have tried a lot of solutions. When you finally found it, chances
are, it was because someone else helped you. Here's your chance to give back.
Use our community feedback tool to let others know what worked for you and what
didn't.
Please also understand that the community feedback system is not warranted to be
correct, it's simply a system that we've built to let people try and help each
other. If something in a feedback response doesn't make sense to you, or you're
not comfortable making changes that the feedback talks about (like registry
edits), please consult a professional.
Thank you for using kbAlertz.com Feedback System.
-- Scott Cate