"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, 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

Answer 1

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 2

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

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.