Monday, May 25, 2015 10:45 AM
Default IIS application pool settings allow for no more than 5 uncaught exceptions within 5 minutes, and when this magic number is reached, the application pool shuts itself down. Uncaught exceptions are somewhat rare for us in the web applications we write because we have frameworks that catch and log errors. Some of our older web applications suffer from uncaught exceptions however, and so does Inmagic Webpublisher on servers where we host clients that use that software.
It used to be that text alerts would wake us up in the middle of the night screaming that sites dependent on Webpublisher were down, and we would remote in to the server to restart the relevant application pool. Well, that was pretty much untenable, so I wrote a script to restart the application pool automatically that would trigger when the application pool's shutdown was recorded in the Windows Application Event Log. A caveat here is that application pools usually shut themselves down for good reason - you shouldn't apply this script as a bandaid if you can fix the underlying causes.
- PowerShell v2 (get current version with
- PowerShell execution policy must allow the script to run (i.e.
Set-ExecutionPolicy RemoteSigned or
Install the Script
- Register a new Windows Application Event Log Source called 'AppPool Resurrector'. Do it manually or use my PowerShell script.
- Put the AppPoolResurrector.ps1 script somewhere on the server, and take note of the name of the application pool you want to monitor.
- Create a new task in Windows Task Scheduler once per application pool you want to monitor
- Trigger is 'On an Event' Event ID: 1000, Source: Application Error, Log: Application
- Action is 'Start a program', Program/script: PowerShell, Add arguments:
-command &" 'c:\path\to\apppoolresurrector.ps1' 'name-of-app-pool' "
Note the script activates to check whether the named application pool is still running, and then proceeds to restart it if necessary. There will be times it is activated by a log event to find that the application pool is fine, probably because the log event was unrelated to the application pool in the first place.