Some time ago, one of our customers reported an odd problem. The support ticket went something like this:

When a user tries to create an alert there is a long pause and is then prompted to login. They enter their credentials but they then receive the following error: "you are not authorised to view this page.

It’s taken a long time to get to the bottom of this one due to a number of red herrings so feel free to skip to the fix at the bottom.

The site in question had recently been moved from another set of servers. The site owners had taken the opportunity to rebrand the site and so our immediate investigations were directed toward the new farm and those customisations.

It quickly became clear that it was a subset of lists in the site that were effected but there was no obvious pattern between them.The "bad lists" included document libraries, news lists and discussion forums and it wasn’t anything simple like the lists with lots of items or a particular file type.

Not long after we started looking into this problem we started having occasional IIS application pool crashes. This obviously took priority so efforts were diverted. To be honest, we weren’t making much progress with either issue until one of our contractors noticed that reproducing the alerts problem triggered a hang on the application pool. If enough people tried to create an alert the application pool would enter a stopped state.

crash

Goggling “A process serving application pool * exceeded time” brings back lots of generic IIS blogs and forums, most of which point to this post on the IIS team blog which describes using DebugDiag to isolate the issue. The dumps pointed us towards an issue with InfoPath forms and in turn this forum post but again this turned out to be a dead end.

 

The Solution

So after a lot of digging we were finally able to work out that the effected lists all had rather complicated views. To give you an example, one of these lists had 64 views, one of which had 12 filters, i.e. column A = XXX AND column B = YYY etc. Deleting that complicated view allowed the user to create alerts.

What’s happening is that the filter creates a CAML query. When that query gets above a certain length (which appears to be about 500 characters) it hangs the application pool. If enough people try the query at the same time, the application pool crashes. To the user this manifests as a long pause followed by being prompted for credentials and then getting “access denied” On the server the application pool is rebooting and reaching and then reauthenticating the user.

So with all this information in hand we logged a fault with Microsoft and they’ve accepted it as a fault. They expect the fix to be included in SP2.