Examining the interrupt vector bindings

Is there a way I can (in kernel mode) walk through the interrupt vectors and see what ISRs are associated with each of them? I’d like to see if they are shared/exclusive, level/latched, and the ISR address (or at least the name of the driver it is located in).

If you’re curious, here’s the reason I want to do this…

I’ve been trying to get my driver to work correctly with the IBS hardware on my AMD processor, which is capable of generating an interrupt when it has some data. Since I haven’t yet learned how to determine an appropriate interrupt vector to associate with it (it’s not a PnP capable “device” as far as I know), I’m disabling interrupts and just polling the hardware with a timer callback.

The IBS interrupt is controlled by an entry in the local APIC for each processor, which can mask the interrupt or not, and has a vector number to use when unmasked. The IBS hardware always signals an interrupt when it has data, but I set it as masked.

I’ve noticed that before I do this, the APIC entry is set unmasked, with a vector of 35h, which means that some other driver is probably using the IBS and expecting interrupts. When I mask the interrupts in the APIC, I may be messing up that other driver, and that other driver may be doing something with the IBS as well. When I run my driver, so far I have been experiencing a system hangup after a random period of time (a few seconds, usually). I’m wondering if this hangup has to do with interference with this other driver, rather than a programming error in my own driver.

So that’s why I want to know which driver is setting the vector 35 in the APIC.

xxxxx@rolle.name wrote:

Is there a way I can (in kernel mode) walk through the interrupt vectors and see what ISRs are associated with each of them? I’d like to see if they are shared/exclusive, level/latched, and the ISR address (or at least the name of the driver it is located in).

I believe the windbg command “!arbiter 4” will tell you this.

 

I’ve noticed that before I do this, the APIC entry is set unmasked, with a vector of 35h, which means that some other driver is probably using the IBS and expecting interrupts. When I mask the interrupts in the APIC, I may be messing up that other driver, and that other driver may be doing something with the IBS as well. When I run my driver, so far I have been experiencing a system hangup after a random period of time (a few seconds, usually). I’m wondering if this hangup has to do with interference with this other driver, rather than a programming error in my own driver.

And if you find that is the case, then what?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim, I ran the !arbiter 4 in windbg, and I don’t know how to interpret the output. Also, there doesn’t seem to be any information about vector 35h.

Here’s partial output…

DEVNODE ffffaa8a59ffed20 (HTREE\ROOT\0)
Interrupt Arbiter “RootIRQ” at fffff800253825e0
Allocated ranges:
0000000000000000 - 0000000000000000 B ffffaa8a5a11a060
0000000000000001 - 0000000000000001 B ffffaa8a5a11a060
…
000000000000002e - 000000000000002e B ffffaa8a5a11a060
000000000000002f - 000000000000002f B ffffaa8a5a11a060
0000000000000036 - 0000000000000036 ffffaa8a5a118bf0 (ACPI)
…
00000000000001ff - 00000000000001ff ffffaa8a5a118bf0 (ACPI)
Possible allocation:
< none >

DEVNODE ffffaa8a59f62010 (ACPI_HAL\PNP0C08\0)
Interrupt Arbiter “ACPI_IRQ” at fffff8066b2e85e0
Allocated ranges:
0000000000000000 - 0000000000000000
0000000000000000 - 0000000000000000 CB ffffaa8a5a2a3a40
0000000000000000 - 0000000000000000 CB ffffaa8a5b2118d0
0000000000000001 - 0000000000000001 ffffaa8a5b049660 (i8042prt)
0000000000000004 - 0000000000000004 ffffaa8a5b049440 (Serial)
0000000000000007 - 0000000000000007 S ffffaa8a5af58290 (amdgpio2)
0000000000000008 - 0000000000000008 B ffffaa8a5a2a3a40
0000000000000009 - 0000000000000009 S ffffaa8a5a118bf0 (ACPI)
0000000000000022 - 0000000000000022 S ffffaa8a5b34a550 (rt640x64)
000000000000002b - 000000000000002b S ffffaa8a5b35c060 (HDAudBus)
0000000000000036 - 0000000000000036 S ffffaa8a5b20a630 (nvlddmkm)
0000000000000037 - 0000000000000037 S ffffaa8a5b209060 (HDAudBus)
00000000fffffff8 - 00000000fffffff8 ffffaa8a5b3506d0 (USBXHCI)
00000000fffffff9 - 00000000fffffff9 ffffaa8a5b204060 (USBXHCI)
00000000fffffffa - 00000000fffffffa ffffaa8a5b20e060 (USBXHCI)
00000000fffffffb - 00000000fffffffb ffffaa8a5b205060 (amdpsp)
00000000fffffffc - 00000000fffffffc ffffaa8a5b205060 (amdpsp)
00000000fffffffd - 00000000fffffffd ffffaa8a5b200060 (storahci)
00000000fffffffe - 00000000fffffffe ffffaa8a5b20d060 (storahci)
Possible allocation:
< none >

Does this help me track the use of vector 35? Or is there some other command for that?

I found in the windbg help file something about the interrupt vector being the IRQ plus 30h, so perhaps I’m looking for IRQ 5? What I know is that the APIC register shows a vector of 35h (for each of the processors).

I have some question about which core a DriverDispatch routine will run in…

My driver uses the IBS hardware only on a single core, given to it in a DeviceControl parameter. It disables interrupts on that core via the local APIC. The timer Dpc is set to run on that core, so it only accesses the hardware on that core. However, the DispatchRead routine can also access the hardware. I’ve assumed that DispatchRead will run in the same thread context where the user code called a read on the File handle, and that thread is pinned to the same core, therefore DispatchRead will not get moved to a different core. Is this assumption correct, or is it possible for DispatchRead to run in a different core? If so, this could explain the hangup, as I didn’t disable interrupts in the APICs for the other cores.

Or do Dispatch routines run in an arbitrary thread context, so that the affinity of the thread that called Read on the File is irrelevant?

On Jan 23, 2018, at 11:59 PM, xxxxx@rolle.name wrote:
>
> Tim, I ran the !arbiter 4 in windbg, and I don’t know how to interpret the output. Also, there doesn’t seem to be any information about vector 35h.

I do note there are two AMD-specific drivers there – amdgpio2 and amdpsp.

If you go to “Device Manager” and look up “Resources by type”, do you find IRQ 35?
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Mr. Rolle… with all due respect, you’re off in the weeds tinkering with stuff – like how interrupts are implemented – that’s not documented and subject to change by implementation (and not architecture).

You realize there’s one interrupt vector (and henace one KINTERRUPT) per *processor* right? There’s not one globally.

Now that I’ve scolded you sufficiently, I’ll at least answer your specific, practical, architectural question:

Well, yes… for WDM it’s correct, assuming your driver is the one “at the top of the stack” that’s called directly from the I/O Subsystem as a result of an I/O related system service invocation.

Peter
OSR
@OSRDrivers

Threads aren’t pinned to cores unless they are explicitly pinned. So on any
given context switch your dispatchread thread could be moved to a different
core. They do tend to stay where they were, but that is a hope not a
mandate.

Mark Roddy

On Wed, Jan 24, 2018 at 12:04 PM, xxxxx@osr.com
wrote:

> Mr. Rolle… with all due respect, you’re off in the weeds tinkering with
> stuff – like how interrupts are implemented – that’s not documented and
> subject to change by implementation (and not architecture).
>
> You realize there’s one interrupt vector (and henace one KINTERRUPT) per
> processor right? There’s not one globally.
>
> Now that I’ve scolded you sufficiently, I’ll at least answer your
> specific, practical, architectural question:
>
>

>
> Well, yes… for WDM it’s correct, assuming your driver is the one “at the
> top of the stack” that’s called directly from the I/O Subsystem as a result
> of an I/O related system service invocation.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

> Threads aren’t pinned to cores unless they are explicitly pinned

Excellent point, Mr. Roddy, thanks for the pickup.

I was waylaid by the “run in the same thread context”… which is correct. But in the overall context (ha!) of the OP’s question, it’s clear he was implying “same logical CPU”.

Nice one,

Peter
OSR
@OSRDrivers

I’ve never programmed the IBS, but if the if this is in the LAPIC then it’s
just an interrupt vector number (a.k.a. an entry in the IDT). You would dump
this with:

!idt -a 35

For example:

1: kd> !apic
…
Ipi Cmd: 01000000`000008e1 Vec:E1 FixedDel Lg:01000000 edg high
…
1: kd> !idt -a e1

Dumping IDT: 80bea600

e1: 81c2515c hal!HalpX86InterruptIpiService

-scott
OSR
@OSRDrivers

Tim,
First of all, thanks for being so helpful, and for so many of my different posts.
I went into Device Manager, and it does not show anything for IRQ = 35. It shows a subset of the allocated values from !arbiter, both ISA and PCI devices.

I learned some more about windbg, and I ran the following:

lkd> !idt 35

Dumping IDT: fffff8002726f000

35: fffff80025179d88 0xfffff80025905c10 (KINTERRUPT fffff8002592cd50)

lkd> dt nt!_KINTERRUPT fffff8002592cd50
+0x000 Type : 0n22
+0x002 Size : 0n256
+0x008 InterruptListEntry : _LIST_ENTRY [0x0000000000000000 - 0x0000000000000000]
+0x018 ServiceRoutine : 0xfffff80025905c10 unsigned char +fffff80025905c10 +0x020 MessageServiceRoutine : (null) +0x028 MessageIndex : 0 +0x030 ServiceContext : (null) +0x038 SpinLock : 0 +0x040 TickCount : 0 +0x048 ActualLock : 0xffffffffffffffff -> ??
+0x050 DispatchAddress : 0xfffff80025179240 void nt!KiInterruptDispatchNoLock+0 +0x058 Vector : 0x35 +0x05c Irql : 0x5 '' +0x05d SynchronizeIrql : 0x5 '' +0x05e FloatingSave : 0 '' +0x05f Connected : 0x1 '' +0x060 Number : 0 +0x064 ShareVector : 0 '' +0x065 EmulateActiveBoth : 0 '' +0x066 ActiveCount : 0 +0x068 InternalState : 0n0 +0x06c Mode : 1 ( Latched ) +0x070 Polarity : 0 ( InterruptPolarityUnknown ) +0x074 ServiceCount : 0 +0x078 DispatchCount : 0 +0x080 PassiveEvent : (null) +0x088 TrapFrame : (null) +0x090 DisconnectData : (null) +0x098 ServiceThread : (null) +0x0a0 ConnectionData : (null) +0x0a8 IntTrackEntry : (null) +0x0b0 IsrDpcStats : _ISRDPCSTATS +0x0f0 RedirectObject : (null) +0x0f8 Padding : [8] "" lkd\> dx -id 0,0,ffffaa8a6046d380 -r1 (\*((ntkrnlmp!_LIST_ENTRY \*)0xfffff8002592cd58)) (\*((ntkrnlmp!_LIST_ENTRY \*)0xfffff8002592cd58)) [Type: _LIST_ENTRY] [+0x000] Flink : 0x0 [Type: _LIST_ENTRY \*] [+0x008] Blink : 0x0 [Type: _LIST_ENTRY \*] lkd\> uf fffff80025179240 nt!KiInterruptDispatchNoLock: fffff80025179240 488bd4 mov rdx,rsp
fffff80025179243 65488b0c2558640000 mov rcx,qword ptr gs:[6458h] fffff8002517924c 488d8100a0ffff lea rax,[rcx-6000h]
fffff80025179253 483bc4 cmp rax,rsp fffff80025179256 7705 ja nt!KiInterruptDispatchNoLock+0x1d (fffff800`2517925d) Branch

nt!KiInterruptDispatchNoLock+0x18:
fffff80025179258 483be1 cmp rsp,rcx fffff8002517925b 720c jb nt!KiInterruptDispatchNoLock+0x29 (fffff800`25179269) Branch

nt!KiInterruptDispatchNoLock+0x1d:
fffff8002517925d 833dfc681f0000 cmp dword ptr [nt!KiBugCheckActive (fffff8002536fb60)],0
fffff80025179264 7503 jne nt!KiInterruptDispatchNoLock+0x29 (fffff80025179269) Branch

nt!KiInterruptDispatchNoLock+0x26:
fffff800`25179266 488be1 mov rsp,rcx

nt!KiInterruptDispatchNoLock+0x29:
fffff80025179269 4883ec20 sub rsp,20h fffff8002517926d 4889542410 mov qword ptr [rsp+10h],rdx
fffff80025179272 e829fbffff call nt!KiInterruptSubDispatchNoLock (fffff80025178da0)
fffff80025179277 488b642410 mov rsp,qword ptr [rsp+10h] fffff8002517927c 488bce mov rcx,rsi
fffff8002517927f e89c57ffff call nt!HalPerformEndOfInterrupt (fffff8002516ea20)
fffff80025179284 65488b0c2520000000 mov rcx,qword ptr gs:[20h] fffff8002517928d 80792001 cmp byte ptr [rcx+20h],1
fffff80025179291 7774 ja nt!KiInterruptDispatchNoLock+0xc7 (fffff80025179307) Branch

nt!KiInterruptDispatchNoLock+0x53:
fffff80025179293 0f31 rdtsc fffff80025179295 48c1e220 shl rdx,20h
fffff80025179299 480bc2 or rax,rdx fffff8002517929c 482b81c05b0000 sub rax,qword ptr [rcx+5BC0h]
fffff800251792a3 480181385c0000 add qword ptr [rcx+5C38h],rax fffff800251792aa 480181c05b0000 add qword ptr [rcx+5BC0h],rax
fffff800251792b1 4c8bc0 mov r8,rax fffff800251792b4 488b4108 mov rax,qword ptr [rcx+8]
fffff800251792b8 f6400232 test byte ptr [rax+2],32h fffff800251792bc 7413 je nt!KiInterruptDispatchNoLock+0x91 (fffff800`251792d1) Branch

nt!KiInterruptDispatchNoLock+0x7e:
fffff800251792be 33d2 xor edx,edx fffff800251792c0 e87bb6f4ff call nt!KiBeginThreadAccountingPeriod (fffff800250c4940) fffff800251792c5 65488b0c2520000000 mov rcx,qword ptr gs:[20h]
fffff800`251792ce fe4120 inc byte ptr [rcx+20h]

nt!KiInterruptDispatchNoLock+0x91:
fffff800251792d1 8a5106 mov dl,byte ptr [rcx+6] fffff800251792d4 80610600 and byte ptr [rcx+6],0
fffff800251792d8 80790700 cmp byte ptr [rcx+7],0 fffff800251792dc 7529 jne nt!KiInterruptDispatchNoLock+0xc7 (fffff800`25179307) Branch

nt!KiInterruptDispatchNoLock+0x9e:
fffff800251792de 84d2 test dl,dl fffff800251792e0 7425 je nt!KiInterruptDispatchNoLock+0xc7 (fffff800`25179307) Branch

nt!KiInterruptDispatchNoLock+0xa2:
fffff800251792e2 807da902 cmp byte ptr [rbp-57h],2 fffff800251792e6 730b jae nt!KiInterruptDispatchNoLock+0xb3 (fffff800`251792f3) Branch

nt!KiInterruptDispatchNoLock+0xa8:
fffff800251792e8 80612000 and byte ptr [rcx+20h],0 fffff800251792ec e8af2b0000 call nt!KiDpcInterruptBypass (fffff8002517bea0) fffff800251792f1 eb17 jmp nt!KiInterruptDispatchNoLock+0xca (fffff800`2517930a) Branch

nt!KiInterruptDispatchNoLock+0xb3:
fffff800251792f3 b902000000 mov ecx,2 fffff800251792f8 ff153a1e2800 call qword ptr [nt!_imp_HalRequestSoftwareInterrupt (fffff800253fb138)] fffff800251792fe 65488b0c2520000000 mov rcx,qword ptr gs:[20h]

nt!KiInterruptDispatchNoLock+0xc7:
fffff800`25179307 fe4920 dec byte ptr [rcx+20h]

nt!KiInterruptDispatchNoLock+0xca:
fffff8002517930a 0fb64da9 movzx ecx,byte ptr [rbp-57h] fffff8002517930e 440f22c1 mov cr8,rcx
fffff80025179312 488bb5d0000000 mov rsi,qword ptr [rbp+0D0h] fffff80025179319 f685f000000001 test byte ptr [rbp+0F0h],1
fffff80025179320 0f8421010000 je nt!KiInterruptDispatchNoLock+0x207 (fffff80025179447) Branch

nt!KiInterruptDispatchNoLock+0xe6:
fffff80025179326 65488b0c2588010000 mov rcx,qword ptr gs:[188h] fffff8002517932f 80b9c200000000 cmp byte ptr [rcx+0C2h],0
fffff80025179336 7419 je nt!KiInterruptDispatchNoLock+0x111 (fffff80025179351) Branch

nt!KiInterruptDispatchNoLock+0xf8:
fffff80025179338 b901000000 mov ecx,1 fffff8002517933d 440f22c1 mov cr8,rcx
fffff80025179341 fb sti fffff80025179342 e839250000 call nt!KiInitiateUserApc (fffff8002517b880) fffff80025179347 fa cli
fffff80025179348 b900000000 mov ecx,0 fffff8002517934d 440f22c1 mov cr8,rcx

nt!KiInterruptDispatchNoLock+0x111:
fffff80025179351 65488b0c2588010000 mov rcx,qword ptr gs:[188h] fffff8002517935a f70100000008 test dword ptr [rcx],8000000h
fffff80025179360 7405 je nt!KiInterruptDispatchNoLock+0x127 (fffff80025179367) Branch

nt!KiInterruptDispatchNoLock+0x122:
fffff80025179362 e8a9f1ffff call nt!KiRestoreSetContextState (fffff80025178510)

nt!KiInterruptDispatchNoLock+0x127:
fffff80025179367 65488b0c2588010000 mov rcx,qword ptr gs:[188h] fffff80025179370 f70100000140 test dword ptr [rcx],40010000h
fffff80025179376 7414 je nt!KiInterruptDispatchNoLock+0x14c (fffff8002517938c) Branch

nt!KiInterruptDispatchNoLock+0x138:
fffff80025179378 f6410201 test byte ptr [rcx+2],1 fffff8002517937c 740e je nt!KiInterruptDispatchNoLock+0x14c (fffff800`2517938c) Branch

nt!KiInterruptDispatchNoLock+0x13e:
fffff8002517937e e8fde90800 call nt!KiCopyCounters (fffff80025207d80)
fffff800`25179383 65488b0c2588010000 mov rcx,qword ptr gs:[188h]

nt!KiInterruptDispatchNoLock+0x14c:
fffff8002517938c 0fae55ac ldmxcsr dword ptr [rbp-54h] fffff80025179390 6683bd8000000000 cmp word ptr [rbp+80h],0
fffff80025179398 7405 je nt!KiInterruptDispatchNoLock+0x15f (fffff8002517939f) Branch

nt!KiInterruptDispatchNoLock+0x15a:
fffff8002517939a e811e8ffff call nt!KiRestoreDebugRegisterState (fffff80025177bb0)

nt!KiInterruptDispatchNoLock+0x15f:
fffff8002517939f 0f2845f0 movaps xmm0,xmmword ptr [rbp-10h] fffff800251793a3 0f284d00 movaps xmm1,xmmword ptr [rbp]
fffff800251793a7 0f285510 movaps xmm2,xmmword ptr [rbp+10h] fffff800251793ab 0f285d20 movaps xmm3,xmmword ptr [rbp+20h]
fffff800251793af 0f286530 movaps xmm4,xmmword ptr [rbp+30h] fffff800251793b3 0f286d40 movaps xmm5,xmmword ptr [rbp+40h]
fffff800251793b7 4c8b5de0 mov r11,qword ptr [rbp-20h] fffff800251793bb 4c8b55d8 mov r10,qword ptr [rbp-28h]
fffff800251793bf 4c8b4dd0 mov r9,qword ptr [rbp-30h] fffff800251793c3 4c8b45c8 mov r8,qword ptr [rbp-38h]
fffff800251793c7 65488b0c2588010000 mov rcx,qword ptr gs:[188h] fffff800251793d0 0fb64101 movzx eax,byte ptr [rcx+1]
fffff800251793d4 a901000000 test eax,1 fffff800251793d9 753c jne nt!KiInterruptDispatchNoLock+0x1d7 (fffff800`25179417) Branch

nt!KiInterruptDispatchNoLock+0x19b:
fffff800251793db 33d2 xor edx,edx fffff800251793dd b948000000 mov ecx,48h
fffff800251793e2 0f30 wrmsr fffff800251793e4 65488b042570020000 mov rax,qword ptr gs:[270h]
fffff800251793ed 4885c0 test rax,rax fffff800251793f0 7425 je nt!KiInterruptDispatchNoLock+0x1d7 (fffff800`25179417) Branch

nt!KiInterruptDispatchNoLock+0x1b2:
fffff800251793f2 65488b0c2588010000 mov rcx,qword ptr gs:[188h] fffff800251793fb 488b8920020000 mov rcx,qword ptr [rcx+220h]
fffff80025179402 483b8138080000 cmp rax,qword ptr [rcx+838h] fffff80025179409 740c je nt!KiInterruptDispatchNoLock+0x1d7 (fffff800`25179417) Branch

nt!KiInterruptDispatchNoLock+0x1cb:
fffff8002517940b b801000000 mov eax,1 fffff80025179410 b949000000 mov ecx,49h
fffff800`25179415 0f30 wrmsr

nt!KiInterruptDispatchNoLock+0x1d7:
fffff80025179417 488b55c0 mov rdx,qword ptr [rbp-40h] fffff8002517941b 488b4db8 mov rcx,qword ptr [rbp-48h]
fffff8002517941f 488b45b0 mov rax,qword ptr [rbp-50h] fffff80025179423 488be5 mov rsp,rbp
fffff80025179426 488badd8000000 mov rbp,qword ptr [rbp+0D8h] fffff8002517942d 4881c4e8000000 add rsp,0E8h
fffff80025179434 f60505d4290001 test byte ptr [nt!KiKvaShadow (fffff80025416840)],1
fffff8002517943b 7405 je nt!KiInterruptDispatchNoLock+0x202 (fffff80025179442) Branch

nt!KiInterruptDispatchNoLock+0x1fd:
fffff8002517943d e97ed61100 jmp nt!KiKernelExit (fffff80025296ac0) Branch

nt!KiInterruptDispatchNoLock+0x202:
fffff80025179442 0f01f8 swapgs fffff80025179445 48cf iretq

nt!KiInterruptDispatchNoLock+0x207:
fffff80025179447 0fae55ac ldmxcsr dword ptr [rbp-54h] fffff8002517944b 0f2845f0 movaps xmm0,xmmword ptr [rbp-10h]
fffff8002517944f 0f284d00 movaps xmm1,xmmword ptr [rbp] fffff80025179453 0f285510 movaps xmm2,xmmword ptr [rbp+10h]
fffff80025179457 0f285d20 movaps xmm3,xmmword ptr [rbp+20h] fffff8002517945b 0f286530 movaps xmm4,xmmword ptr [rbp+30h]
fffff8002517945f 0f286d40 movaps xmm5,xmmword ptr [rbp+40h] fffff80025179463 4c8b5de0 mov r11,qword ptr [rbp-20h]
fffff80025179467 4c8b55d8 mov r10,qword ptr [rbp-28h] fffff8002517946b 4c8b4dd0 mov r9,qword ptr [rbp-30h]
fffff8002517946f 4c8b45c8 mov r8,qword ptr [rbp-38h] fffff80025179473 488b55c0 mov rdx,qword ptr [rbp-40h]
fffff80025179477 488b4db8 mov rcx,qword ptr [rbp-48h] fffff8002517947b 488b45b0 mov rax,qword ptr [rbp-50h]
fffff8002517947f 488be5 mov rsp,rbp fffff80025179482 488badd8000000 mov rbp,qword ptr [rbp+0D8h]
fffff80025179489 4881c4e8000000 add rsp,0E8h fffff80025179490 48cf iretq

nt!KiKernelExit:
fffff80025296ac0 50 push rax fffff80025296ac1 52 push rdx
fffff80025296ac2 488d442438 lea rax,[rsp+38h] fffff80025296ac7 65488b142538000000 mov rdx,qword ptr gs:[38h]
fffff80025296ad0 488da200420000 lea rsp,[rdx+4200h] fffff80025296ad7 65488b142588010000 mov rdx,qword ptr gs:[188h]
fffff80025296ae0 488b9220020000 mov rdx,qword ptr [rdx+220h] fffff80025296ae7 488b9278020000 mov rdx,qword ptr [rdx+278h]
fffff80025296aee ff70f8 push qword ptr [rax-8] fffff80025296af1 ff70f0 push qword ptr [rax-10h]
fffff80025296af4 ff70e8 push qword ptr [rax-18h] fffff80025296af7 ff70e0 push qword ptr [rax-20h]
fffff80025296afa ff70d8 push qword ptr [rax-28h] fffff80025296afd ff70d0 push qword ptr [rax-30h]
fffff80025296b00 ff70c8 push qword ptr [rax-38h] fffff80025296b03 658b042518700000 mov eax,dword ptr gs:[7018h]
fffff80025296b0b 0fbae001 bt eax,1 fffff80025296b0f 721f jb nt!KiKernelExit+0x70 (fffff800`25296b30) Branch

nt!KiKernelExit+0x51:
fffff80025296b11 0fbae200 bt edx,0 fffff80025296b15 7316 jae nt!KiKernelExit+0x6d (fffff800`25296b2d) Branch

nt!KiKernelExit+0x57:
fffff80025296b17 0fbae000 bt eax,0 fffff80025296b1b 7207 jb nt!KiKernelExit+0x64 (fffff800`25296b24) Branch

nt!KiKernelExit+0x5d:
fffff80025296b1d 480fbaea3f bts rdx,3Fh fffff80025296b22 eb09 jmp nt!KiKernelExit+0x6d (fffff800`25296b2d) Branch

nt!KiKernelExit+0x64:
fffff800`25296b24 6583242518700000fe and dword ptr gs:[7018h],0FFFFFFFEh

nt!KiKernelExit+0x6d:
fffff800`25296b2d 0f22da mov cr3,rdx

nt!KiKernelExit+0x70:
fffff80025296b30 5a pop rdx fffff80025296b31 58 pop rax
fffff80025296b32 0f01f8 swapgs fffff80025296b35 48cf iretq

From this, it appears to me (naively) that vector 35 is not associated with any ISR(s). I surmise that the system boot or the BIOS has 35 reserved for the IBS hardware. I guess that if I somehow programmed the IBS to raise an interrupt (35) and there’s no ISR attached to it, it will be handled by KiInterruptDispatchNoLock, whatever that does (see disassembly above). Since the interrupt mode is Latched, failure to turn off the interrupt line shouldn’t cause an interrupt storm (right?).

I wonder if it would be safe for my driver, instead of using a CustomTimerDpc to poll the IBS hardware, to do IoConnectInterrupt for vector 35, IRQL 5, Level Sensitive?

You?ve dumped the OS interrupt dispatching code. The driver supplied service routine is at 0xfffff800`25905c10.

Not sure why that address doesn?t have a symbolic name though, what does .reload and then !address 0xfffff800`25905c10 say? I?m not sure this will tell you anything, but I?m curious as to who is consuming this interrupt.

-scott
OSR
@OSRDrivers