“Bad binary signature” in ASP.NET MVC application

问题:

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, though these are 32 bit XP. Just wondered if anyone had encountered this before, and has any suggestions? Details as follows:

Bad binary signature. (Exception from HRESULT: 0x80131192)

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Runtime.InteropServices.COMException: Bad binary signature. (Exception from HRESULT: 0x80131192)

All projects are set to compile for Any CPU, and are compiled in Release mode. The ASP.NET site is precompiled, and the precompiled build is on a 64 bit Windows 2008 TeamCity build agent. Thanks in advance.

EDIT

We're still plagued by this. I have looked at all the binaries in the website's bin directory using corflags.exe. None has the 32BIT flag set, and all have a CorFlags value of 9 except for Antlr3.Runtime.dll which has a value of 1. The problem only affects certain pages, and it seems to be those which use FluentValidation (including FluentValidation.Mvc and FluentValidation.xValIntegration assemblies). None of these shows anything out of the ordinary when inspected with corflags.exe, and there are no odd looking dependencies revealed by ildasm.

When built locally (32 bit Windows XP) the site deploys and runs fine. When built on the build agents (64 bit Windows 2008 Server) the site displays these errors. The site runs in Integrated Pipeline mode, and is not set to 32 bit.

The stack trace is:

[COMException (0x80131192): Bad binary signature. (Exception from HRESULT: 0x80131192)]
   ASP.views_user_newinternal_aspx.__RenderContent2(HtmlTextWriter __w, Control parameterContainer) in e:\TeamCity\buildAgent\work\605ee6b4a5d1dd36\...Admin.Mvc\Views\User\NewInternal.aspx:53
   System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) +115
   ASP.views_shared_site_master.__Render__control1(HtmlTextWriter __w, Control parameterContainer) in e:\TeamCity\buildAgent\work\605ee6b4a5d1dd36\...Admin.Mvc\Views\Shared\Site.Master:26
   System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) +115
   System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) +240
   System.Web.UI.Page.Render(HtmlTextWriter writer) +38
   System.Web.Mvc.ViewPage.Render(HtmlTextWriter writer) +94
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +4240

回答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.

回答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

回答3:

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?

回答4:

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.

回答5:

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.

回答6:

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.