Bug with x64 in Release configuration

Mar 30, 2012 at 7:46 PM


I've discovered a bug that is visible in a special case when running in x64 in release configuration when no debugger is attached.
Please have a look at the following code:

The ExampleClass is compiled into a seperate assembly:


public class ExampleClass
    static string sText = "Hello World";

    public static string getText()
        return (sText);


This is the program that uses the ExampleClass from a executable:


static void Main(string[] args)
        "The text is: {0}",



The problem on execution now is, that obviously the static constructors are not called and the 'null' is returned. As soon as we start the application from visual studio with F5 only, the example works. When running with Ctrl+F5 it does not. .NET reflection from the framework works fine.

What I really wonder is the fact, that the same example with Debug or in x86 works perfectly in every case. So I currently don't understand where the difference in x64-Release is. Does anyone have an idea how to fix this?

Thank you,
Andreas Guther

Apr 3, 2012 at 8:53 PM

That is actually quite bizarre. It sounds like a bug in the compiler/optimizer or CLR, but those are incredibly rare so not exactly a likely option.

Does it still fail if you untick the "Optimize Code" option on the Build pane of your project properties?

Apr 11, 2012 at 6:27 PM


thank you for your response. No, it does not fail when "Optimize Code" is unchecked. Please have a look on the issue list, I opened a case that includes an example.

Kind regards,

Apr 12, 2012 at 1:47 AM

I looked at your example and it does indeed fail as you describe, however, this behavior is not something that Fasterflect can control or change: It would appear to be a bug in the 2.0 CLR. Note that I am unable to reproduce the problem when using the .NET 4.0 CLR.

You can work around the problem by adding an empty static constructor to the class, like so:

static ExampleClass() {}

This changes the way the CLR initializes static fields. Or alternatively, you can turn off the compiler optimizations - my guess is that the optimizer removes the beforefieldinit flag for the field which triggers the problem in the x64 2.0 CLR.

I searched a bit and came across some interesting links related to this problem:

I'll be closing the issue as Won't Fix, since it's really not anything we can fix.

Apr 17, 2012 at 11:57 AM


thank you for the deep investigation. My problem currently is, that I do not have control over the class I want to use.

My workaround is now to use the default reflection for the first static call I make on that specific class and for the recurring calls I use Fasterflect.

Thank you,

Apr 17, 2012 at 12:14 PM

It's not an ideal situation but glad you resolved it somehow.