I'm attaching to a simple program and the new thread breaks at DbgBreakPoint as expected. I'm using x64dbg (32-bit). The problem is, when I go to the Threads window it shows all the threads' EIPs as being within ntdll. If I click on a thread and switch to it it shows in the disassembly that EIP is on the line after calling into WOW64 (syscall). If I put a break on that line and run nothing happens.

What's going on here? How can I switch to a thread and continue single-stepping from where its EIP is actually at?

It doesn't seem to make sense that all the threads would be blocked in the kernel, because this always happens every time I attach, no matter when. It makes no difference whether I suspend the threads or not. On the other hand, if I just put an infinite loop in and then attach, I'm able to gain control at the infinite loop as expected. I guess that must mean that the threads actually are blocking. But why?

What can I do to regain control over the threads considering how I can't just break on the line after the transition to WOW64 (that is, where the kernel returns from the blocking call, back in the 32-bit code)?

  • 2
    Try putting a breakpoint somewhere higher on the call stack. Wow64 is strange and it might show a bogus EIP for threads that are not in user space. – mrexodia May 20 '18 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.