No line numbers in ASP.NET server errors - asp.net

I'm using Visual Studio 2010 and C# ASP.NET. When I run my project using F5 key, it launches the ASP.NET Development Server, and that's the server I'm using for my work, not IIS.
Problem is, when I get a "Server error in / application" unhandled exception error, the error page has no line numbers, nor source file name. Just an error description and stack trace. For example:
Server Error in '/' Application.
DataField must be specified. [or whatever error message]
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: DataField must be specified.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[etc]
I am compiling in Debug mode. My PDB is being generated in my project's BIN directory. In my project properties, under Web, NTLM authentication is turned off. In my web.config I have the following:
<authentication mode="Forms">
[...]
<customErrors mode="Off"/>
[...]
<compilation debug="true" targetFramework="4.0">.
Also in my project properties, under Build, the Debug configuration is active, and the DEBUG and TRACE constant checkboxes are turned on. Under Advanced, the Internal Compiler Error Reporting is set True, and Debug Info is set to Full.
The user account I am running under has "Debug Programs" privilege enabled in its group's security policy.
I have researched this question here on Stack Overflow and elsewhere, but I can't seem to find a straight answer that fits my situation. One answer I found involved removing a setting "impersonate=true" from web.config, which apparently applies to IIS, but I'm not using IIS, nor do I have this in my config file. I'm using the built-in ASP.NET Development Server which comes with VS 2010, instead of IIS. Another answer said to set up a symbol server, and set the _NT_SYMBOL_PATH env variable, but I don't know if this applies to what I'm doing.
This is really confusing because I'm using default settings and configuration for everything, and it seems like this would be a common problem most developers would encounter. Unless everyone else is using Publish and doing their development via IIS. Incidentally I haven't tried with IIS to see if I get line numbers, yet. But I want to use the built-in ASP.NET Development Server -- I would expect it to show full debug/trace details for exceptions by default, and maybe even integrate with VS 2010 to break on exceptions and let me step through code. But maybe I'm asking for too much. Anyone?
(If you answer with a suggested solution, please first read the details of my settings above, so you can see whether I already have the setting you're suggesting.)
Followup: I tried with IIS and I get line numbers. But this doesn't solve the issue because I want to use the lightweight Development Server instead.

So, I figured out that line numbers were showing up fine when a .CS source file threw an exception, but not when an exception occurred in an .ASPX source file. For the .ASPX itself, the line number and source code excerpt were not appearing at all, whether in IIS or Development Server. (This is not exactly how I had described the issue originally in my question, above, so this clarifies things a bit.) One of my colleagues said this is just the normal behavior, there's no way around it. He implied that you will have to guess which line the exception is on in your ASPX page.
However, after more research, I found a way! I can get the line numbers when an .ASPX file causes an exception. But I still don't understand why this isn't any easier to set up! Like maybe an option at the page or project level, instead of requiring a block of code to be added.
The following code must be in each page's ASPX.CS itself, not in its Master Page, nor in any parent class derived from Page class (which the page may inherit from). This is because if the other classes' Page_Error handlers are called instead, then the call stack is affected, and the most recent entry doesn't pertain to the error. (I was looking into a solution for this too by traversing the call stack. It appears to be possible, but I ran out of time and gave up for now.)
public void Page_Error(object sender, EventArgs e)
{
Exception objErr = Server.GetLastError().GetBaseException();
StackTrace st = new StackTrace(new StackFrame(true));
StackFrame sf = st.GetFrame(0);
Response.Write("File Name: " + sf.GetFileName().ToString() + "<br>");
Response.Write("Method Name: " + sf.GetMethod().Name.ToString() + "<br>");
Response.Write("Error Line Number: " + (sf.GetFileLineNumber() - 1) + "<br>"); // line numbers are offset by 1 for some reason
Response.Write("Error Column Number: " + sf.GetFileColumnNumber().ToString() + "<br>");
Server.ClearError();
}

Related

Parser Error Message: Could not load type 'xxxx.Global'

Everything worked yesterday without any errors.
Today though, I created a new page and tried to load it, which returned an error. so I went and rebuilt the solution, and now I have this error on every page on my site.
error description:
Server Error in '/' Application.
Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not load type 'xxxx.Global'.
Source Error:
Line 1: <%# Application Codebehind="Global.asax.cs" Inherits="xxxx.Global" Language="C#" %>
Source File: /global.asax Line: 1
I tried to look up the error, but the solutions I managed to find didn't solve the problem, I would love some help as I am truly lost about what had caused this.
EDIT: so I tried deleting the Global.asax file and running the site, which caused the first line in all my pages to return an error messege. still trying to find a solution.
Managed to solve it, Here's what finally worked for me -
first, in the first line of your aspx pages, Masterpage.Master and Global.asax you'll need to replace CodeBehind with CodeFile.
(in order to access your Global.asax code open it through the directory with a text editor).
after that, in your Global.asax.cs code, change public class Global : System.Web.HttpApplication to public partial class Global : System.Web.HttpApplication.
worth noting - this is a mishmash of a number of solutions that I found while googling, trying these separately first could also solve the bug.
You can try to set the CPU to x64 in visual studio to slove this issue:
On the menu bar, choose Build, Configuration Manager.
In the Active solution platform list, choose a 64-bit platform for the solution to target, and then choose the Close button.
If the platform that you want doesn’t appear in the Active solution platform list, choose New. The New Solution Platform dialog box appears.
In the Type or select the new platform list, choose x64.
If you want to copy the settings from a current platform configuration, choose it, and then choose the OK button.
If this does not solve your problem, you can also refer to the solution in this link:
Could not load type 'XXX.Global'.

ASP.NET XML Parsing Error: no element found Line Number 1, Column 1 Error

Hey I found a weird temperamental page which randomly gives me the following error
XML Parsing Error: no element found
Location: http://kj2011/site_2011/nonprofit-database/overview.aspx
Line Number 1, Column 1:
This page was fine for like 2 weeks but as of yesterday I randomly get the above error. I was to delete the pages and recreate the error is gone but would come back again few hours later. I have some other templates
i.e http://kj2011/site_2011/nonprofit-database/financial.aspx
Which has the same Master File and User Controls but never gets the error just the overview.aspx page.
Any Ideas ?
That sounds like the Firefox error page that's returned when FF expects HTML and gets an empty document instead. Try looking at it with Firebug enabled and see what the Net tab says - perhaps you have a good header, but no html.
Usually that kind of thing is not due to an ASP.NET error (since with those you still have a document body for the Yellow Screen of Death page), but is more along the lines of a networking error...
Would it be possible to try looking at it from another computer to see if that's the problem?
To find the issue you are having with this problem.
In your global.asax file add:
void Application_Error(object sender, EventArgs e)
{
Exception objErr = Server.GetLastError().GetBaseException();
string err = "Error caught in Application_Error event" +
"\n \nError Message: " + objErr.Message.ToString()+
"\n \nStack Trace: " + objErr.StackTrace.ToString();
System.Diagnostics.EventLog.WriteEntry("MYApplication", err, System.Diagnostics.EventLogEntryType.Error);
Server.ClearError();
}
You can set a break point here or log this message into an EventLog.
The most likely cause for such problem is security, if the problem occurs! check file security and make sure its accessible by asp.net process. (ASP.NET Required Access Control Lists (ACLs)), also does this occur with local calls on the same server?
Another thing is to check your page and make sure you don't have one or more unclosed tags in your markup.
I just debugged this issue on my website. In my case, the cause was a call to Response.End() . You can recreate the error by dropping Response.End() as the first line of Page_Load.
From MSDN ms524629:
The Response.End method causes the Web server to stop processing the script and return the current result. The remaining contents of the file are not processed.
In my case, Response.End() was being called before any content was written to the buffer. Also, there was no Content-Type in the response header (see attached Firebug screen grabs). My guess is because of these two factors, Firefox didn't know what to make of it and by default it tried to process it as a an XML file.
In your situation, my guess is the extra View.aspx file caused an exception that was interrupting page rendering cycle.
Just for the future reference, in case people come here from google
According to this thread, there are many different reasons to get this error.
In my case this caused by overriding
override void Render(System.Web.UI.HtmlTextWriter writer)
and I have not called base.Render(writer); at the end of overridden function.
This was an issue with an external DLL, which created a page called view.aspx in the same folder which caused an issue with our overview.aspx. We just renamed the page and the issue went away.
When the rewrite of the url in web.config has a problem - the browser send 404 error. Try to comment all the rules and check again if the 404 error arise.
Just to cover all the possibilities. Today I got the same error, no matter the page I was trying to access, but it was a completelly unrelated issue.
For some reason, Skype loaded before IIS on Windows startup and took control of port 80, instead of the usual 17112. Whenever I tried to access a page Skype returned an empty response.
You can simply shut down Skype and reset IIS, but to make sure it never happens again do the following:
Go to:
Skype > Tools > Options > Advanced > Connection
And uncheck Use port 80 and 443 as alternative for incomming connections
some time This type of error occurs when you have app_offline.html file in your directory.When ASP.Net found a file names app_offline.htm in the root of a web application directory, it shut-down the application, unload the application domain from the server, and stop processing any new incoming requests for that application. ASP.NET also then respond to all requests for dynamic pages in the application by sending back the content of the app_offline.htm file. The default content is an error message.
In my case it was the AjaxControlToolkit.dll that was missing from the bin folder. Adding a breakpoint in the Application_Error method in global.asax as suggested above allowed me to find this out.
I met the same problem, in my case, I lost a ';' in a syntax.
App_Themes folder was missing when I got this.

SharePoint Server 2010: Problem getting detailed error messages

I'm pretty new to SharePoint and IIS, but I haven't been able to find an answer to this one. I'm deploying a custom ASPX with code-behind to my SharePoint server and need a detailed stack trace to see where my problems are.
This involves modifying the web.config file and setting three attributes of certain tags: <SafeMode CallStack="true" AllowPageLevelTrace="true" /> and <CustomErrors mode="Off" />. There are lots of different web.config files, but my error messages change when I modify a certain one, indicating that I chose the right file to edit.
Error message
The problem, however, is that when I do change these tags, I only get an error message telling me the stack trace cannot be displayed remotely, even if I try to display the page on the server itself. The error message basically tells me that in order to get the complete stack trace, I have to do what I just did: Set CustomErrors mode="Off".
I have had this happen before, but only with certain types of errors (HttpModules).
Try checking the windows event log for a more detailed message. It should be there.
Also try restarting IIS/server to make sure its clean/all services are started.

Seeing the actual error behind 'An unexpected error has occurred' in Sharepoint 2010

In MOSS 2007, we could update the tag's callstack attribute to true and then customerrors mode to "Off" to see the actual error behind the 'An unexpected error has occurred' message. Does it apply on SharePoint 2010 as well ? I tried it but I get the following error:
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.
Details: To enable the details of this specific error message to be viewable on the local server machine, please create a tag within a "web.config" configuration file located in the root direc...
Use the ULS logs. There is even a nice viewer for it too: http://code.msdn.microsoft.com/ULSViewer.
In web.config change CustomErrors to Off and callstack to "true" (just search for these values)
You can also see the error in event viewer's Application logs.
It is still possible to make changes to the web.config to get the regular asp.net yellow screen errors. Much like it is with a standard application, the first time you hit F5 in your SharePoint 2010 project, Visual Studio 2010 will prompt you if you want it to automatically configure the local web.config file for you.
However, in SharePoint 2010, the custom error page displays a GUID which can be used as a bookmark in the Log file. It makes searching the Log file much easier. But that GUID will not be displayed on the yellow screen error page, so you might want to take that into consideration before modifying the web.config.

ASP.NET Custom Errors vs. Compilation debug="false" and security

I keep reading that an ASP.NET based web site should have custom errors enabled in the web.config because exceptions will show a stack trace.
I may have a faulty memory (currently don't have access to an ASP.NET website under development), but I thought as long as Compilation debug="false" in the web.config file, then the stack trace will not be displayed.
Is my understanding correct about the debug flag and display of the stack trace? If so, then even if custom errors are not enabled, then won't the only message displayed to remote users for an exception be a the non-descriptive message:
"The page cannot be displayed because an internal server error has occurred."
If so then wouldn't it be OK, from a security perspective, to not display a custom error page for the exception?
No, a stack trace will still be shown even if the debug flag is off, but it will not have line numbers for each call in the stack.
The non-descriptive message is what the browser usually shows instead of the actual error message from the server, unless you change the configuration. Anyone wanting to expose information by causing error messages would know how to do this.
Displaying the stack trace isn't a security risk in itself, but it does expose some information that could potentially make it easier to hack the site. A hacker might for example get a clue as to what's done to sanitase the input and find a way around it.
Custom error messages should almost always be prefered over the default error thrown. It gracefully sends your user to a location where they can keep browsing your site without having to go back and try again.
Turning DEBUGGING off in your web.Config is VERY important and goes beyond just not showing the line numbers and stack trace... it also tells the compiler to build in release mode which optimizes performance dramatically. As soon as your app goes to production, all debugging should be disabled.

Resources