Weird timeout error in 1.6.0.0

Topics: ASP.NET 2.0
Dec 23, 2010 at 12:53 PM

Ok, I've reproduced the other error I've been seeing.

If I click the Home button on the top menu bar of the front page after a long time, I get an error page:  http://jeffreygetzin.com/blog/error404.aspx?aspxerrorpath=/blog/default.aspx

If I hit the Home button again, even from that error page, I get a valid page.

I'm thinking this has something to do with a session timeout. Perhaps some Session variables are now null?

Again, the blog still has the default password if you want to go in and monkey about. I'd give it some time to time out before you do that, though.  I can also provide screen captures if that helps.

  Thanks,

   Jeff

P.S. I thought I should mention that I program in C# and .NET sometimes for a living. As a professional who works with this type of project, let me say that this is one heck of a well-designed project. I'm very impressed at the overall design of the solution!

Coordinator
Dec 23, 2010 at 6:15 PM

Yes, I see that ... and I think I maybe saw it yesterday too.  I think it's an error occurring during some type of application startup process ... where it happens just the first time, but not after that since the application has already started.  I can restart the blog by going to the Extensions tab in the control panel, and disabling an Extension (then re-enabling it).  And then the error occurs again when hitting the homepage OR hitting any other page in the site (e.g. contact.aspx).

Two things you can do.  It's possible the error is being recorded in logger.txt in the App_Data directory.  So you could check there to see if that file exists, and what's inside it.  There could be other things logged too.

The other thing is to modify the custom errors tag in the web.config file, by turning it off.  So it would look like:

<customErrors mode="Off">

This will probably cause the actual error to be displayed on the page, rather than being redirected to error404.aspx.

BE isn't using Session, btw.  Session state is disabled in the web.config file.

Dec 23, 2010 at 6:45 PM

I didn't find any logger.txt file. (BTW, have you checked out log4net?)

So I went in and turned off custom errors. Now you can definitely see that something is rotten in Denmark. It looks like binary data, or possibly text in the wrong character encoding, is being written to the response. I have no clue what this means or could be causing it.

   Jeff

Coordinator
Dec 23, 2010 at 6:58 PM

We're making progress.

Modify your global.asax file in the root, and change the Application_Error method so it looks like the one I posted here on November 9th.  This will output an actual error message on the page (not formatted nicely, but will be sufficient).

Dec 23, 2010 at 7:15 PM

 

Ok, I'm on it. b)

Give me a few minutes ...

Dec 23, 2010 at 7:17 PM

Interestingly, I don't see that file deployed to the root directory. Is it compiled into the application?  (If so, I'll need to recompile.  If not, we may have found our problem!)

Coordinator
Dec 23, 2010 at 7:20 PM

Global.asax is not compiled.  It's an uncompiled, text-based file that is included with BE.  It should be in the root folder.

Here's what the file looks like.

Dec 23, 2010 at 7:40 PM

Ok, that seems to have had no effect.

Now to be clear, I built the project from source code and then did a Publish from VS into a local directory and uploaded the contents of that directory. So, for instance, none of the code-behind files were uploaded; instead they were compiled into the bin/ dir. Is this not the intended path for deployment?

   Jeff

 

Coordinator
Dec 23, 2010 at 7:45 PM

I see ... that's not really the intended path for deployment.  Some people have reported runtime errors & problems when using the Publish feature in VS.  It is probably creating a bunch of small DLL files in the /bin directory.

The intended deployment method is to just copy/FTP the files directly to the server, as-is.

This could be the actual problem.

Dec 23, 2010 at 7:47 PM

Ok, let me try that. I'll delete everything except for the data directories and then re-copy over all the files as-is.

  Jeff

Dec 23, 2010 at 8:02 PM

Ah ha! Now we have something to work with!

 

Server Error in '/blog' Application.

Security Exception

Description: The application attempted to perform an operation not allowed by the security policy.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

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:

[SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) +0
System.Security.CodeAccessPermission.Demand() +58
System.IO.Path.GetFullPath(String path) +98
System.Xml.XmlResolver.ResolveUri(Uri baseUri, String relativeUri) +92
System.Xml.XmlUrlResolver.ResolveUri(Uri baseUri, String relativeUri) +9
System.Xml.XmlTextReaderImpl..ctor(String url, XmlNameTable nt) +99
System.Xml.XmlTextReader..ctor(String url, XmlNameTable nt) +31
System.Xml.XmlDocument.Load(String filename) +62
BlogEngine.Core.Providers.XmlBlogProvider.SelectPage(Guid id) in Pages.cs:32
BlogEngine.Core.Providers.BlogService.SelectPage(Guid id) in BlogService.cs:145
BlogEngine.Core.Page.DataSelect(Guid id) in Page.cs:325
BlogEngine.Core.BusinessBase`2.Load(KEY id) in BusinessBase.cs:271
BlogEngine.Core.Providers.XmlBlogProvider.FillPages() in Pages.cs:129
BlogEngine.Core.Page.get_Pages() in Page.cs:253
BlogEngine.Core.Page.GetFrontPage() in Page.cs:288
BlogEngine.Core.Web.HttpModules.UrlRewrite.context_BeginRequest(Object sender, EventArgs e) in UrlRewrite.cs:57
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +68
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75



Version Information: Microsoft .NET Framework Version:2.0.50727.4200; ASP.NET Version:2.0.50727.420

[/quote]

Dec 23, 2010 at 8:09 PM

Interestingly enough, the trust level for the application is set to "Full (internal)" according to IIS Manager. Same for the parent application directory.

Jeff

Coordinator
Dec 23, 2010 at 8:14 PM

Yes, getting somewhere :)

I think this specific error is related to CAS (code access security), which has to do with medium trust, full trust, etc.

BE will normally run okay in medium trust.  It's most likely related to the environment where your blog is hosted ... meaning, the web hoster may have some overly restrictive policies.  It looks like the code is making sure it has File IO access per the code access security policies on that machine, and failing there.

Here's Google results for the error message.  And here's Google results for "FileIOPermission" appearing here at CodePlex BlogEngine (these results are more specific to BE).

You might want to check some of those results out.

Coordinator
Dec 23, 2010 at 8:18 PM

You might want to try specifying a medium trust in your web.config file.  In the <system.web> section, try adding:

<trust level="Medium" />

Dec 23, 2010 at 8:37 PM

That seemed to have done the trick. I had to pretty much nuke the entire site, upload everything as binary, add the trust-level to the web config, and then set the trust level for the directory to Full in IIS Manager. Now it seems to be working! :)

Coordinator
Dec 23, 2010 at 8:42 PM

That's great news ... and yes, if I restart your blog (by disabling and re-enabling an Extension), no more error message.

Dec 23, 2010 at 8:46 PM

Seems like a weird chain of errors. I'd like to know why we got the binary data on the error screen, but I guess all is well now. Thank you for all your help! :)

Coordinator
Dec 23, 2010 at 9:01 PM

You're definitely not the first person to get the binary data ... some people call it garbage characters, etc.

It happens in BE when an unhandled error occurs in certain locations within the code ... it doesn't occur for all types of errors.  I'm actually not sure in what cases you see the garbage characters vs a normal yellow screen of death.  But one reason it can happen with the global.asax file that is included with BE 1.6 is because the Application_Error handler in global.asax catches unhandled errors, and then attempts to do a Server.Transfer to error.aspx.  error.aspx is a normal webform page that uses the normal masterpage.  If the reason for the error in the first place is because the masterpage is throwing an error (or some widget/control within it), then when Server.Transferring to error.aspx, the same (or different) error occurs again since the masterpage cannot run without errors.  However, even in this case, it seems like a yellow screen of death could be shown, instead of the garbage characters.  So I'm not sure exactly!