“Bad binary signature” in ASP.NET MVC application

Question

We are getting the error above on some pages of an ASP.NET MVC application when it is deployed to a 64 bit Windows 2008 server box. It works fine on our development machines

Answer 1

I've just seen a similar issue to this where some lambda expressions are used within views which leads to a corruption of the .Net dll when compiled on a 64 bit system. It results in the same exception you are seeing, and certainly sounds like a likely candidate.

Apologies if this seems a little vague, as we haven't fully resolved this and are still looking into it, although I'll be sure to update here when we have a resolution.

The trail that makes us believe this is an actual corrupt dll, is that if you view your compiled view dll in ildasm.exe, and examine the actual method call involving the lamda, you get a "[SIGNATURE ENDED PREMATURELY]" error shown in ildasm. RedGate's reflector, however, crashes when trying to expand the method.

In our case, the ildasm looks like this:

IL_029f:  call class [System.Core]System.Linq.Expressions.Expression`1<!!0> [System.Core]System.Linq.Expressions.Expression::Lambda<class [System.Core]System.Func`2<class [MyCode.Authentication.Admin.Mvc]MyCode.Authentication.Admin.Mvc.Dto.InternalUserDto,object>>(class [System.Core]System.Linq.Expressions.Expression, class [System.Core]System.Linq.Expressions.ParameterExpression[])
IL_02a4:  call class [System.Web.Mvc]System.Web.Mvc.HtmlHelper [MyCode.Extensions]MyCode.Extensions.System.Web.Mvc.HtmlHelperInputExtensions::CheckBox<[2]>(class [System.Core]System.Linq.Expressions.Expression`1<class [System.Core]System.Func`2<class [MyCode.Extensions]'type parameter'.T,object>> [SIGNATURE ENDED PREMATURELY])

We've noticed this is a 64 bit issue only. We are about to investigate whether this issue still occurs on .Net 4.0. I'll update here when we know.

We are also in the process of seeing if this has been raised as a bug with Microsoft. Again, I'll update here when we know.

[EDIT: having now got to the root cause of the problem]

I thought I'd come back and update this answer.

For us, it turned out that this wasn't a compiler issue at all, but an issue with aspnet_merge. In short, on our 64 bit build boxes, we were using an older, out-of-date copy of aspnet_merge (accidentally) that appeared to work but resulted in these corrupt dlls (in exactly the way you describe). A path had been changed, so our web deployment project was using this wrong version.

Updating the path to aspnet_merge version 3.5 or higher, fixed the problem.

We thought this was a 64bit issue originally because our build boxes were the only 64 bit environment we compiled on (all our dev workstations are 32 bit), and the only one to have this problem. However, the "bitness" was a red herring!

Hope this helps you solve your problem.

Answer 2

That sounds like you are calling a 32bit COM component. You probably either need to run the app in 32 bit mode or change your dependency.

See Scott Hanselman's post for more info.

http://www.hanselman.com/blog/32bitnessAnd64bitnessAndMigratingDasBlogOnIIS7AndASPNETUnderVista64.aspx

Answer 3

Is it possible for you to rule out a serious issue with the server or its software?

By the trace and your comment about line 53, I'd seriously consider something corrupt unrelated to your code i.e. I'd expect any related .net code being triggered to vary the stack in the error.

Answer 4

As this has been my most important source for the past three days of investigation I'll post my solution here.

Similar to others reporting this problem, we have had a successful 32bit deployment environment running TeamCity but are moving to 64bit which is the only place this occurs. It also only appears on specific pages - not "intermittenly" or "randomly" as some are reporting.

After methodically ruling out a whole host of things (predominantly aspnet_merge.exe version and the environment), and finding an MVC page where I could reproduce the problem, I had it down to being a code problem. Other places have also pointed towards lambda expressions being the cause which is somewhat true for us as well. The following code relates to code in views only.

To get to the point, incorrect code or not, this will work on aspnet_merge.exe version 4.x running on 32bit:

Model.MyEvents.Distinct(x => x.CategoryName).Many()

Where as on aspnet_merge.exe version 4.x on 64bit it HAS to be written as:

Model.MyEvents.Distinct((x, y) => x.CategoryName == y.CategoryName).Many()

I am aware the hint is in the name IEquality*Comparer* which logically should take two arguments but the first version will compile and work in a 32bit environment.

I just hope this post will help others in the same situation. I am then sure someone will be able to decipher this and grind it down to an 32-vs-64-bit IntPtr issue of some bizarre sort.

Answer 5

BadgerB in this thread might be on to something:

Am I mistaken or is this error supposed to be caused when a dll is changed in a significant way (the signature of a method call is changed) without recompiling the code that uses the dll to take the new signature into account.

It sounds like the difference between the working and not-working scenarios is the machine/environment used to build the binaries. Could it be that when building with TeamCity on a 64-bit machine, the interface or signature of some method is changing which is then causing this error?

Can you post the full call stack of when this exception occurs? Are there any COM objects or P/Invoke calls to native code? Are you using any native code?

Answer 6

Just putting this out there, in case others find this question.

I had a similar issue, though the error message was slightly different: System.BadImageFormatException: Bad binary signature. (Exception from HRESULT: 0x80131192)

I tracked the problem down to a lambda being passed between a .NET 4.0 web site project and a 3.5 class library after being pre-compiled using aspnet_merge.

The issue only presented after installing VS2012 (and its in place upgrade of .NET 4.0 to 4.5).

The related question “Bad binary signature” in ASP.NET MVC application seemed to be more specific to the issue I found, so I've given a more detailed answer there.

Hope that helps.