How script debugging works

There are a couple of players in client side script debugging:

• Script host (example: wscript.exe, mshtml.dll or asp.dll). This is the application that wants to run script. The host is responsible for giving the text of documents to the debugger and it helps map text to a particular document.
• Script engine (jscript.dll/vbscript.dll). This is responsible for interpreting the stream of script statements. The debugger will ask it to stop on a particular script statement, and it will ask it to evaluate script expressions. The host will give it script text and tell it to run it.
• Process Debug Managed (pdm.dll). This is a dll written by the debugger team. It runs inside of the script process. Its job it to keep track of script code, and to marshal calls from the debugger to threads running script code.
• Script process listing (mdm.exe or shared memory). This is a list of all the script processes on the computer and a DCOM interface into the process. In the past, this was done by the Machine Debug Manager (mdm.exe). In Whidbey, we have removed mdm.exe, so this is now implemented with shared memory.
• Script Debug Engine. This communicates between the process debug managed and the debugger UI. It determines where to set a breakpoint, when we should ask the script engine to stop, what to do when we do stop, etc.

As you can see, there are many components involved here. These components come from different products, and don't ship together. You can read more about it on MSDN.