Microsoft KB Archive/312544

= You may receive an &quot;InvalidProgramException&quot; error message when you run a Microsoft .NET-connected program =

Article ID: 312544

Article Last Modified on 12/29/2006

-

APPLIES TO


 * Microsoft Visual Studio 2005 Standard Edition
 * Microsoft Visual Studio 2005 Professional Edition
 * Microsoft Visual Studio .NET 2003 Professional Edition
 * Microsoft Visual Studio .NET 2003 Enterprise Architect
 * Microsoft Visual Studio .NET 2003 Enterprise Developer
 * Microsoft Visual Studio .NET 2003 Academic Edition
 * Microsoft Visual Studio .NET 2002 Professional Edition
 * Microsoft Visual Studio .NET 2002 Enterprise Architect
 * Microsoft Visual Studio .NET 2002 Enterprise Developer
 * Microsoft Visual Studio .NET 2002 Academic Edition

-



This article was previously published under Q312544



SUMMARY
When you run a Microsoft .NET-connected program, you may receive an &quot;InvalidProgramException&quot; error message.



CAUSE
This problem is caused by a bug in the language compiler that was used to build the program.



MORE INFORMATION
A program that is written in a language that uses the Microsoft .NET Framework, such as Visual Basic, Visual C#, or Eiffel, is translated into Microsoft intermediate language (MSIL) instructions. These instructions are stored in the output assembly. When you run the program, the .NET Framework compiles the MSIL instructions into equivalent native code such as Pentium instructions. A just-in-time (JIT) compiler performs this final translation on demand, just before each method executes.

In very rare circumstances, a language compiler may produce invalid MSIL. For example, the compiler may perform one of the following errors:  Issue a value that has no matching MSIL instruction Try to branch into the middle of another multibyte instruction Try to create more local variables than the .NET Framework supports

Note A hotfix is available for this problem. The hotfix increases the limit of local variables from 32,767 to four million. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

919514 FIX: When you use the MSIL Assembler in the .NET Framework 2.0 to generate a PE file from the MSIL code, the PE file may close unexpectedly, and you may receive an access violation error message



When the invalid code runs, the JIT compiler detects the error, and then throws an InvalidProgramException exception. In some cases, the JIT compiler may throw this exception incorrectly if the compiler determines that a method contains invalid MSIL.

When the program runs and tries to execute the code path that contains invalid instructions, the program will throw an InvalidProgramException exception.

Note If the program runs and does not encounter the invalid code path, the program does not throw an exception. For example, if the invalid code path is located in an else block that is not used during this run, the exception does not occur. You are not informed that the problem exists until the program tries to use the invalid code.

When the program throws the InvalidProgramException exception, a dialog box appears that gives you the option to attach a debugger to examine the problem. You also have a choice of which debugger to use. To determine the location of the error, follow these steps:
 * 1) Click Yes, and then click to select New instance of Microsoft Development Environment.
 * 2) When the IDE appears, you receive another message box that reports the unhandled InvalidProgramException exception. Click Break.
 * 3) Open the call stack debug window to see the name of the method and the line number that contains the error.

How to troubleshoot the InvalidProgramException exception
To determine whether your assembly contains invalid MSIL, run the PEverify tool over the program. This tool performs a detailed analysis of all the metadata and MSIL within the assembly, and then reports any problems. A typical problem report resembles the following:

[IL]: Error: [c:\MyApp\Prog.exe : MyClass::MethodX] jmp / exception into the middle of an instruction


 * If the PEverify tool locates invalid MSIL, the language compiler that you used to build the application probably contains a bug. Please send a bug report to your compiler vendor.
 * If the PEverify tool does not locate invalid MSIL, the .NET Framework JIT compiler may contain a bug. Please send a bug report about this problem.

Note If your assembly contains unverifiable code, the PEverify tool also reports every instance of unverifiable code. For example, this behavior occurs if you use the unsafe option in C#, or if you use the compiler for Managed Extensions for C++. You must examine all the instances of unverifiable code to find the instances that cause an InvalidProgramException exception. A list of these instances appears at the end of this article under the heading &quot;PEverify messages that generate a runtime InvalidProgramException exception.&quot;

How to work around this problem
There is no specific solution for this problem. However, you can try various approaches to determine which method works best in a particular situation.

Try to rebuild the application by using a nonoptimized version of the module that appears to contain the problem. How to do this depends on the programming language that you use. However, the method typically corresponds to a debug configuration build or to a /debug option on the command line.

Check the rebuilt application by using the PEverify tool. If the problem persists, try to make small changes to the method that is broken. You can add an extra local variable, or you can rearrange the code.

Note If you change the code, make sure that you preserve the correct algorithm. For example, use if/else instead of the ?: construct.

Tips and tricks
It is possible that the application runs properly when you build the application with optimizations turned off, such as in a debug configuration. But the application throws an InvalidProgramException exception when you build the application with optimizations turned on, such as in a retail configuration. If you try to investigate this behavior by running the application from the Visual Studio .NET IDE, the problem does not appear.

The problem does not occur when you run a program from inside the Visual Studio debugger because the debugger assumes that you want to debug the program and instructs the JIT compiler not to optimize. To run the application with the JIT compiler optimized, build the program in retail configuration, and then run the program outside the Visual Studio debugger. You can double-click the program file name in Microsoft Windows Explorer or run the program from the command line.

When you have narrowed down the location in your code where the problem may exist, you can JIT-attach a debugger to run before the program reaches the line that throws the InvalidProgramException exception. Insert a call to the System.Diagnostics.Debugger.Break method in your code at the point where you want to inspect the program.

If the InvalidProgramException exception occurs only on retail builds, you can use CorDbg, the command-line debugger that is included with the Microsoft .NET Framework SDK. CorDbg can debug fully-optimized code. Type CorDbg, and then type mode jit 1 to enable JIT optimizations. Then you can run the application by using ( run  ). You can also perform tasks such as set breakpoints, inspect source, show the native-generated code, and dump memory.

If you write a program in raw MSIL, and you use the ILASM assembler tool to build the program into an assembly, always run the PEverify tool over the assembly to check for mistakes. ILASM was designed for advanced users of the .NET Framework, such as compiler writers. This assembler tool runs &quot;with the guards off,&quot; and deliberately enables you to generate invalid MSIL. This behavior is useful when you write test software to check runtime behavior. For example, you can insert an instruction that is likely to throw an InvalidProgramException exception, such as the following. br  -3 You can also use the .emitbyte directive to achieve similar, nontypical behavior.

PEverify messages that generate a runtime InvalidProgramException exception
The following PEverify messages indicate that an InvalidProgramException exception will be thrown at runtime. Therefore, your language compiler probably contains a bug.

Note This list includes only the message text. The actual report contains more detailed information about where the error is located.

Unknown opcode.

Unknown calling convention.

Unknown ELEMENT_TYPE.

Stack is too large.

fall thru end of the method.

try start >= try end.

try end > code size.

handler >= handler end.

handler end > code size.

filter >= code size.

Try starts in the middle of an instruction.

Handler starts in the middle of an instruction.

Filter starts in the middle of an instruction.

Try block overlap with another block.

Try and filter/handler blocks are equivalent.

Try shared between finally and fault.

Handler block overlaps with another block.

Handler block is the same as another block.

Filter block overlaps with another block.

Filter block is the same as another block.

Filter contains try.

Filter contains handler.

Nested filters.

filter >= code size.

Filter starts in the middle of an instruction.

jmp / exception into the middle of an instruction.

Unrecognized local variable number.

Unrecognized argument number.

Code size is zero.

Method ends in the middle of an instruction.

Branch out of the method.

Finally handler blocks overlap.

Lexical nesting.

Innermost exception blocks should be declared first.

filter block should immediately precede handler block.

Additional query words: kbreadme

Keywords: kbvs2005swept kbvs2005applies kbcompiler kbdebug kbhowto kbinfo kbreadme KB312544

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.