InvalidProgramException / Common Language Runtime detected an invalid program

Question

This is the weirdest programming problem I've seen for a long time.

I am using Microsoft Visual C# 2010 Express , C# and .NET 2.0 to develop an application. This application refers to a couple of dll / assemblies (all of these libraries are generated on my machine).

The following is part of the code (these are all basic things):

 public class PowerManagement { [TestCase] public void PrepareTest(){ // Configure according to pre-conditions Preconditions precondition = new Preconditions(); precondition.SetupPreconditions(); ... } [TestCase] public void PerformTest(){ TestcaseData testcaseData = new TestcaseData(); // Set Trigger and perform check switch (testcaseData.triggerNumber){ case (1): if ((new Trigger1(testcaseData)).Validate() != 1) Report.TestStepFail("failed"); break; ... case (4): if ((new Trigger4(testcaseData)).Validate() != 1) Report.TestStepFail("failed"); break; default: Report.TestStepFail("Not yet implemented"); break; } } } 

This application is then generated in a dll from Visual C# 2010 Express and used elsewhere, and everything is fine. The problem occurs when I add another case to the switch statement (see below)

  ... case (4): if ((new Trigger4(testcaseData)).Validate() != 1) Report.TestStepFail("failed"); break; case (5): if ((new Trigger5(testcaseData)).Validate() != 1) Report.TestStepFail("failed"); break; default: Report.TestStepFail("Not yet implemented"); break; 

I can still build without a single problem and generate a dll, but when I use the generated dll, I get the following error:

 A .NET exception (InvalidProgramException) occured in the module PowerManagement Error message: Common Language Runtime detected an invalid program. Throwing method: PowerManagement.PerformTest 

(the problem occurs even if I copy case(4) and paste it as a new case, so it has nothing to do with Trigger5 -class)

What's going on here? I looked at the other InvalidProgramException and Common Language Runtime in Stackoverflow, but none of them were related.

I know this problem is strange , so please let me know and I will provide more information. I use a Windows 8 64-bit machine, if that matters. I have already checked for updates for VS and .NET updates. I havet also regenerated all dlls a couple of times and also created a solution from scratch a couple of times.

Answer 1

I finally managed to solve this problem. I disabled code optimization in C # Express and solved the problems. The strangest thing, but since we use old tools and frameworks, we cannot blame anyone.

Answer 2

I just wanted to add my experience for this ... In my case, I host my C # Web API on Azure, and I came across this message when trying to enter my API. I had to go to my Azure management portal (portal.azure.com), go to Application Services, select my Web API program and click "Restart" on the "Overview" screen. After that, the program again worked as usual. I did not find any additional clues in my magazines.

Answer 3

Try enabling 32-bit applications in your advanced application pool.

Answer 4

I had this problem after upgrading to Visual Studio 2017 v15.8.6 . The problem disappeared when I removed the assemblyPostProcessorType attribute in the compilation tag in web.config .

Answer 5

I sometimes came across this error after deploying to an Azure web application using MSDeploy. The error always disappeared after redeployment.

Our assembly and deployment are two different steps: the redeployment sends the same files each time - this suggests that the problem is not only the compiler problem, as suggested in other parts of the answers to this question.

Perhaps this is a bug in MSDeploy or in the IIS version used for WebApps in Azure ...

Answer 6

According to MSDN : "Usually this indicates an error in the compiler that generated the program."

I would start by making sure all updates are installed on Windows, .NET, and Visual Studio.

You should also check out Q312544 with Microsoft support.

Answer 7

Such a problem can be caused by errors in the tools that manage IL builds after compilation, for example, if you use Fody and its plugins. At least there is an error in the Fody MethodDecorator that causes such an effect, see https://github.com/Fody/MethodDecorator/issues/8

Answer 8

I solved this problem by following these steps:

• Rename C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Team Tools \ Performance Tools \ vsinstr.exe to C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Team Tools \ Performance Tools \ vsinstr.exe.broken
• Rename C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Team Tools \ Performance Tools \ vsinstr.legacy.exe to C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Team Tools \ Performance Tools \ vsinstr.exe
• Restore solution

Answer 9

If your problem is with the dotnetcore web api deployed in an Azure application , then this may be due to an understanding of the application. Setting the understanding of the application at the blade level should solve the problem. Also note that there seems to be an unresolved issue with setting it at the blade level as recommended parameters compared to basic . The core is the value that works.

This issue is related to deploying the web API as an API application in Azure. An initial request to any endpoint will result in the expected response; however, subsequent requests will return the same Common Language Runtime error. I found out that the problem started when I turned on the Recommended collection level on the Application Insights blade in my web application. I installed the recommended ones and turned on all the switches. Reverting this change stopped the error. For reference, the API I'm using is running Microsoft.ApplicationInsights 2.8.1.

For reference: https://github.com/dotnet/coreclr/issues/18323

Answer 10

-uncheck "code optimization" (see links to DLL) -Upgrade in .net framework 4.6

Answer 11

If you have this problem with Azure web applications, check if the Microsoft.ApplicationInsights.AzureWebSites extension is installed or its friendly name is the Application Insights extension for the Azure application service and uninstall it through kudu .

We found this extension was potentially interfering with MSDeploy pushing - there was a snapshotholder_x64.exe process running under the IIS w3wp.exe process. Someone has probably enabled this extension through the Azure portal.

Answer 12

Out of nowhere, we started getting a XXX webservice Exception, System.InvalidProgramException: Common Language Runtime detected an invalid program.

I copied the compiled site to another environment - it works just fine. I copied it to another server - it works just fine.

I noticed that this exception started when the server rebooted (either rebooting or resetting the application pool). Exploring this problem, I noticed a comment by Brian Reichl on June 6, 16 at 12:33.

I expect the bit mismatch to result in a BadImageFormatException, not the InvalidProgramException described in the question.

I was not familiar with the InvalidProgramException exception but I was familiar with the BadImageFormatException and the symptom is very similar to the one I get with the BadImageFormatException problem. I can’t say 100% why any exception occurs, the current execution theory is a 32-bit application running on a 64-bit machine, but we could not prove it and could not fix it. Including 32-bit applications in the application pool did not fix the problem.

The only fix we know, albeit temporary, is to simply restart the App Pool. No need to recompile or anything else. Fortunately, this does not happen too often, maybe once a month or two.

Answer 13

I just ran into this problem myself. Despite the fact that VS created a virtual directory for me, vb was used as the default language, but I have a C # application. Changing this setting solved the problem.

Answer 14

This is an interesting exception that I encountered while hosting on IIS. I solved this by discovering that my version of the .NET Framework on IIS is different from the version of the .NET Framework that my project used. Note that if you have other / ddl projects that are referenced, make sure you also update their version of the .NET Framework.