Aparenly is a .net issue here’sa long lost microsoft article about it
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:
Click Yes, and then click to select New instance of Microsoft Development Environment.
When the IDE appears, you receive another message box that reports the unhandled InvalidProgramException exception. Click Break.
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 "PEverify messages that generate a runtime InvalidProgramException exception."
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 ?: