none
How to get thread ID for caller to my driver or for thread that invokes an ISR RRS feed

  • Question

  • I wrote a driver that collects data from some MSRs whenever an interrupt occurs.  However, I only want to collect the data when the thread being interrupted is the same thread that told the driver to collect the data.

    When my user thread makes a DeviceIoControl call to the driver, the driver calls KeGetCurrentThread () and stores it.

    When the ISR is called, the driver again calls KeGetCurrentThread ().

    Unfortunately, the thread obtained in the interrupt is not the same as the thread obtained in the Control function.

    This used to work fine under Windows XP, but now on Windows 10 it isn't working.

    Interesting thing, when I run this scenario several times, the thread obtained by the ISR is always the same, while the thread obtained in the Control function is different each time.

    That leads me to suspect that the ISR is getting the driver's own thread, whereas the Control function is getting the caller's user thread.

    If this true, then I need for the ISR to be able to get the thread that was interrupted.  How do I do this?

    Another related question, which core is handling the Control call and the interrupts?  Is it the same core that's running my user code, or is it arbitrary and does it really matter?

    BTW I also tried calling PsGetCurrentThreadId ().  I got the same behavior as above.  The thread ID obtained in the Control function is the same as that returned by GetCurrentThreadID () in the user code.

    So if the ISR can get either the thread handle or the thread ID of the user thread, then I'll be good.

    Thanks for the help.

    Thursday, July 6, 2017 8:38 AM

Answers

  • Interrupts run in an arbitrary thread context which as it sounds means they can be any thread.  In general expecting a specific thread to be interrupted is a very bad design decision.  

    What are you trying to do that you need to do this in the ISR?  There are ways to restrict a thread to a given core, can you use a delay timer with a specific thread locked to a core to do what you want?


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, July 6, 2017 10:54 AM

All replies

  • Interrupts run in an arbitrary thread context which as it sounds means they can be any thread.  In general expecting a specific thread to be interrupted is a very bad design decision.  

    What are you trying to do that you need to do this in the ISR?  There are ways to restrict a thread to a given core, can you use a delay timer with a specific thread locked to a core to do what you want?


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, July 6, 2017 10:54 AM
  • Have you considered that threads can migrate among CPUs -  while MSRs belong to certain physical CPU?

    This used to work fine under Windows XP, but now on Windows 10 it isn't working.

    Yeah. Someone has moved the cheese...

    Interesting thing, when I run this scenario several times, the thread obtained by the ISR is always the same, while the thread obtained in the Control function is different each time.

    which core is handling the Control call and the interrupts?  Is it the same core that's running my user code, or is it arbitrary and does it really matter?

    Which ISR is it? Of your own hardware device, or  timer?

    The CPU that starts handling ioctl call in the kernel side is always the same CPU that called the ioctl in user mode. A KMDF driver must use special callback to receive the call in the original context, otherwise KMDF may switch the CPU (TL;DR).

    -- pa

    Thursday, July 6, 2017 10:56 AM
  • This is interesting, esp. as I don't remember having looked at this problem in July at all.

    To answer your question about why I want to do this, I'm collecting samples from the Instruction Based Sampling (or IBS) MSRs on the AMD CPU that I have.  This is for making a profile of some code that the user thread is running.  I need to be in kernel mode to read the MSRs when the interrupts occur.

    AMD's CodeXL program does a similar thing, but it only filters samples by process, rather than by thread.

    I wanted to filter by thread because my test program is capable of running the profiled code in two different threads each locked to a different core (sharing a single compute unit on the CPU), and I want to profile each thread separately and see how they compete with each other.

    If I want to do this, I believe I need to go through the process of opening a handle to the driver separately for each thread, and sending the Control to set up the sampling for each one.  That way, the ISR will see the driver context for the corresponding core and can do its sampling work.

    When you are saying that it's bad design to expect a particular thread to be interrupted, could you elaborate on this, and does this also apply to expecting a particular process to be interrupted?

    Is there in general any way for an ISR to identify the thread being interrupted in a way that the user code in that thread can get the same value?  Same question about the process.

    Thanks, Don, for any help you can provide.  I'm far from a driver expert, and don't want to have to become one.  I was just interested in getting this driver I wrote to be useful.

    Saturday, December 16, 2017 11:03 PM
  • The ISR can interrupt any thread on the system, not just a specific thread.   If your driver is the one receiving the interrupt your ISR could call the PsGetCurrentXXX calls, but I have never done this and cannot state what the result would be, since there is no value in them.   You can get the CPU using the KeGetCurrentProcessorNumberEx but this again assumes you own the ISR.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Saturday, December 16, 2017 11:13 PM
  • KeGetCurrentThread indeed can be called from ISR. When your profiling interrupt occurs, the CPU may run some other task than any of your user app threads. Otherwise, it should work if you consider that the MSRs belongs to physical CPU and ensure the affinity.

    Regards,

    -- pa

    Saturday, December 16, 2017 11:25 PM