SuspendThread WOW64 suspending in kernel code RRS feed

  • Question

  • From MSDN:

    Suspending a thread causes the thread to stop executing user-mode (application) code.
    What I've found however is that my 32-bit app in Windows 7 running under WOW64, Thread A calling SuspendThread on Thread B can pause it while it's running 64-bit code (which I would expect is not user-mode code). EIP shows the suspended thread stopped at

    73472320 jmp     0033:7347271E

    with its ESP having changed (I know this because, while the ESP is pointing to the same page as that thread's stack, it's got a much higher address than the current stack pointer - I believe RSP has clobbered ESP). If I put a breakpoint at the instruction which the above returns to, and then get the thread to resume, I found that the ESP changes back to the value before the X86SwitchTo64BitMode call (which is the correct stack pointer). I also found that when single stepping into the same function, I can never get that higher address ESP value at any point of the single step. In fact, when single stepping, ESP value never changes before and after the X86SwitchTo64BitMode call.

    Also, I did make sure SuspendThread succeed by checking against (DWORD)-1.

    All of these leads me to believe that the thread is suspended in kernel-mode code.

    What could be causing the OS to suspend a thread while it's running non-user-mode code? How do I prevent that? This is basically preventing me from getting the actual current stack pointer of Thread B. Note that when the app runs outside of WOW64 (on native x86 OS), no such problem exists.

    Wednesday, November 10, 2010 1:50 PM