views:

732

answers:

3

I want to know which threads processes device interrupts. What happens when there is a interrupt when a user mode thread is running? Also do other user threads get a chance to run when the system is processing an interrupt?

Kindly suggest me some reference material describing how interrupts are handled by windows.

+1  A: 

Like any other operating system, Windows processes interrupts in Kernel mode, with an elevated Interrupt Priority Level (I think they call them IRPL's, but I don't know what the "R" stands for). Any user thread or lower-level Kernel thread running on the same machine will be interrupted while the interrupt request is processed, and will be resumed when the ineterrupt processing is complete.

John Saunders
Actually it is IRQL (Interrupt ReQuest Level). There are 32 of them. User mode code operates in PASSIVE (0) level. Devices IRQL/DIRQL are higher that DISPATCH (2) level.
dragonfly
You've probably remembered that the internal representation of a system call that is delivered to a device driver is called an IRP (I/O Request Packet)...
RBerteig
I shouldn't answer questions so late at night. I was remembering from the VMS operating system, where they are called IPL - Interrupt Priority Levels. Reverting to my technical childhood.
John Saunders
A: 

In order to learn more about device interrupts on Windows you need to study device driver development. This is a niche topic, I don't think you can find many useful resources in the Web and you may have to look for a book or a training course.

Anyway, Windows handle interrupts with Interrupt Request Levels (IRQLs) and Deferred procedure calls. An interrupt is handled in Kernel mode, which runs in higher priority than user mode. A proper interrupt handler needs to react very quickly. It only performs the absolutely necessary operations and registers a Deferred Procedure Call to run in the future. This will happen, when the system is in a Interrupt Request Level.

kgiannakakis
+1  A: 

Device interrupts themselves are (usually) processed by whatever thread had the CPU that took the interrupt, but in a ring 0 and at a different protection level. This limits some of the actions an interrupt handler can take, because most of the time the current thread will not be related to the thread that is waiting for the event to happen that the interrupt is indicating.

The kernel itself is closed source, and only documented through its internal API. That API is exposed to device driver authors, and described in the driver development kits.

Some resources to get you started:

  • Any edition of Microsoft Windows Internals by Solomon and Russinovich. The current seems to be the 4th edition, but even an old edition will help.

  • The Windows DDK, now renamed the WDK. Its documentation is available online too. Be sure to read the Kernel Mode Design Guide...

  • Sysinternals has tools and articles to probe at and explain the kernel's behavior. This used to be an independent site until Microsoft got tired of Mark Russinovich seeming to know more about how the kernel worked than they did. ;-)

Note that source code to many of the common device drivers are included in the DDK in the samples. Although the production versions are almost certainly different, reading the sample drivers can answer some questions even if you don't want to implement a driver yourself.

RBerteig