Cook Computing

Operation could destabilize the runtime

June 28, 2006 Written by Charles Cook

I've just come across mention of an XML-RPC.NET problem on the clyx development blog. They have a Community Server installation and were seeing exceptions with this message:

Operation could destabilize the runtime.

What the? Sorry, could you repeat that? I am so learning to hate that message. A haiku message would be more useful. The message may be mysterious, but our experience indicates that it is somehow related to mixing .NET 1.1 and .NET 2.0 assemblies in the one \bin directory. (Shades of DLL Hell all over again...)

We saw this in both the Exceptions Report and Event Log. It happened when using a desktop blogging tool to access the CS Metaweblog API. We also noticed that an assembly wasn't loading - the ubiquitous and very handy XML RPC support library from Cook Computing. This seemed to be due to it being strongly named. By grabbing the source, building it in .NET 2.0 and removing the key file reference (alternatively, adding your own key), we were able to get it going.

So we got this far OK... let's check that log one more more runtime destabilization.. YAY!

A post on a Microsoft ASP.NET forum seems to confirm there is a possible issue with using assemblies built for .NET 1.1 in an ASP.NET 2.0 application:

We saw this back towards the end of Whidbey for a case where 1.1 DLLs were being used in an ASP.NET 2.0 app. Apparently the 1.1 compilers for C#/VB.NET had some boundary cases with the IL they emitted. In 2.0 there were low-level changes in the CLR that made some 1.1 code unverifiable - which leads to the exception you are seeing. Unfortunately I can't claim to understand what it was the CLR changed - I just know we saw it.

In our specific case it was a problem with a C# switch statement that had more than 8 conditions - underneath the hood the C# compiler in 1.1 emitted IL code that became unverifiable in 2.0. I don't see any switch statements in your code above so that's not going to be the specific problem.

To track down the problem, you should try the old fallback of chopping out all the code except the first line. Then run the app - see if it fails. Then uncomment the second line code code - run the app - see if it fails. Rinse and repeat. That's literally how we tracked down the issues on our team.

The error message is coming from an instance of System.Security.VerificationException. The clyx problem manifested itself when they migrated from development to their production hosting site and went from running their code under full trust to medium trust. This is because their hosting service, like many others in shared hosting environments, force ASP.NET sites to run under medium trust to prevent applications from causing any damage to the system or to other sites on the same machine. When running with medium trust code is verified unlike full trust where verification appears to be skipped. I didn't realize that in a full trust environment, i.e. code running locally on a system with default settings, code is not verified. For example this program from the .Net Security Blog will run locally even though PEVerify fails it:

// Compilation:
// ilasm -nologo -exe

.assembly extern mscorlib {}
.assembly test { .ver 0:0:0:0 }

.class public Test extends [mscorlib]System.Object

    .method public static void Callee()
        .maxstack 1
        ldstr "In Callee()"
        call void [mscorlib]System.Console::WriteLine(string)

    .method public static void Main()
        .maxstack 1
        ldftn void Test::Callee()
        calli void ()


I've not been able to reproduce clyx's problem but I am seeing the following error when running XML-RPC.NET in anything but Full Trust:

Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

The exception is thrown when MethodInfo.Invoke is called. I need to do some more investigation.