Why does my site require "Enable 32-bit applications"?

Question

I just worked on porting an intermediate website from II6 to IIS8.

IIS8 comes with the option to Enable 32-bit applications , which is the true flag. Explanation of this flag:

[enable32BitAppOnWin64] If the application pool is set to True 64-bit operating system, the workflow (s) serving the application pool starts in WOW64 mode (Windows on Windows64). In WOW64 mode, 32-bit processes load only 32-bit applications.

Now, if I set this to False , my website stops serving, and I get a 500 message with an error message:

The ISAPI filter 'C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ aspnet_filter.dll' could not be loaded due to a configuration problem. Electric Current Configuration supports loading images created for the AMD64 processor architecture. The data field contains the error number. To learn more about this problem, including how to fix this problem, processor architecture mismatch error, see

Now I guessed that they should be an assembly with x86 flags set, so I followed the instructions from this post using CorFlags to verify this. But everyone returns Any CPU , i.e.

 Version : v4.0.30319 CLR Header : 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 0 

There are minor verification, but this is a trick.

So why do I need to set Enable 32-Bit Applications to True ?

So, I did some more research using Process Explorer (this is a question ), and it seems that if I configure to allow 32-bit applications to False , and although Corflags says they don't require 32 bits, some of the DLLs are 32 image type -bit:

Answer 1

I believe that I reached the end, in the end!

So it looks like some x64 configuration is missing on this machine. In particular, the "ISAPI Filters" configuration contained the standard .net 4 aspnet_filter.dll (C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ aspnet_filter.dll), but not the x64 version (C: \ Windows \ Microsoft. NET \ Framework64 \ v4.0.30319 \ aspnet_filter.dll)

From conversations with our infrastructure partners, they suggested the best way to properly configure this setting: "remove the .Net 4.0 function and reinstall it," remember that this requires a reboot!