如何在Windows KMDF中注册软件中断？Win10 x64相关技术咨询

Hey Jason, let's walk through each of your questions clearly—this is a pretty low-level, restricted area of Windows kernel development, so we’ll cover both the technical how-tos and the critical risks involved:

1. How to register a software interrupt in Windows KMDF? #

First off, KMDF doesn’t provide any built-in, public APIs for registering custom software interrupts. Software interrupts (triggered via INT n instructions) are tightly controlled by the Windows kernel, with most vectors reserved for system use. That said, if you’re determined to implement this (knowing the risks we’ll cover later), here’s the general approach using manual IDT (Interrupt Descriptor Table) manipulation:

• Retrieve the IDT base address: You’ll need the unexported KeGetInterruptDispatchTable() function to get a pointer to the system’s IDT. In KMDF, you can resolve this function via MmGetSystemRoutineAddress() (avoid hardcoding offsets, as they change between Windows versions).
• Modify the target interrupt gate: Pick an unused interrupt vector (verify it’s not occupied by hardware interrupts or system services first). Update the corresponding IDTENTRY64 structure to point to your service routine. Key fields to configure:
  • OffsetLow/OffsetMiddle/OffsetHigh: Split the 64-bit address of your interrupt service routine (ISR) into these three fields.
  • Selector: Set to KGDT_R0_CODE (kernel-mode code segment selector).
  • Type: Use INTERRUPT_GATE_32 (0xE) if you want to clear the IF flag during the interrupt, or TRAP_GATE_32 (0xF) if you don’t.
  • Dpl: Set to 3 to allow user-mode code to trigger the interrupt, or 0 for kernel-only access.
  • Present: Set to 1 to mark the gate as valid.
• Handle multi-processor systems: Each CPU has its own IDT. Iterate over all active processors (using KeQueryActiveProcessors() and KeSetSystemAffinityThread()), switch to each CPU’s context, and update its IDT separately.

Here’s a simplified code snippet (note: this uses undocumented functions and is unsupported):

// Resolve the unexported KeGetInterruptDispatchTable function
PKIDTENTRY64 (*KeGetInterruptDispatchTable)(VOID) = 
    (PKIDTENTRY64 (*)(VOID))MmGetSystemRoutineAddress((PUCHAR)"KeGetInterruptDispatchTable");

if (!KeGetInterruptDispatchTable) {
    // Handle function resolution failure
    return STATUS_UNSUCCESSFUL;
}

PKIDTENTRY64 idt = KeGetInterruptDispatchTable();
ULONG targetVector = 0x42; // Example unused vector (verify validity first!)

// Update the interrupt gate entry
idt[targetVector].OffsetLow = (USHORT)((ULONG64)MySoftwareInterruptISR & 0xFFFF);
idt[targetVector].OffsetMiddle = (USHORT)(((ULONG64)MySoftwareInterruptISR >> 16) & 0xFFFF);
idt[targetVector].OffsetHigh = (ULONG)((ULONG64)MySoftwareInterruptISR >> 32);
idt[targetVector].Selector = KGDT_R0_CODE;
idt[targetVector].Type = INTERRUPT_GATE_32;
idt[targetVector].Dpl = 3; // Allow user-mode to trigger the interrupt
idt[targetVector].Present = 1;

2. Is this operation feasible, and does official API support exist? #

• Feasibility: Technically yes—you can modify the IDT to register a custom software interrupt, but only in environments where Kernel Patch Protection (PatchGuard) is disabled (like test machines with debug mode enabled, or non-retail Windows builds).
• Official API support: No, there are no public, supported APIs for this. Microsoft explicitly discourages modifying the IDT or registering custom software interrupts because these vectors are part of the kernel’s internal infrastructure. Doing so can cause conflicts with system components, other drivers, or future Windows updates.

3. Must I use undocumented features, and will this trigger Kernel Patch Protection? #

• Undocumented features required: Yes. Since there’s no public API, you have to rely on unexported functions like KeGetInterruptDispatchTable() and manual IDT edits—all of which are undocumented and liable to break between Windows versions.
• PatchGuard trigger: Absolutely. On 64-bit Windows 10, PatchGuard actively monitors critical kernel structures including the IDT. Any unauthorized modification will be detected, and PatchGuard will trigger a system crash (BUG_CHECK 0x109: CRITICAL_STRUCTURE_CORRUPTION). This is unavoidable on retail Windows builds.

A Safer Alternative #

If your goal is to enable communication between user-mode code and your KMDF driver, use supported mechanisms instead:

• IOCTL requests (via WdfIoQueueCreate and WdfDeviceCreateIoQueue)
• Shared memory (using MmMapIoSpace or user-mode mapped sections)
• Kernel-mode callbacks for user-mode events

These methods are stable, supported, and won’t trigger PatchGuard.

内容的提问来源于stack exchange，提问作者Jason