There are a lot of different ways to troubleshoot ASP.NET issues.  I have gone over most of the things you can do with a dump that has been captured from the process.  But there is another way to get useful information out of a process and that is by using a profiler.

There are a number of profilers that are available for .NET applications.  Some of the more popular ones include (most come from Brads post and there is a good list here as well):

Traditional Performance and/or Memory Profilers

Enterprise Health Monitors

The drawback with any of these profilers is that it has to be enabled prior to the process starting up.  So it is very difficult to use these to analyze a web server.

Note: SciTech has the following on their website (but I haven’t actually tested it out) - A wizard is also provided for connecting the profiler to already running processes, or to import memory dump files. This is especially useful when profiling problems in a production application.

With .NET 4.0, this will change as profilers are allowed to attach to a running process.  This will make profiling much better when dealing with ASP.NET.  Check out David’s blog for more info on that.

I have used some of these and have had my own experiences with them but I really want to hear what you guys think.

Some questions I have for you guys in regards to profilers:

  1. Do you use a profiler against your code?
  2. Which profiler(s) have you used?
  3. How much success do you have with it?
  4. Are you thinking of using a profiler to help track down any issues?
  5. What features do you think would be really useful for a profiler to have?
  6. What drawbacks keeps you from using a profiler?
  7. Would you consider running a type of profiler against your application in development if it helped you to get a better idea of performance or potential issues with your code?