CLR Debugging Scenarios
This topic describes how the common language runtime (CLR) debugging API handles typical debugging scenarios. Note that the CLR supports some scenarios directly and interoperates with current methods to support others.
Out-of-Process Debugging
In out-of-process debugging, the debugger is in a separate process from the process that is being debugged (that is, it is outside the debuggee). This scenario reduces the interactions between the debugger and the debuggee. Therefore, it enables a more accurate picture of the process.
The CLR debugging API supports out-of-process debugging directly. The API handles all communication between the debugger and the managed parts of the debuggee to support managed code debugging.
Although the CLR debugging API is used out-of-process, some of the debugging logic (for example, thread synchronization) occurs in-process with the debuggee. In most cases, this is an implementation detail that should be transparent to the debugger. For more information about thread synchronization, see CLR Debugging Architecture. A disadvantage is that the debugging API cannot be used to inspect crash dumps when it is used out-of-process.
In-Process Debugging
In the .NET Framework versions 1.0 and 1.1, the CLR debugging API supported limited in-process debugging, in which a profiler could use the inspection features of the debugging API. In the .NET Framework 2.0, in-process debugging was replaced with a set of functionality that is more consistent with the profiling API. For more information about these changes, see the stack snapshot and object inspection features in the Profiling Overview.
Remote Process Debugging
In remote process debugging, the debugger user interface is on a separate computer from the process that is being debugged. This scenario can be useful if the debugger interferes with the debuggee when they are running on the same computer, because of limited resources, location dependencies, or bugs that interfere with the operating system.
The CLR debugging API does not support remote process debugging directly. A debugger that is based on the CLR debugging API must still exist out-of-process from the debuggee. Therefore, this solution requires a proxy process on the same computer with the debuggee.
Unmanaged Code Debugging
Because managed code can coexist in the same process as unmanaged code, frequently the user will want to debug both kinds of code at the same time.
The CLR debugging API does not support unmanaged code debugging directly. However, they can coexist with an unmanaged code debugger by sharing the Win32 debugging facilities. Also, facilities are provided to support stepping through boundaries between managed and unmanaged code.
Furthermore, the CLR debugging API provides two options for debugging a process:
A soft-attach option in which only the managed parts of the process are debugged. A debugger that is soft-attached to a process can subsequently detach from the process.
A hard-attach option in which both the managed and unmanaged parts of a process are debugged, and all Win32 debug events are exposed through the debugging API.
Mixed Language Environments
In component software, different components can be built with different languages. A debugger must understand when the code is in a different language so that it can display data in the correct format, evaluate expressions with the correct syntax, and so on.
The CLR debugging API does not provide any direct support for mixed language environments, because the CLR has no concept of source language. A debugger's existing source mapping facilities should enable it to map a given function to the language in which the function was implemented.
Multiple Processes and Distributed Programs
A component program can include cooperating components that are running in different processes or even on different computers throughout a network. A debugger should be able to trace execution logic between processes and computers to provide a logical view of what is going on.
The CLR debugging API does not provide any direct support for multiple process debugging. Again, a debugger that is using the API should provide such support directly, and existing methods to do this should continue to work.