System.BadImageFormatException is not informative - by JGWeissman

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


2
0
Sign in
to vote
ID 433065 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 4/16/2009 5:43:47 PM
Access Restriction Public

Description

When I run a program I generated with Reflection.Emit, I get an Exception that says: System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

I accept that I may have made a mistake in generating the MSIL, but if the runtime claims to have found a problem, it should explain what it is.
Sign in to post a comment.
Posted by Drew Noakes on 8/10/2009 at 10:43 AM
I too am finding this exception quite frustrating. peverify says all classes and methods are ok, which I'd expect seeing as the assembly has been generated using Reflection.Emit. So, I'm left wondering, what category of problem causes BadImageFormatException when the assembly is generated by the .NET framework itself?
Posted by Microsoft on 5/19/2009 at 2:08 PM
Hello,
Thank you for getting in touch with us and providing this feedback. We are at a point in the release where this particular bug (BadImageFormatException should be more informative) does not meet the bug-fixing bar. As a result, I'm resolving your bug "By Design".
However, your suggestion is valid and here are some resources/mitigations that will help.
1) Run peverify.exe - this provides some useful information on the cause of the bad image, helping you to debug the issue better.
2) Check bitness - are you trying to load a 32 bit assembly in a 64 bit application?
3) Check if the runtime versions match - are you trying to load a CLR v2.0 assembly in an application that has CLR v1.1? Modules built against v2 can not be loaded by a pre-v2 CLR.
4) Are you loading an unmanaged assembly as if it's a managed dll?

(2), (3) and (4) are the primary causes of a BadImageFormatException. I hope this suggestion helps. If you think that the resolution of this bug is unacceptable, please feel free to send me an email at aarthir AT microsoft DOT com, or simply re-activate this issue.

Thanks!
Aarthi Ramamurthy,
PM, CLR.
Posted by JGWeissman on 4/20/2009 at 10:10 AM
The problem in this case turned out to be that generic parameters were not resolved to a specific type. The exception therefore should have said that the generic type Foo<Bar> referenced at a certain instruction needs the generic parameter Bar to be specified. Further, the call to ILGenerator.Emit that generated that instruction should have a thrown an exception explaining the problem.

My problem had nothing to do with the 32-bit/64-bit architecture issue you referenced. Though that case also should generate a better error message, or better yet, just automatically run the DLL with the right architecture (I would hope the DLL specifies what architecture it expects).

I expect that there are plenty of other conditions that cause this error that should also have specific, helpful exceptions.
Posted by Microsoft on 4/19/2009 at 8:37 PM
Please go to http://msdn.microsoft.com/en-us/library/k7137bfe(VS.80).aspx and try workaround provided by chaiguy1337. You can find it at the bottom of the page.

Thanks,
Kylin.Ming
Posted by Microsoft on 4/19/2009 at 8:35 PM
Thanks for reporting this issue. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team