Debugging Thread 0:0 is special

Thread IDs uniquely identify a thread – this certainly holds for user mode threads and should also hold for kernel mode threads. But there is one kind of thread where the ID does not uniquely identify a KTHREAD – the Idle thread.

On a uniprocessor system, there is only one Idle thread and this idle thread will have the thread ID 0 (in process 0). On a multiprocessor system, however, Windows creates one Idle thread per CPU. That makes sense – however, what may be surprising at first is that although all Idle threads have their own KTHREAD structure, all share the same thread ID 0 (CID 0:0). That is, each multiprocessor system will have multiple threads with ID 0, which in turn means that CID 0:0 does not uniquely identify a single thread.

This is easily verified using the kernel debugger on a multiprocessor system (a quad core in this case):

    0: kd!running
    
    System Processors f (affinity mask)
      Idle Processors f
    All processors idle.
    
    0: kd!pcr 0
    KPCR for Processor 0 at ffdff000:
    [...]
    
    	      CurrentThread: 8089d8c0
    	         NextThread: 00000000
    	         IdleThread: 8089d8c0
    
    
    0: kd!thread 8089d8c0
    THREAD 8089d8c0  Cid 0000.0000  Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0
    [...]
    
    0: kd!pcr 1
    KPCR for Processor 1 at f7727000:
    [...]
    
    	      CurrentThread: f772a090
    	         NextThread: 00000000
    	         IdleThread: f772a090
    	         
    0: kd!thread f772a090
    THREAD f772a090  Cid 0000.0000  Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 1
    [...]
    
    ...and so on.
    

Now, the idle threads are usually not of major intest. Still, it is possible that these threads can become relevant – such as when doing certain kinds of analysis such as tracing interrupts. If such analysis groups events by the CID of the thread they were captured on (rather than the VA of the KTHREAD structure), the results for CID 0:0 will be wrong.

Not a big thing. Still, it took me a while to figure out that this was indeed the reason for some of my traces containing timestamps in strange order: The traces had been created on a quadcode machine and I did make the mistake to correlate the events by their CID during later analsis. As a result, the traces of the four idle threads were all mixed up…

Any opinions expressed on this blog are Johannes' own. Refer to the respective vendor’s product documentation for authoritative information.
« Back to home