When you run a Microsoft .NET-connected program, you may receive an "InvalidProgramException" error message.

Back to the top

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

Back to the top

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 (http://support.microsoft.com/kb/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.

Back to the top

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:

•	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 "PEverify messages that generate a runtime InvalidProgramException exception."

Back to the top

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.

Back to the top

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 MyApp ). 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 "with the guards off," 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.

Back to the top

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.

Back to the top