How to track down errors when Azure web role starts up?

Question

I habe a web role in azure. It is running fine locally in development app fabric, but fails silently when deployed to Azure (simply no response at all for any request).

I assume it's some problem with the web.config, but that is happening so early that it occurs already before I can set up the diagnostic stuff in global asax. As said, it's working fine locally, but there is simply no response at all from the azure system.

How can I find out what specifically is wrong to be able to solve it like get the exception text, stack trace, IIS application system error log or anything that could hint me to the real problem?

Answer 1

The absolute first thing that is run in a Web role is not your application but the OnStart() method in WebRole.cs in your Azure project. This is the place to add code to monitor your Web site.

The standard technique is to copy your application trace logs and the Windows event logs to Azure table storage, together (if appropriate) with instrumentation for CPU usage, IIS statistics and what-have-you.

A good introduction to this is here: http://blog.bareweb.eu/2011/01/beginning-azure-diagnostics/

and a good followup with details on the specifics you'll need in your application is here: http://blog.bareweb.eu/2011/03/implementing-azure-diagnostics-with-sdk-v1-4/

which remains applicable for the Azure SDK 1.5.

Once you are capturing diagnostics, you can either use Visual Studio to view them directly, or you can use a tool like the Cerebrata Azure Diagnostics Manager to graph and filter them automatically. This tool is a little rough around the edges (especially for larger systems with multiple instances: the graphs aren't really useful) but is as good as it gets at the moment.

---

An alternative approach is to use Remote Desktop to connect to the remote instance and do some spelunking in the Windows event logs and suchlike. You can also use the Internet Explorer browser that's on the remote instance to directly connect locally to the application and see any errors etc. that may otherwise be hidden.

Personally I'd only do this if the diagnostic storage mechanism isn't working: production servers really should have remote desktop access turned off altogether to reduce the possible surface area for external attack.