开发者

Running my web site in a 32-bit application pool on a 64-bit OS

开发者 https://www.devze.com 2022-12-26 05:03 出处:网络
Here is my setup: Dev: - Windows Server 2008 64-bit - Visual Studio 2008 - Solution with 3 class libraries开发者_开发问答, 1 web application

Here is my setup:

Dev: - Windows Server 2008 64-bit - Visual Studio 2008 - Solution with 3 class libraries开发者_开发问答, 1 web application

Staging Web Server: - Windows Server 2008 R2 64-bit - IIS7.5 Integrated Application Pool with 32-bit Applications Enabled

In Visual Studio I have set all 4 of my projects to compile to 'Any CPU' but when I run this web application on the web server with the 32-bit application pool it times out and crashes. When I run the application pool in 64-bit mode it works fine. The production web server requires me to run 32-bit application pool in 64-bit OS which is why I have this configured in this way on the staging web server.

(I considered posting on ServerFault but the server part seems to be working fine. It is my code specifically that doesn't seem to want to run in 32-bit application pool which is why I am posting here.)

Edit: Event View Error

Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b
Faulting module name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdbdf
Exception code: 0xe053534f
Fault offset: 0x0000b727
Faulting process id: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting module path: %12
Report Id: %13


Sadly, I don't think there is any way someone here could have figured this out. Two DLLs I was using came from a downloaded ZIP file and when I went to the properties of those files there was a box that said they had been downloaded off the internet and I had to "unblock" them. Seems the 64-bit app pool did not honor this, but when I dropped to 32-bit it did. Once I "unblocked" the DLLs everything started working just fine.


I had a similar error on an application that I was working on... if I built the assembly to target x86 it worked fine. I only had issues when I targeted "Any CPU".


I guess 64-bit can run both 64-bit and 32-bit code but 32-bit can only run 32-bit code.

If you want to run the code compiled by the 64-bit compiler on 32-bit enabled box, you need to compile your code using a 32-bit compiler.


For each project, try the following:

1) Right mouse click on the project and select Properties.

2) Select the Build tab on left side

3) Select x86 for Platform target

4) Rebuild


I believe that error is indicative of trying to load a 64-bit dll into a 32-bit process. Your projects may all be set to "Any CPU" (or to x86), but I'm willing to bet that you're referencing a 64-bit dll. Are you using any 3rd party libraries for which you've included a 64-bit dll?

It's possible to swap 32-bit/64-bit references on-the-fly depending on the current machine's environment by modifying the .csproj files and using a bit of msbuild script. If you're interested in how this can be done, let me know and I'll post a follow-up.


Your post is a tad confusing.

Any CPU - X64 works?

Any CPU - X64+32bitCompat doesn't work?

If this is the case, it sounds like their is a discrepancy between the libraries being used. Perhaps the runtime is interpreting as x64 but being fed x86 libraries. It is important that they match.

You should create new configurations for both x64 and x86 (or just x86) and deploy them as needed. In my experiences, using 'Any CPU' leads down this bad and ugly road.


In my case, the problem was cause by a wrong version of third party dlls in the bin folder of the client.

I have a version 10.3 and 11.1 of Infragistics installed on my computer. My project have a reference with the version 11.1 but in the bin folder of my client, only Infragistics 10.3 are present.

Because I have both version installed on my computer, I don't have any error when I build the application. The reason is that my can determine where is the good version of Infragistics; in the GAC. But for the customer who don't have Infragistics installed, I receive the same error that in the question of this post.


Same (generic) exception code, but for me the issue occurred if I tried to authenticate using a domain admin user account (to my 32 bit .net 2 app on IIS 7 on 2k8R2). If I created a local user and added them to the Builtin\Administrators group and then logged in with that account the app worked fine. Even though the domain admin user is automatically a member of builtin\administrators. Hopefully that line of thinking and not relying on the domain admin accounts helps someone else.

0

精彩评论

暂无评论...
验证码 换一张
取 消