Instant debugging
The ability to connect the debugger to any process at any time is called immediate debugging (Just-in-timedebugging). Here we have a little more explanation about it: When the programmer clicks the Cancel button, tell the UnhandexceptionFilter function to debug the process.
Internally, UnhandexceptionFilter calls debugger, this needs to be viewed below the registry keyword:
HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Windows NT / CurrentVersion / Aedebug
In this subkey, there is a value called debugger, and is set to the following value when installing VisualStudio:
"C: / Program Files / Microsoft Visual Studio / Common / MSDEV98 / BIN / MSDEV.EXE" -p% ld -e% ld
Windows98 In Windows 98, these values are not stored in the registry, but stored in the Win.ini file.
This line of code is to tell the system which program (here is MSDEV. EXE) as the debugger run. Of course, other debuggers can also be selected. UnhandledExceptionFilter also passes two parameters to debug programs in this command line. The first parameter is the ID of the debugged process. The second parameter specifies an inherited manual reset event, which is established by UnhandexceptionFilter. Vendors must implement their debuggers so that they can recognize the -p and -e options for the specified process ID and event handle.
After the process ID and event handle are merged into this string, UNHANDEXCEPTIONFILTER performs debugging programs by calling createProcess. At this time, the debugger process starts running and checks its command line parameters. If there is a -P option, the debugger gets the process ID and hooks itself on the process by calling debugactiveProcess.
Bool DebugActiveProcess (DWORD DWPROCESSID);
Once the debugger completes its own hook, the operating system will report the status of the debuggee to the debugger.
After the debugger is fully initialized, it will check its command line and find the -e option. If this option exists, the debugger acquires the corresponding event handle and calls setEvent. The debugger can directly use the handle value of the event because the event handle has created inheritability, and the debug process to the unhandledExceptionFilter function call also makes the debug program process into a child process.
Setting this event will wake up the thread of the debugged process. Wake-up threads pass the information about untreated exceptions to the debugger. The debugger receives these notifications and loads the corresponding source code file, and then put itself in the instruction position that causes an exception.
Also, you don't have to wait for an abnormality before debugging the process. You can always connect a debugger on any process, just run "MSDEV-PPID", where the PID is the ID of the process to be debugged. In fact, use Windows2000 TaskManager, it is easy to do. When you observe the Process taglet, you can select a process, click the right mouse button, and select the debug menu option. This will cause TaskManager to see the registry sub-keywords discussed earlier, call CREATEPROCESS, and pass the ID of the selected process as a parameter. Here, TaskManager transmits 0 values for event handles.
