In ASP.NET 2.0 we have a new powerful monitoring feature called “Web Events” which help keep track of important events happening during your application’s lifetime, such as the application is starting, is stopping, it has been recompiled, exceptions etc… Web events are consumed by providers (listeners), which read the information packaged with the event and then record the information. Each provider is written to record the Web event data in a different way. For example, one provider might write to the Windows event log, while another might send an e-mail message. We have several built-in Web Events and 3 Providers available, and of course you can build your own using the classes provided in the System.Web.Management namespace; however there are only two events enabled in the rules element: All Errors and Failure Audits. Both are enabled and are subscribed to by the EventLogProvider. In it’s simplest form, for example, you can tell ASP.NET to make an event log entry each time an application starts or shuts down by adding this to the <system.web> section of the web.config file for the application: <healthMonitoring enabled="true" heartbeatInterval="0"> <rules> <add name="Lifetime event logging rule" eventName="Application Lifetime Events" provider="EventLogProvider" /> </rules> </healthMonitoring> The sample code…

After a couple of years working in InternetDev support I’ve seen many different kind of problems reported by customers (different environments, different use of Microsoft technologies and products combined together, different application needs, different customer’s background and technical knowledge etc…), but as one of my favorite authors said, Sometimes they come back, so it happens that sometimes we also get incoming calls for well known problems like memory leaks, high CPU and worker process crashes. Of course there could be many different causes for those problems, but some of them are more likely to affect your application; here is a list of the first things I check when I’m working on a memory leak problem (usually analyzing a memory dump of the faulting application). This is not a complete list (but I promise to update the post if I’ll find something new and interesting) and if you talk to other Support Engineers they might give you a slightly different view on the subject, this is what I found and learnt in my day to day support experience. Application deployed in debug mode This is something we must avoid in a production environment; debug mode is useful during development, but in…