I used the debugger sample code from MSDN, and created a very simple console debugger demo from it. However I have a problem to handle Exceptions.

I firstly used CreateProcess with DEBUG_PROCESS to create the process. Then call WaitForDebugEvent with EXCEPTION_DEBUG_EVENT, later I just ignore all kinds of exceptions by using ContinueDebugEvent with DBG_CONTINUE. However, when I used this console to open some windows applications like wmplayer.exe(not all the time). It will trigger some write access violation at the beginning. But wmplayer.exe surely can handle it well. Because I can prove that using well-known debuggers like windbg or ollydbg to see that. But my console just keeps geting this write access vioaltion all the way to then end(WaitForDebugEvent keeps returning the same exception for ever). It seems that it encounters an infinite loop and never ends. The calling of ContinueDebugEvent with DBG_CONTINUE doesn't seem to be able to ignore this exception. Is there anything wrong in the way I am doing it? Should I add more handling steps to make it work?

Thanks a lot for your help!

i dont know if this could be the problem but always start your debugger code with DEBUG_ONLY_THIS_PROCESS instead of DEBUG_PROCESS its simpler childs and other events dont come to your debugger

ollydbg is DEBUG_ONLY_THIS_PROCESS only and doesnt ever handle other events
WINDBG is DEBUG_THIS_PROCESS_ONLY by default unless one forces it to be DEBUG_PROCESS with commandline args , or dynamically using extensions

also if you dont shun asm coding take a look at iczelion's tutorial ~ 17,18,19 there is a basic debugger code in there thats bare bones and easy to understand

I tried but didn't work. does ollydbg use ContinueDebugEvent with DBG_CONTINUE to bypass the exception (Shift-F9). I don't clearly understand the difference between DBG_CONTINUE and DBG_EXCEPTION_NOT_HANDLED. which one does Ollydbg use when typing Shift-F9 to bypass the exception?

resolved. Iczelion's tut is great

"If you specify DBG_CONTINUE, the thread will ignore its own exception handling and continue with the execution. In this scenario, your program must examine and resolve the exception itself before resuming the thread with DBG_CONTINUE else the exception will occur again and again and again.... If you specify DBG_EXCEPTION_NOT_HANDLED, your program is telling Windows that it didn't handle the exception: Windows should use the default exception handler of the debuggee to handle the exception. "

Thx blabberer for the good reference.