none
Issues in user mode process debugging from kernel debugger. RRS feed

  • Question

  • Hi, 

    I am trying to debug a thread in user mode application from an attached kernel debugger. First i change the context using .process /i <eproc> command to the application i want to debug and then issue following command 

    kd> bp /t 8944f7c0  ntdll!ntclose

    ntdll!NtClose:

    001b:77c65ef4 b874010000      mov     eax,174h
    001b:77c65ef9 e803000000      call    ntdll!NtClose+0xd (77c65f01)
    001b:77c65efe c20400          ret     4
    001b:77c65f01 8bd4            mov     edx,esp
    001b:77c65f03 0f34            sysenter
    001b:77c65f05 c3              ret
    001b:77c65f06 8bff            mov     edi,edi



    My expectation was that the windbg will break when ntclose will be called in the context of the thread.

    However i am seeing following single step exceptions coming from other processes like services.exe , csrss.exe etc. I have confirmed that DR registers are not set.

    Single step exception - code 80000004 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    ntdll!NtClose+0x5:
    001b:77c65ef9 e803000000      call    ntdll!NtClose+0xd (77c65f01)

    I am not sure why this is happening (almost looks like windbg is inserting 'int 3' globally ? How can i get past the single step exceptions? I tried 'gn' with no success.

    Thanks in advance.

    Wednesday, March 13, 2013 6:32 PM

All replies

  • Have you already tried 
    bp /p <EPROCESS> /t <ETHREAD> ntdll!NtClose
    Some useful information:
    Analyst's Perspective: Analyzing User Mode State from a Kernel Connection
    http://osronline.com/article.cfm?id=576&nocache=1

    With kind regards

    Wednesday, March 13, 2013 9:01 PM
  • almost looks like windbg is inserting 'int 3' globally

    Absolutely.

    The thread and process specific breakpoints are evaluated on the host. So, you set the breakpoint globally and when it's hit the debugger gets control, checks the thread, and resumes if there isn't a match. I find that I get similar behavior to yours when I try to do a thread specific breakpoint on a very hot code path (such as CloseHandle).

    -scott


    OSR Online

    Tuesday, April 2, 2013 9:04 PM
  • I am just wondering, why I get different behaviour, when doing
    bp /t <ETHREAD> ntdll!NtClose
    and
    bp /p <EPROCESS> /t <ETHREAD> ntdll!NtClose
    Using first one, also notifications for other processes show up, but the second one seems to behave 'better'.
    Are not threads always process-bound? 

    With kind regards

    Tuesday, April 2, 2013 11:26 PM
  • Threads can certainly attach to other processes and run in their context, though that's not terribly common. You're really just bumping into the standard issues you have when you try to set a breakpoint on a hot function. For something like this, better to set a breakpoint on the call site(s) or import address (http://www.osronline.com/article.cfm?article=522).

    -scott
    OSR


    OSR Online

    Wednesday, April 3, 2013 7:07 PM
  • Ah I see, this may avoid 'one or other' break.

    Thanks a lot for your advice

    Thursday, April 4, 2013 9:31 AM