Doubting about the Threads window of visual studio

Question

As you can see above , there are 4 win32 threads at exactly the same location, how to understand it? UPDATE

7C92E4BE  mov         dword ptr [esp],eax 
7C92E4C1  mov         dword ptr [esp+4],0 
7C92E4C9  mov         dword ptr [esp+8],0 
7C92E4D1  mov         dword ptr [esp+10h],0 
7C92E4D9  push        esp  
7C92E4DA  call        7C92E508 
7C92E4DF  mov         eax,dword ptr [esp] 
7C92E4E2  mov         esp,ebp 
7C92E4E4  pop         ebp  
7C92E4E5  ret              
7C92E4E6  lea         esp,[esp] 
7C92E4ED  lea         ecx,[ecx] 
7C92E4F0  mov         edx,esp 
7C92E4F2  sysenter         
7C92E4F4  ret        

Answer 1

At a guess, they're probably sleeping in something like WaitForSingleObject or similar.

Answer 2

At a guess, you have a thread pool of some sort, so you have four threads all executing the same thread function. In this case, all four are mostly likely idle, waiting for a task they need to execute. If that's the case, it's quite sensible that all four show the same location.

Answer 3

You'll need to ignore the threads that are started by Microsoft code. I'm guessing at mmsys or DirectX from your screen shot. Microsoft code is very thread-happy.

You can get better diagnostics about what they do when you enable the Microsoft Symbol Server. You'll get decent names in the Call Stack window, often letting you guess what their purpose is. Of course, you'll never get to look at their code.

Answer 4

The debugger shows the next ring3 processor instruction that is going to be executed. In this case the thread has called sysenter, which makes a ring0 system call to the operating system's kernel. This kernel system call is waiting for something to happen before returning control back to the calling code. Once that something happens, then it will call the next user-mode instruction, which in this case is ret.

If you have 4 threads that are all calling the same function that waits for a system call at the same location, you will have 4 threads that show the same address in the Threads window. This is something that you will see quite often in applications built with the Windows subsystem, which usually have a number of threads that are started by the Windows API that spend most of their time waiting for kernel events.