I'm having problems with WaitForDebugEvent EXCEPTION_DEBUG_EVENT

Question

I'm starting an Explorer.exe instance with CreateProcess (flags NORMAL_PRIORITY_CLASS + DEBUG_PROCESS + DEBUG_ONLY_THIS_PROCESS), and then I'm doing this:

procedure FakeDebugProcess; 
var 
  wDebugEvent : DEBUG_EVENT; 
begin 
  fillchar( wDebugEvent, sizeof( wDebugEvent ), 0 ); 
  repeat 
    if WaitForDebugEvent( wDebugEvent, INFINITE ) 
      then 
        begin 
          if wDebugEvent.dwDebugEventCode = EXIT_PROCESS_DEBUG_EVENT 
            then break; 
          ContinueDebugEvent( wDebugEvent.dwProcessId, wDebugEvent.dwThreadId, DBG_CONTINUE ); 
        end;
  until false; 
end;

Everything almost works OK, except I'm getting a lot of EXCEPTION_DEBUG_EVENTs from what appears to be "C:\Windows\System32\rpcrt4.dll"

(AdditionalDetails: EXCEPTION_ACCESS_VIOLATION)

77ea3c00 sub_77ea3c00:                    ; function entry point
77ea3c00 >>mov     [ecx+4], eax
77ea3c03   movsx   eax, bx
77ea3c06   cdq
77ea3c07   sub     eax, edx
77ea3c09   sar     eax, 1
77ea3c0b   mov     [ecx], ax
77ea3c0e   xor     eax, eax
77ea3c10   pop     edi
77ea3c11   pop     esi
77ea3c12   pop     ebx
77ea3c13   pop     ebp
77ea3c14   ret     8

What am I doing wrong? How do I fix it?

I'm using Delphi 7, btw.

Answer 1

Why do you assume there's anything wrong with your code? A debugger gets a first-chance notifications for any SEH exception. You are debugging an enormous amount of code. Not just Explorer.exe, you also get all of the shell extension handlers. There's plenty of crud around, Explorer does its best to stay alive even when those extensions have bugs.

If you actually want to solve this, not a bad idea, then use SysInternals' Autoruns utility and disable any shell extension handler that wasn't made by Microsoft and you don't really need. If you want to test your debugger then try something more innocent like Notepad.exe. Although File + Open brings those shell extensions back.

Answer 2

Your code is fine, testing using other debuggers, like ollydbg, rpcrt4.dll still reports exceptions on attaching to some applications. The only way around this to be define filters(what ollydbg allows the user to do), based on the exception code, then based on the module. Thus if you recieve 0xC0000005(EXCEPTION_ACCESS_VIOLATION), you check for: EIP >= (UINT_PTR)GetModuleHandle("rpcrt.dll") && EIP <= (UINT_PTR)GetModuleHandle("rpcrt.dll") + getModuleSize("rpcrt.dll") (of course getModuleSize is a custom func to get the modules virtualized size from the PE, and UINT_PTR is a type big enough to hold a pointer on your target system), you ignore it, else process the event, though might be require hooks into KiDispatchUserException(this should be the right one, else check NTInternals)