The mysterious problem with WebResource.axd
I have tried to figure out why a customer get a strange error message on their ASP.NET web site that stops the whole site from working until you restart the whole IIS.
The exception “The WebResource.axd handler must be registered in the configuration to process this request” occurred quite randomly at first sight. After some investigations I found that the site usually stopped working if you called some of the pages immediately after a restart of the web application. This happens for example when you change in web.config but an unload of your AppDomain can be triggered by other mechanisms, too.
I found no clues to the cause when I searched on the error message, only a lot of question and other desperate people.
Looking closer at the call stack and browsning around with Roeders Reflector I found that the cause of our problem with WebResource.axd is in the method EnsureHandlerExistenceChecked in the class System.Web.Handlers.AssemblyResourceLoader:
As you can see in the code above, if the test fails once it will never re-test since handlerExistenceChecked is true and the site will stop working forever.
The only way to recover from the error I have found is to stop the site, run iisreset /restart and wait for a while before you start the site again.
I have not manage to find the exact reason for why the test fails initially. I have some theories but they are hard to validate since used classes and methods are private or internal. One guess is that FindMapping returns null because the HttpHandler collection has not yet been loaded. Another guess is that HttpHandlerAction has not been correctly initialized so TypeInternal is null. It could even be possible that there is a problem with the type system (because ASP.NET applications unloads the AppDomain, generat assemblies dynamically and loads them, etc) so you actually have two instances of the same underlying system type making the Equal operator give an incorrect result.
It really does not matter why it does not work since we can not patch Microsoft’s framework ourself or wait for a hot fix. If anyone else has some clues or have done some research on this problem, please let me know!
My workaround to recover from the error is to use reflection to clear one of the private static flags so it re-runs the test. (Use of reflection like the requires that your application does not run with a low trust level so it might not work everywhere.) Since it is expensive to use reflection I only run the check in the Error event handler in my Application object.
Any feedback is appreciated.