Freigeben über

Problems with 32-bit ASP.NET 2.0 DLLs on a Windows 2003 Server 64 bit

  • Artikel

Recently I worked on an issue with my customer who had a 64 bit Windows 2003 Server. He told that he installed some software which works on IIS and he started getting "Service unavailable" message for all his websites. All his application pools were crashing. He was seeing the following event logged in the system event viewer:

 Event Type:         Error

 Event Source:      W3SVC

 Event Category:    None

 Event ID:            1039

 Date:                 6/6/2007

 Time:                 4:59:48 PM

 User:                 N/A

 Computer:           SOMETHING

  

 Description:

 A process serving application pool 'DefaultAppPool' reported a failure.
 The process id was '4156'. The data field contains the error number.

 For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.

  

 Data:

 0000: c1 00 07 80               Á..?

The DATA part in the event log gave me the clue to look for the DLL versions getting loading into the Application Pool. Following is the output from the ERR tool for this error code 800700c1:

 C:\>err 800700c1

 # as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0xc1

 # for hex 0xc1 / decimal 193 :

 SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION bugcodes.h

 SQL_193_severity_15 sql_err

 # The object or column name starting with '%.*ls' is too

 # long. The maximum length is %d characters.

 ERROR_BAD_EXE_FORMAT winerror.h

 # %1 is not a valid Win32 application.

 # 3 matches found for "800700c1"

Now, I wanted to check what are the DLLs getting loaded into the application pool. In this case, we were not browsing an ASPX page, so I didn't think to check for the ASP.NET DLL versions are the first place. So, I checked the ISAPI Filters tab in the Website properties. There were some filters listed which were of 64-bit DLLs. Now, I verified the global website properties. There was the ASP.NET_2.0.50727.0 DLL (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_filter.dll) which was shown in RED.

You can guess what I would've done now. Yeah, you are correct. I registered the 64-bit version of ASP.NET with IIS. You can do that by running aspnet_regiis -i from the Framework64\v2.0.50727 folder under C:\WINDOWS\Microsoft.NET.

You can verify the mode in which IIS worker process runs by querying this key from Metabase.

W3SVC/AppPools/Enable32BitAppOnWin64

This should be false to make IIS worker process to run under 64 bit mode. There will be some situation where your website will be using some 32-bit ISAPI filters and you want to host your website on a 64-bit IIS 6.0 server. At that time, you can make W3SVC/AppPools/Enable32BitAppOnWin64 to be true (1) and this would make worker processes to be spawned as a 32-bit process (WoW - Windows on Windows).

cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 true
cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 false

IMPORTANT NOTE : You can't make one application pool serving one website to run under 32-bit and other on 64-bit. All the application pools can be either 32-bit or 64-bit.

The reason why this happened would have been the software the customer is trying to install which would've required ASP.NET 2.0 to be registered with IIS and it had a code to run aspnet_regiis -i from the 32-bit folder. This is just a wild guess, but possible.

MORAL OF THE STORY : Do not install any software on a production server unless you really know what will it do to the existing configurations.

Comments

  • Anonymous
    November 01, 2007
    One of the best posts I've seen on NET. Straight to the point and saved me hours and potentially the grief in going back to client to tell him to change O/S. Can't thank you enough.

  • Anonymous
    December 16, 2007
    Thank you for this great post it solved all off our problems