如何阅读asp.net错误消息

Question

I'd like to get to the bottom of something that has been plagueing me for some time. How the hell does a person read an ASP.net error message like this:

Error: is currently unavailable. DotNetNuke.Services.Exceptions.ModuleLoadException: The server tag is not well formed. ---> System.Web.HttpParseException: The server tag is not well formed. ---> System.Web.HttpException: The server tag is not well formed. at System.Web.UI.TemplateParser.ProcessError(String message) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPat h virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at DotNetNuke.UI.ControlUtilities.LoadControl[T](TemplateControl containerControl, String ControlSrc) at DotNetNuke.UI.Modules.ModuleHost.LoadModuleControl() --- End of inner exception stack trace ---

This is DNN , but this happens from time to time in other .net applications like Sitefinity too and although I can see what the error is, it doesn't tell me where to start looking.

Thanks :)

Answer 1

The actual exception is on the first line. 'DotNetNuke.Services.Exceptions.ModuleLoadException' followed by the exception message.

The rest of the text is mostly the stack trace. This is useful if say the method throwing the error is called from several places, and you want to know which one. The further you read in the trace, the higher up you get in the call chain. So TemplateParser.ProcessError was called by ParseStringInternal, which was called by ParseString, and so on.

Now to the problem at hand, it says the server tag is not well formed. I'm not that familiar with DNN, but a quick google on the message and exception name finds this: http://www.dotnetnuke.com/Resources/Blogs/EntryId/1496/The-server-tag-is-not-well-formed-oh-my.aspx

Which, in case the article is ever moved, contains this solution:

This error is caused by an invalid characted located in the file called EditEntry.ascx. This character has an accent in it causing the crash. For full disclosure, this (now) invalid character has been in the code for quite a while, probably since its first public release.

Open DesktopModules\\Blog\\EditEntry.ascx Go to line 21 Look for the string matching "ResourcêKey " (notice the funky "e") Replace "ê" with "e" Save and upload This fix will get you up and running once again.

Answer 2

A nice trick is explained in this article here -

Click link read full article

It tells about updating the global.asax file to the line number.

void Application_Error(object sender, EventArgs e)
{
   // Code that runs when an unhandled error occurs
   Exception ex = Server.GetLastError();

   // get line number from ASPX parse error
   System.Web.HttpParseException httpParseEx = ex as System.Web.HttpParseException;

   if (httpParseEx != null)
   {
       String lineNumber = "Line number: " + httpParseEx.Line;
   }
} 

Answer 3

That's called a callstack . Many debuggers or programming environments will display this when a problem happens. Usually, what you want to do is start at the top of the callstack and identify which are "system" calls and which are the calls more likely to be the source of the problem. In this case:

DotNetNuke.UI.ControlUtilities.LoadControl[T](TemplateControl containerControl, String ControlSrc) at DotNetNuke.UI.Modules.ModuleHost.LoadModuleControl()

Is the most likely source of the problem.