CLR comprehensive and thorough parsing: production diagnostics improvements in CLR 4

In the common language runtime (CLR) team, we have a team dedicated to providing APIs and services for other people to build diagnostic tools for managed code. The two largest components that we have (in terms of dedicated engineering resources) are the managed debugging and Analysis APIs (icordebug* and icorprofiler*, respectively).

Like other CLR and framework teams, we can only achieve our value by trying to develop applications. For example, the Visual Studio team uses these debugging and analysis APIs for their managed debugger and profiling tools, as well as a large number of Third-party developers using the profiling API to build tools.

In the past 10 years, this area focuses primarily on the functionality of the developer's desktop system, whether for the CLR or Visual Studio: Step through the source code in the debugger to find errors in the code, start the application under Performance Profiler to find a low speed code path, and use the Edit and continue the feature to reduce the time spent in the edit-build-debug cycle, and so on. These tools help to find errors in an application that has been installed on the user's computer or after it has been deployed to the server (in both cases the following will be called production), and many of our Third-party vendors build world-class production diagnostics based on our work.

However, customers and these vendors have also been providing us with feedback emphasizing the importance of further simplifying the error lookup process throughout the lifecycle of the application. After all, the later the time to discover software errors in the application lifecycle, the more costly the fix is.

In response to this type of feedback, we have made a lot of effort and started to extend the scope of our diagnostic API support to the production side of the spectrum, and the CLR 4 (the runtime library supporting Microsoft. NET Framework 4) is the first release of our work results.

In this article, I'll discuss some of the things that we currently think are particularly tricky, the way we're doing this, and the types of tools they provide. Specifically, I'll explain how we developed the debugging API to dump the application crashes and hangs, and I'll explain how we can simplify the process of detecting the suspension for multithreaded problems.

I will also explain how the feature, which has been run by additional profiling tools, can further simplify the process of troubleshooting such situations and significantly reduce the diagnostic time required for problems raised by excessive memory consumption.

Finally, I'll briefly explain how we can simplify the deployment of the profiling tools by eliminating reliance on the registry. The whole article focuses on the types of new tools that work for us, but in order to help you understand how you can take advantage of the work we've published through Visual Studio, I've also discussed some other resources.