The ICorDebug API (the API for debugging managed apps) is about 70 total interfaces. Here is how I'd group the interfaces together, along with my random comments about how various interfaces fit into the big picture.
A quick comment about interface versioning:1. ICorDebug is a COM-classic unmanaged interface. Most of the interfaces are derived from IUnknown because we wanted to avoid the diamond-inheritance problem when we needed to add version 2 interfaces. I've left the "Derives From" column blank if an interface derives from IUnknown. 2. Version 2 interfaces have the previous interface's name appended with a version number. (eg, "IFoo2")
I'd roughly partition it into the following groups:
Top-level: ICorDebug + ICorDebug2 are the top-level interfaces which effectively serve as a collection of ICorDebugProcess objects.
Callbacks: Managed debug events are dispatched via methods on a callback object implemented by the debugger:
Process: This set of interfaces represents running code and includes the APIs related to eventing.
Code / Type Inspection: Could mostly operate on a static PE image, although there are a few convenience methods for live data.
Execution Control: Execution is the ability to "inspect" a thread's execution. Practically, this means things like placing breakpoints (F9) and doing stepping (F11 step-in, F10 step-over, S+F11 step-out). ICorDebug's Execution control only operates within managed code.
Threads + Callstacks: Callstacks are the backbone of the debugger's inspection functionality. The following interfaces are related to taking a callstack. ICorDebug only exposes debugging managed code, and thus the stacks traces are managed-only.
Object Inspection: Object inspection is the part of the API that lets you see the values of the variables throughout the debuggee. For each interface, I list the "MVP" method that I think must succinctly conveys the purpose of that interface.
Enumerators: All enumerators in ICorDebug derive from the ICorDebugEnum class and have the same usage semantics. I put the enumerators off into their own group because conceptually, we don't users to focus on them specifically. For example, in a managed wrappers, all the enumerators could be exposed as IEnumerable<T>, and thus wouldn't have their own dedicated types. Not all of these enumerators are implemented.
Deprecated / Never implemented: These are listed for completeness sake. Since they're not used, I'll refrain from commenting about them.
Note that this is not intended to be any form of official documentation. See MSDN for official docs and specs.This is just my random commentary.I may come back and update this in the future.