通过

"Common Language Runtime detected an invalid program" - InvalidProgramException - When your application has a really large method.

  • 项目

If you've written a whole bunch (and I mean a really big WHOLE bunch) of code inside a method, constructor or the like, there is a good chance you'll see this exception.

We had an application that would generate an Assembly using CodeDom based on certain parameters. The parameter list for one scenario got so huge that the app generated a class with a constructor with 39,000 lines of code. When we tried instantiating an object of this class our app would just crash with a "Common Language Runtime has detected an invalid program" - InvalidProgramException.

PEVerify.exe would not return any errors (and say that the IL is just fine) but when you try and run NGEN.exe it would fail at that gigantic method.

So the problem is with the JIT compiler. There is a limitation on the number of local variable the JIT compiler in the CLR can handle for .NET 2.0 - which was restricted to a max of 32767 (which includes the local used by the JIT itself as well). So once in a blue moon with a GIGANTIC method that you just can't do with out for some strange reason will give you this Exception. This problem is documented in KB (I would like to point out that this is not the only scenario in which the CLR would throw the InvalidProgramException, this is one of the reasons you'd see it).

There is a Hotfix available for this problem now which increases the limit of local variables from 32767 to 4 million. The problem (and hence the reason for this blog entry) is that KB 919514 (https://support.microsoft.com/?kbid=919514), which is related to the Hotfix doesn't seem related at all from the description. And the KB that does sound related KB 312544 (https://support.microsoft.com/kb/312544 - problem #3) doesn't speak of the Hotfix. Our appologies for this confusion - I've written an email to the content team to resolve this documentation issue.

Till then please read KB 919514 and contact PSS for the Hotfix. This fix has already been branched into the Orcas release.

 UPDATE (29/12/2006) : I just got a notification that the content team has updated KB 312544 to reflect the availability of the Hotfix.

Comments

  • Anonymous
    December 08, 2006
    Increasing the limit is an easy fix. However, was it intentionally restricted to 32,767? I am not sure that I am comfortable having a few million local variables in a single method. What is the desired functionality?

  • Anonymous
    December 09, 2006
    "I am not sure that I am comfortable having a few million local variables in a single method" [mjeelani] You are right - you shouldn't be comfortable till you break that method into multiple methods and do an aggressive code review on it. However, from a framework perspective I think the 32767 limit was being hit very often especially by the COBOL developers hence I believe the limit was increased.

  • Anonymous
    May 03, 2007
    I have a method with just a few lines of code and there is a call to another method from there which never takes place! The exception is exactly what has been described.

  • Anonymous
    September 26, 2007
    I have a mixture of .NET 2.0 and VC++6.0 code. I wrote my coclass in VC and implement IList, ICollection and IEnumerable which are comvisible. Then I used the coclass in .NET because of that implementation I can use the object as an ICollection object. But whenever I call one its methods I caught an InvalidProgramException. How should I do?!

  • Anonymous
    November 25, 2007
    I do support on a SharePoint Portal (2003, Framework 1.1). Last week after we deployed some new functionality

  • Anonymous
    February 15, 2008
    The comment has been removed

  • Anonymous
    July 09, 2008
    Thank you so much dudes. Now its working fine to me. After I break into many methods from one large method(39087 lines). Thanks a lot once again.

  • Anonymous
    March 02, 2009
    I managed to get this exception while using Test Driven .Net with a RowTest (which is smallish). A simple solution recompile fixed this for me.

  • Anonymous
    August 20, 2009
    @Allen B. Taylor - If you still want optimization turned on the for rest of the code, but just want to avoid this exception scenario, you can decorate the sensitive methods with [MethodImpl(MethodImplOptions.NoOptimization)] attribute and the compiler will skip optimizations for that method. I had to do that in a recent program that was doing some byte to struct mapping stuff using Marshal.StructureToPtr/PtrToStructure, etc.. Compiler couldn't figure it out, and so, decorating those "low level" methods that moved the byte data around with that attribute allowed me to get a good build with optimization turned on for the rest of the code. Hope that helps, Troy

  • Anonymous
    April 15, 2011
    The comment has been removed

  • Anonymous
    April 27, 2011
    The comment has been removed

  • Anonymous
    January 13, 2014
    @Heider Sati: That's why you should always enable Option Strict!

  • Anonymous
    September 04, 2014
    The comment has been removed