BadImageFormat Exceptions on 4.5.13 and 4.5.15 of dotNetAgent.

[Terje_Barth]

We are experiencing loss of functionality - replaced with a "BadImageformat" exception and the IIS Server returning HTTP 400 to the clients in one of our services every X number of App Pool Recycles in production and have managed to track this back to the AppDynamics agent. We initially ran 4.5.13 and were able to reproduce the error behaviour in our QA environment, and also to see it disappear as an issue when AppDynamics was uninstalled and IIS restarted. Our hope was that 4.5.15 would've fixed this issue, despite it not being mentioned on the fix list. Unfortunately we seem to be able to reproduce the error behaviour here too, albeit less frequently. I thought this issue was fixed in a much earlier version of the DotNetAgent?

[iamryan]

Hi @Terje.Barth,

The .Net agent was updated in December (DOTNET-3700) to fix this issue https://docs.appdynamics.com/display/PRO45/Resolved+Issues+by+Month#ResolvedIssuesbyMonth-January202....

[Satyam_Jaitely]

BadImageFormatException is something we have seen recently and our Devs are currently working on the fix. The fix will be coming very soon.

The root cause is a race condition when making IL transformations, which introduces nulls in the transformed IL.
This issue we're seeing is caused by a race condition where the agent injects multiple methods into the application for tracking business transactions.  One of the methods injected is calling another method where the method signature exists but the method body doesn't yet.  This results in the BadImageFormatException you're seeing. 

Meanwhile, we have a workaround configuration to work around this issue without losing visibility. This workaround requires the following changes:

1. Edit the config.xml to add the following xml element within the <app-agents> element.
   • <profiler>
     <full-no-dependency-mode enabled="false" />
     </profiler>
2. Save the Config.xml file.
3. Restart the AppDynamics.Agent.Coordinator service.
4. Restart the instrumented process (the application pool in this case).

So our recommendation is to make the configuration change above, which will resolve the issue you're seeing now without having to wait for a new agent version.  Once the new agent version comes out we recommend upgrading to that version(4.5.18) and then removing the config above from the configuration file. 

[Jonathan_Barrow]

What would happen if a 4.5.18 or newer system still had the <full-no-dependency-mode enabled="false" /> flag in place?