Playing with the debugger x64dbg, I noticed that my application uses multiple threads as shown below:Among them, one thread is certainly used for the window, as the application is a window application.The strange thing is that the EIP never changes.However, moving the window or write in it must change the EIP right? As the thread responsible for the window must run continuously in order to prevent the window from freezing.Can you explain why the EIP never changes? Is it related to x64dbg?Thanks !
Window application - Does the debugger stop the window thread?
debugging
x64dbg's Threads page only refreshes once every two seconds, not nearly fast enough to see much going on in threads that are mostly blocked waiting (such as an application's message loop thread). You can verify that the thread is getting time-sliced by watching the User Time column. Move your window around for several seconds, and you should cause enough application code to run to see the User Time increment.Edit addressing @Duke Nukem's comment:Active debuggers on Windows rely on an event system, so most of them just sit around and don't do anything until an exception, breakpoint, or user interaction happens. These debuggers (WinDbg, VS, etc) won't show any thread state or anything like that while the target is running (you only get that information when the target is broken into). This is where the confusion is coming in for people not familiar with x64dbg. The x64dbg Threads tab isn't tied into the debugging events system, it is just a monitoring tool that periodically scans all the threads in the target (even while it is running) and grabs timing stats and also queries the thread's context in order to display the current instruction pointer.