I've just been working on migrating a staging web site from II6 to IIS8.
IIS8 comes with an option Enable 32-Bit Applications which is a true false flag. The explanation of this flag is:
[enable32BitAppOnWin64] If set to True for an application pool on a
64-bit operating system, the worker process(es) serving the
application pool run in WOW64 (Windows on Windows64) mode. In WOW64
mode, 32-bit processes load only 32-bit applications.
Now if I set this to False my web site stops serving and I get a 500 logging an error message of:
ISAPI Filter
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll'
could not be loaded due to a configuration problem. The current
configuration only supports loading images built for a AMD64 processor
architecture. The data field contains the error number. To learn more
about this issue, including how to troubleshooting this kind of
processor architecture mismatch error, see
Now I guessed that their must be an assembly with x86 flags set, so I followed the instructions from this post using CorFlags to check this. But the all return Any CPU, i.e.
Version : v4.0.30319
CLR Header : 2.5
PE : PE32
CorFlags : 9
ILONLY : 1
32BIT : 0
Signed : 0
There are slight veriations but thats the jist.
So why do I need to set Enable 32-Bit Applications to True?
So I've done some more investigation using Process Explorer (this question helped) and it appears that if I set enable 32-bit applications to False and even though the Corflags says they do not require 32 bit several of the dlls do have an image type of 32-bit:
I believe I've gotten to the bottom of this, eventually!
So it appears that this machine is missing some of the x64 configuration. Particuarly 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 talking with our infrastructuire guys they suggested the best way to get this set up correctly is to "uninstall the .Net 4.0 feature and re-install it" bear in mind this requires a reboot!
Related
I have a windows forms application running on .NET 4 that communicates with a WCF web service. The application is compiled to run with X86 as the platform target. The application was deployed on a network of hundreds of computers, and there are only a couple, that happen to have a windows XP version installed (Microsoft Windows Embedded POSReady 2009, service pack 3 to be more precise) that launch the error "Common Language Runtime detected an invalid program" upon calling the constructor of the WCF proxy class object. In order to isolate the problem, I created a small console application that the only thing it does is to call the constructor of the web service proxy class, like:
ItesWebServiceClient m_webService = new ItesWebServiceClient("BasicHttpBinding_IItesWebService");
And the exception is then thrown:
stacktrace output
The same console app runs on all other computers, even the ones with the same windows version.
We've already tried repairing and re-installing .Net framework on the failing computers but so far nothing fixes it. I also used the PEVerify tool to validate MSIL and ran the code in debug mode (no optimizations) as suggested on other posts.
Is there something I'm missing? could there be a key .Net framework component or hot fix that needs to be installed?
Thanks
Ok it turns out that the person who was re-installing the .Net framework on the machines was always installing the .net client profile version. Uninstalling that version and installing the full .net 4 version solved it.
I have ASP .Net Web Application in C# (no MVC or WebForms) compiled in Release mode for AnyCPU, pdb files are enabled and deployed with application.
When enable 32-bit applications on AppPool has the default value of False the stack trace of the exception has correct line numbers.
When the flag is set to True the stack trace has incorrect line numbers.
Just to make it clear the only thing I change is the value for enable 32-bit applications flag in AppPool configuration of my web application.
I have tried this on two machines:
Windows 8 with IIS 8.5.9600.16384
Windows Server 2008 R2 with IIS 7.5.7600.16385
In my particular case it is OK to just reconfigure AppPool (we have already migrated from x86 to AnyCPU and this obsolete configuration is just a mistake), but I am still interested why does this happen? (may be there is some bug in IIS, I was not able to find this behavior mentioned anywhere).
Update: it seems I have figured it out, but this is a temporary reprieve:
The problems is almost certainly due to code optimization (I have written code in such a way, that rules out other options: jitter reorders functions. This is not a compiler because I do not recompile application between tests).
Most of the optimization is done by jitter, and x86 optimizations are more aggressive than x64 optimizations, thus the difference in resulting code. When Microsoft decides to make x64 optimizations more agressive lines will be broken.
So the answer seems to be:
There are basically two steps of optimization in C#: a compilter (csc.exe, when C# code is translated into IL) and a jitter (when IL is translated in machine code). Jitter does not most of the optimizations (article). Also there is a great post by Eric Lippert about which optimization you might expect.
x86 and x64 jitters do different optimizations (CLR via C# Fourth Edition by Jeffrey Richter, Part V Threading, section Volatile Constructs, page 764)
Thus you can get correct line numbers in x64 (because jitter does not optimize code that aggressively) and x86 (that is more mature).
Summary: I have not found a way to work around it.
I am trying to get a 32 bit WCF library to run on Azure. I've read several posts, like this: 32-bit legacy COM DLLs on Windows Azure, saying that they successfully force IIS to load a 32 bit application.
I added the startup batch file, which also registers a COM, and I see that it is run successfully. The COM is registered and the setting is set to true in IIS manager.
Yet the role keeps recycling and in the Event Viewer I see:
WaIISHost
Role entrypoint could not be created: System.BadImageFormatException: Could not load file or assembly 'file:///E:\approot\bin\wcfAzureWrapperStoryMapping.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'file:///E:\approot\bin\wcfAzureWrapperStoryMapping.dll'
I tried changing the OS from Windows 2008 to Windows 2012, no effect. What is going on?
And the funny part, the base folder contains two folders, x64 and x86. So it's like there is a provision for 32 bit. How do I force these guys to cooperate? I was thinking to rename the folders from the batch file but it's probably not going to work...
UPDATE: funny enough, Task Manager shows IISConfigurator as 32 bit! What's going on, I wonder?
I have an year or so old application which uses Expression Encoder 3 to generate thumbnails. Few of the users are complaining that they are receiving the following exception:
Could not load file or assembly 'Microsoft.Expression.Encoder.Utilities.dll' or one of its dependencies. This application has failed to start because the application configuration is incorrect.
The application contains in itself the required EE3 assemblies in the setup, so as such installation of Expression Encoder is not required.
All these crashes started to occur after the application was upgraded to .net 4.
Any clues on what might be happening?
[EDIT] Was able to reproduce the issue on one of our local systems. We did a clean install of Windows XP. Installed .net 4 and then our app. It crashed with the same exception. We could fix the issue by installing .net 3.5!
I was quick to point fingers at .net 4 backward compatibility.
So the question remains: any clues on what might be happening?
According to this question this seems to be an issue with EE3 itself in that it requires EE to be installed (via the installer) to work properly.
Sadly this also seems to be the case for EE4, according to this thread, due to a codec licence issue.
Sorry :/
Have you looked at MediaFoundation? it might serve as an alternative, although ive never used it myself.
I had similar problems, where it wasn't working on a Windows7 64-bit server.
Here's some things I've learnt:
You must modify your project's build settings so it has a target platform of "x86".
You must ensure that the "Desktop Experience" feature is enabled on the target machine. See this blog.
I've built and installed my service from vs2010 onto a 64bit machine.
My problem comes in when my service references 32 bit dlls (spssio32.dll to be precise) - I get the error in my event viewer : "System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Any help on the matter would be appreciated.
Regards,
Byron Cobb.
Is your service code written in a .NET language? If so, you need to mark it as targeting x86 rather than Any CPU (via Project properties / Build / Platform target).
(By default, .NET code targets Any CPU, meaning that on 64-bit machines it will compile into x64 machine code. Because such 64-bit code can't load 32-bit DLLs, that can lead to failures like the one you're seeing. Where code has a dependency on a 32-bit DLL, it needs to always compile to 32-bit machine code even on 64-bit machines, hence setting the target platform to x86.)
You can use a COM surrogate
http://www.dnjonline.com/article.aspx?id=jun07_access3264
The other variant is to spawn an external 32 Bit server-process and add a .NET remoting interface to it and your 64 bit application, so you can use .NET remoting for interprocess communication.