This project is read-only.

Operation could destabilize the runtime

Topics: ASP.NET 2.0
Jan 8, 2011 at 7:27 PM

Just upgraded from 1.6 to 2.0 (SQL2005 backend) using GoDaddy shared hosting running .NET 4 and integrated pipeline.

Site appears to be working fine until I login and then I am staring at a page of corrupted html (screenshot: ) This site is pretty much out of the box. I have only added 1 widget (but I was getting this error before)

Using Fiddler, I was able to determine I was getting a 500 Internal Server Error, but nothing else - no logs from BlogEngine. I then added ELMAH to the site to get the error and I was able to see the complete error message. 

System.Security.VerificationException: Operation could destabilize the runtime.

System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.Security.VerificationException: Operation could destabilize the runtime.
   at BlogEngine.Core.Utils.ParseEnum[T](String value, T defaultValue)
   at BlogEngine.Core.SecuritySiteMapProvider.IsAccessibleToUser(HttpContext context, SiteMapNode node)
   at System.Web.SiteMapNode.IsAccessibleToUser(HttpContext context)
   at System.Web.StaticSiteMapProvider.GetChildNodes(SiteMapNode node)
   at System.Web.SiteMapNode.get_ChildNodes()
   at Admin.Menu.BindMenu()
   at Admin.Menu.OnLoad(EventArgs e)
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.HandleError(Exception e)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP.default_aspx.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)



Jan 8, 2011 at 10:30 PM

Hi, glad you were able to find that error message.  See this issue.  What you can do, I believe, is remove the "rights" attribute from all the nodes in the Web.sitemap file.

An example is:

I'll look into this... not sure what's causing the error to occur.

Jan 8, 2011 at 10:42 PM

Btw, you said you're using .NET 4.0.  Are you using the web.config file that came with BE?  I'm speaking of the one that is included in the root folder of BE.  That one is designed for .NET 3.5.

In the /setup folder, there is a file named ASP.NET_4.0_Web.Config.  This is a .NET 4.0 version of the web.config file.  Have you tried replacing the web.config file in the root with that one?  I'm curious if this error is still present if you were to use the .NET 4.0 web.config file.

Jan 9, 2011 at 4:37 AM

Yes, I using the SQLServer.NET_4.0_Web.Config as the starting point for the web.config updates.

Thanks, removing the rights attribute from the web.sitemap appears to have fixed the issue.

As to the cause of the error, I don't know either.. No funky LINQ queries, just straight up generic list enumeration and boolean checks. If you need a guinea pig for any fix, let me know.

Jan 9, 2011 at 7:02 AM

Yeah, it's strange.  Your stack trace helps.  It looks like the error is occurring in Utils.ParseEnum.  If you happen to know the exact line the error is occurring on that, that could be helpful.  My only guess is that it's occurring on the line:

foreach (T item in Enum.GetValues(typeof(T)))

But that doesn't look like it should cause a problem.  All the other lines in Utils.ParseEnum are as simple as can be  :(

Jan 9, 2011 at 7:57 PM

If you have a free moment, maybe you can try this code below for inside the IsAccessibleToUser() function.  This replaces the existing foreach loop, and does not call Utils.ParseEnum.  If you test this, just please make sure you put the "rights" attributes back into the Web.sitemap file so this code runs.  Thanks......

foreach (string r in rightsRaw)
	if (Enum.IsDefined(typeof(Rights), r.Trim()))
		Rights right = (Rights)Enum.Parse(typeof(Rights), r.Trim(), true);
		//Rights right = Utils.ParseEnum<Rights>(r.Trim(), Rights.None);
		if (right != Rights.None)

Jan 13, 2011 at 2:16 AM

What if you switch to ASP.NET 4.0 Classic?

Mar 30, 2011 at 10:32 PM
Edited Mar 30, 2011 at 10:49 PM

Same problem here.

I have a parent website on Rackspace Cloud (cluster) which I just converted to 4.

I left the child "BlogEngine" (latest revision etc) application as 3.5 to start off with, but that didn't work. So I figured if I was going to have to slug it out I may as well do it all on 4.0, so I switched to the 4.0 web.config, uploaded that, and... same problem as the first post here as far as I can tell.

I tried the web.sitemap change but that makes no difference. I think it's likely GoDaddy and Rackspace Cloud use the same thing - there have been other errors with applications in the past related to the medium trust business which they likely both use.

Anyone made this work? I'll obviously report back if I can get it running.

------------- UPDATE

Scratch that... I just mucked about with it, bounced it a few more times, tried it again on my test machine and it started working. There  are funny cache issues with Rackspace Cloud, so perhaps it was those. So to clarify: I saw this error for a few minutes, but it went away and all is well. Thanks.

Apr 16, 2011 at 2:04 AM

Similar problem with a website w/BlogEngine on GoDaddy hosting.  Pulled the "rights" from web.sitemap file and the problem went away.  Is that the "official" fix for the problem?

Apr 16, 2011 at 8:53 AM

For now, removing the Rights is the only simple option that doesn't hurt anything.

The Rights are only important if you have multiple users logging in who are assigned to different Roles where certain Roles have rights to do certain things.  For a typical blog where there's a single person, the Rights are not needed.

Not sure exactly why .NET throws this error.  I suppose for a future release we might change the code that parses the web.sitemap Rights so this error does not occur.