Didn't notice this behaviour until today when a customer in the hosting environment was experiencing sporadic problems where his web app would just die with Access Denied errors all over the shop. I double checked the environment to make sure that the security was as it should be though I couldn't understand why my diagnostic script would run just fine (write some files, open and update an Access database etc etc) yet his app was failing.

Turns out he was starting a thread in his Global.asax.cs Application_Start() method which would sleep until certain times of the day and then wake up to do some background database tidy up and writing to an XML log file. This was when things just stopped.

Now, in the shared web hosting environment, ASP.NET application web requests are served by ASP.NET impersonating the anonymous user account created for that user and his website. After bit of head scratching I suspected that the thread wasn't running under the impersonated anonymous user account and hence the permissions errors. A quick look at WindowsIdentity.GetCurrent().Name upon entering Application_Start() told me as much and it was the aspnet_wp.exe process account being used. However, because the thread would sleep until certain times of the day his app would run fine for hours and then just suddenly hit the floor.

In a nutshell, when an ASP.NET application starts up, it executes its startup code in the context of the worker process (aspnet_wp.exe or w3wp.exe depending on whether you run 2k or 2k3) account. When the Application_Start() event is fired, it is fired under the worker process identity, not the impersonation account.

So basically his thread was being created and run under the low privileged process account which doesn't have sufficient rights to perform all of the operations it expected to be able to perform.

Something new learned every day