New
#1
How to find an available interrupt vector that doesn't conflict.
I have a kernel driver that has an ISR for some hardware. I need to find an interrupt vector so that I can program the hardware to use that vector and I can tell Windows to call my ISR when the interrupts occur.
My strategy is as follows: I use IoConnectInterrupt with various combinations of parameters until I get a successful return. The combinations I use are, in order of choices:
- not shared, shared
- Latched, Level Sensitive
- vector from 50h ... FEh
- DIRQL from 0 to 9.
The driver gets the first success for not shared, Latched, vector 80h, DIRQL 0.
I changed the driver to try shared first, then it got shared, Latched, vector 80h, DIRQL 0.
The result is that after I enable the hardware for vector 80, I do get some interrupts. The ISR keeps an interrupt count which the client program can get from the driver. However, after a short period of operation, the entire system hangs -- nothing new showing on the console window, no mouse, no keyboard (not even ctrl-alt-del).
Obviously, this particular choice of interrupt parameters is interfering with some other device on the system.
When I change the driver so that it does not enable interrupts by the hardware, everything works fine. The client program gets no data from the driver, of course, and it keeps on trying forever.
My question is: What method do you recommend for selecting these parameters for IoConnectInterrupt, or some other method of hooking the ISR to a vector?
Perhaps using Hal routines?
My method doesn't seem right, even with shared access, because some other driver might later want exclusive access to the same vector and fail to get it. So there should be a better way of arbitrating vector usage.
Please help. Right now my project is dead in the water. Thanks.
Last edited by mrolle; 26 Dec 2017 at 16:37.