2

We recently upgraded to .Net 4.0 and wrote a custom deployment script for our application that uses the Microsoft.Web.Administration library to do things like create websites and setup app pools. We started testing the code on developer boxes and it seemed to work. Then we noticed that if the dev re-built the application it would stop running and IIS7 would give us this (practically useless) error message:

Server Application Unavailable

The web application you are attempting to access on this web server is currently unavailable. Please hit the "Refresh" button in your web browser to retry your request.

Administrator Note: An error message detailing the cause of this specific request failure can be found in the application event log of the web server. Please review this log entry to discover what caused this error to occur.

If we manually recycle the application pool the app will start right back up. We don't see any events or errors in the Application Log. The pool is set to automatically start and recycle on configuration changes.

We have tried every combination of setting in the app pool, application and ASP.net settings. We have tried running the app pool as different user accounts. We have tried deleting the app pool and the application and re-creating both by hand through the UI and the problem still persists.

It's as if using the Microsoft.Web.Administration library poisons the machine so it will never automatically restart app pools again??!!

We would appreciate any insight or debugging advice. We cant run this on any production systems until we understand what caused this to happen.

Gareth Farrington
  • 123
  • 1
  • 4

3 Answers3

0

Are you calling Site.Stop() by any chance? That does change the autoStart property of the site to false, calling Start() would set it back to true.

To make sure there is no other tricks, you I would recommend copying the file %windir%\System32\Inetsrv\Config\ApplicationHost.config to some backup directory, then run your deployment app, and then Diff both files after that and see the differences, my guess is that you will see some autoStart properties set to false. If that is the case, that is caused because of calling Stop and never calling Start again (before CommitChanges)

Check to see if your code has a pattern of: Site.Stop() ... do changes in memory .... ServerManager.CommitChanges() .... Site.Start()

You will never commmit the last Start that modified it to autoStart

Carlos Aguilar Mares
  • 1,886
  • 13
  • 8
  • That's a good angle of attack, at one point we has something like that. We have a cluster so we don't want any of the machines starting up until everything else is in place. So we stop all the sites in one pass. Then make configuration changes. Then start all machines in a final pass. We have re-created the site by hand and the auto start property is set to true. Diffing ApplicationHost.config against another working machine may reveal something... – Gareth Farrington Jul 27 '10 at 14:50
  • Ok, I merged my ApplicationHost.config with a known working copy from another machine. They are nearly identical now (some of the crypto has to be different). All auto start type settings are as they are on the other machine. I still get the error when I re-build. I'm starting to think it's not IIS or it's in there so deep that it might require a re-install. – Gareth Farrington Jul 27 '10 at 15:32
0

I found this thread while searching for the exact same error description. And I found what was causing it in my case.

I was converting an application from .net 3.5 to 4.0 and after I changed the app-pool from 2.0 to 4.0 this started. It only happened in classic mode not integrated.

In my case I had wildcard http handlers in web.config:

<add name="Wildcard .net 64 bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="bitness64"/>    
<add name="Wildcard .net 32 bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="bitness32"/>

But I had forgotten to change the path to the .net 4.0 directory

so after changing \v2.0.50727\aspnet_isapi.dll to \v4.0.30319\aspnet_isapi.dll the website started behaving normally.

Hope this helps someone.

Thorgeir
  • 116
  • It does seem to be limited to the "classic" mode app pools. We have since switched over to integrated mode. I think your answer is as good as we will get on this. – Gareth Farrington Feb 17 '11 at 17:49
0

Not sure if you've already been through this, but you can't mix .NET 4 and .NET 2 apps in the same application pool. This problem bit us recently. We had to create a new app pool, and assign the new .NET 4 web app to that pool. All the .NET 2 apps reside in the other one.

At that point, everything was happy, and the message you mentioned went away.

Ducain
  • 483
  • 2
  • 10
  • 20