2

We are currently in the progress of migrating multiple sites from a x86 win 2008 to a x64 win 2008. We have copied the config dir from and wwwroot's from the old server to the new server but when we start the server we get a 503 error page and in the event log are 5 warnings and then a error.

Warning:

A listener channel for protocol 'http' in worker process '2060' serving application pool 'SiteAppPool' reported a listener channel failure.  The data field contains the error number.

The xml of the event:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-WAS" Guid="{524B5D04-133C-4A62-8362-64E8EDB9CE40}" EventSourceName="WAS" /> <EventID Qualifiers="32768">5139</EventID> <Version>0</Version> <Level>3</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2011-04-14T11:10:04.000Z" /> <EventRecordID>334493</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>System</Channel> <Computer>WEBSRV64</Computer> <Security /> </System> <EventData> <Data Name="AppPoolID">SiteAppPool</Data> <Data Name="ProcessID">2060</Data> <Data Name="param3">0</Data> <Data Name="ProtocolID">http</Data> <Binary>7E000780</Binary> </EventData> </Event>

We get 5 of those but all with a different worker process number.

After that we get this error:

Application pool 'SiteAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.

We have absolutely no clue why this error happens,, we did an 1 on 1 copy of the site. Currently we are still running on the 32 bit server but we like to migrate asap. Does anyone have a clue why we get this error?

Improve this question

2 Answers 2

Reset to default
1

Could be a lot of things but a few things jump to my mind :

  • Was the old site using a different ID for the application pool, perhaps a local machine user? If so, it could be something internal to the application itself that isnt handling the new ID properly.
  • Is the proper version of the .Net Framework installed on the new machine?
  • Have you compared the old and new application pools point-by-point using the Advanced Settings view?

If you create a new site/application pool and accept the default settings, does it still do this for the new site?

Improve this answer
8
  • @dave what do you mean with different ID,, where to find the ID? or do you mean the name?
    – SynerCoder
    Apr 14, 2011 at 13:12
  • The user ID that the application pool runs as.
    – Dave Wise
    Apr 14, 2011 at 13:13
  • @dave can you then give a example of why the application could not handle it propperly?
    – SynerCoder
    Apr 14, 2011 at 13:21
  • Some applications install modules in the http pipeline and if those modules do anything that leaves the server, like calling a database, then that would fail and things breaking in the pipeline lead to sometimes strange errors
    – Dave Wise
    Apr 14, 2011 at 13:32
  • I'd actually be interested to see if you can create a new functional site and pool just using the default settings. If not, then it might be that something came over in the /inetsrv/config that shouldn't have been copied.
    – Dave Wise
    Apr 14, 2011 at 13:35
0

It's likely a component in your site that isn't compatible with x64. It could be an isapi filter or possibly some managed code or a COM+ call.

If it fails right away for an http request then it's likely an isapi filter. You can confirm by disabling all filters and testing a test.html page. Then add things back until it fails again.

You have 2 solutions:

  • Easiest: run your app pool in 32 bit mode. That's a good setting anyway. You can set it from the app pool advanced properties, one of the top options. Set it as an app pool default and future app pools will also be set that way. In IIS7, you can leverage the high memory of x64 while still running app pools in 32-bit mode.
  • Alternately, once you narrow down the component in question, get an update from the vendor.
Improve this answer
3
  • it is a clean IIS installation and we copied the config folder from the 32bit to 64bit. windows folder/system32/inetsrv/config folder.
    – SynerCoder
    Apr 14, 2011 at 13:11
  • 1
    I'm not positive if that will work or not. What I would test then is if a new app pool and site will serve up correctly. This will let you know if the general upgrade worked, or if the failure is related to your particular app pool and site. You may be able to narrow it down to a single reference in the Program Files folder vs. Program Files(x68) or something like that. Otherwise, what I suggest is to start over and use MSDeploy, which will take care of the bitness conversation, or manually copy your <sites>, app pools and location sections manually. That will get most settings.
    – Scott Forsyth
    Apr 14, 2011 at 14:38
  • Yeah, don't do that. Like Scott says, migrate it using the catchily-titled Web Deployment Tool or similar - 32 and 64-bit configs don't usually look the same, and the 64-bit version is built with a bunch of preconditions and helpful bitness-management settings built in.
    – TristanK
    Apr 14, 2011 at 23:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .