BSOD on calling IoConnectInterrupt

Raghukiran_Urs · March 15, 2007, 6:21am

Hi All,
I am getting BSOD when IoConnectInterrupt is called
what’s wrong with the following piece of code

BOOLEAN MyISR(
IN PKINTERRUPT Interrupt,
IN PVOID ServiceContext
)
{
DbgPrint(“MyISR executed”);
return FALSE;
}

NTSTATUS MyStartDevice(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{
NTSTATUS status = STATUS_SUCCESS;
PLOCAL_DEVICE_INFO deviceInfo;
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
KIRQL devIrql;
ULONG intVect;

Level = 0x10;
Vector = Level;
intVect=HalGetInterruptVector(PCIBus,(ULONG)0,Level,Vector,
&devIrql,
&Affinity);

deviceInfo = (PLOCAL_DEVICE_INFO)DeviceObject->DeviceExtension;
status=IoConnectInterrupt(
deviceInfo->InterruptObject,
IGDAccessISR,
DeviceObject->DeviceExtension,
NULL,
intVect&0xff,
devIrql,
devIrql,
Latched,
TRUE,
Affinity,
FALSE
);
return status;
}

regards,
Raghukiran

On 3/13/07, Nagesh Kumar wrote:
>
> For Hooking the IDT, Rootkits: Suverting the Windows Kernel By Greg
> Hoglund,James Butler is the best book. Refer Chapter 4 For complete
> details on IDT Hooking.
> Its like a tutorial itself. All the best.
>
> ~Nagesh
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · March 15, 2007, 6:47am

I will strictly suggest u not to do this kind of stuffs.

~Nagesh

Raghu Kiran wrote:

cite="xxxxx@mail.gmail.com"
type=“cite”>
content=“text/html; charset=ISO-8859-1”>

Hi All,

I am getting BSOD when IoConnectInterrupt is called

what’s wrong with the following piece of code

BOOLEAN MyISR(

    IN PKINTERRUPT Interrupt,

    IN PVOID ServiceContext

    )

{

DbgPrint(“MyISR executed”);

return FALSE;

}

NTSTATUS MyStartDevice(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)

{

    NTSTATUS    status = STATUS_SUCCESS;

PLOCAL_DEVICE_INFO      deviceInfo;

ULONG    Level;

    ULONG    Vector;

    KAFFINITY   Affinity;

KIRQL devIrql;

ULONG intVect;

Level = 0x10;

Vector = Level;

intVect=HalGetInterruptVector(PCIBus,(ULONG)0,Level,Vector,

&devIrql,

&Affinity);

deviceInfo = (PLOCAL_DEVICE_INFO)DeviceObject->DeviceExtension;

status=IoConnectInterrupt(

  deviceInfo->InterruptObject,

  IGDAccessISR,

  DeviceObject->DeviceExtension,

  NULL,

  intVect&0xff,

  devIrql,

  devIrql,

  Latched,

  TRUE,

  Affinity,

  FALSE

  );

    return status;

}

regards,

Raghukiran

Mark_Roddy · March 15, 2007, 8:03am

A better question is what is right about the following piece of code. You
cannot use HalGetInterruptVector in a pnp device. I assume you are
attempting to ‘hook interrupts’ for monitoring purposes. I don’t think this
approach is going to work. Oh and PCI busses are level sensitive interrupts,
not latched. Did you actually allocate storage for an InterruptObject or
is deviceInfo->InterruptObject pointing off into empty space?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Raghu Kiran
Sent: Thursday, March 15, 2007 6:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] BSOD on calling IoConnectInterrupt

Hi All,

I am getting BSOD when IoConnectInterrupt is called

what’s wrong with the following piece of code

BOOLEAN MyISR(
IN PKINTERRUPT Interrupt,
IN PVOID ServiceContext
)
{
DbgPrint(“MyISR executed”);
return FALSE;
}

NTSTATUS MyStartDevice(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{
NTSTATUS status = STATUS_SUCCESS;
PLOCAL_DEVICE_INFO deviceInfo;
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
KIRQL devIrql;
ULONG intVect;

Level = 0x10;
Vector = Level;
intVect=HalGetInterruptVector(PCIBus,(ULONG)0,Level,Vector,
&devIrql,
&Affinity);

deviceInfo = (PLOCAL_DEVICE_INFO)DeviceObject->DeviceExtension;
status=IoConnectInterrupt(
deviceInfo->InterruptObject,
IGDAccessISR,
DeviceObject->DeviceExtension,
NULL,
intVect&0xff,
devIrql,
devIrql,
Latched,
TRUE,
Affinity,
FALSE
);
return status;
}

regards,

Raghukiran

On 3/13/07, Nagesh Kumar wrote:

For Hooking the IDT, Rootkits: Suverting the Windows Kernel By Greg
Hoglund,James Butler is the best book. Refer Chapter 4 For complete
details on IDT Hooking.
Its like a tutorial itself. All the best.

~Nagesh

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Tim_Roberts · March 15, 2007, 12:42pm

Raghu Kiran wrote:

Hi All,
I am getting BSOD when IoConnectInterrupt is called
what’s wrong with the following piece of code
…

Level = 0x10;
Vector = Level;
intVect=HalGetInterruptVector(PCIBus,(ULONG)0,Level,Vector,
&devIrql,
&Affinity);

Almost everything is wrong with this code.

What are you actually trying to do? Do you actually have a piece of
hardware that got assigned to IRQ 0x10 (how do you know?), or are you
trying to intercept INT 10 calls to the video BIOS? This is most
definitely NOT the right way to do that. Software interrupts are not
real interrupts. They do not have IRQs, so HalGetInterruptVector cannot
help you. Further, the INT 10 interrupt handler is called in 16-bit v86
mode, not in 32-bit protect mode. Finally, Windows display drivers
typically only call into the BIOS to change the mode. After the mode
has changed, there won’t BE any calls to INT 10.

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

Jake_Oshins · March 15, 2007, 2:04pm

Let me add to this. The parameters to IoConnectInterrupt are historical,
and they are not enough to describe all the things that need to be known to
connect and unmask an interrupt. Thus they end up being “cookies” that
actually describe a device to the PnP subsystem (or the HAL in older
versions of NT). If you don’t own the device and/or don’t guess the right
values for valid cookies, then connecting the interrupt will fail.

This is why IoConnectInterruptEx takes, in essence, a PDO and nothing more.
(More complex versions of it allow a little more control, but that’s another
topic.) The PDO definitively identifies the device and the PnP manager just
derives the right information, without having to re-associate the cookies
passed in IRP_MN_START_DEVICE with the actual internal parameters.

Jake Oshins
Windows Kernel Guy
Author of a lot of Interrupt-Related Code

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Raghu Kiran wrote:
>> Hi All,
>> I am getting BSOD when IoConnectInterrupt is called
>> what’s wrong with the following piece of code
>> …
>>
>> Level = 0x10;
>> Vector = Level;
>> intVect=HalGetInterruptVector(PCIBus,(ULONG)0,Level,Vector,
>> &devIrql,
>> &Affinity);
>>
>
> Almost everything is wrong with this code.
>
> What are you actually trying to do? Do you actually have a piece of
> hardware that got assigned to IRQ 0x10 (how do you know?), or are you
> trying to intercept INT 10 calls to the video BIOS? This is most
> definitely NOT the right way to do that. Software interrupts are not
> real interrupts. They do not have IRQs, so HalGetInterruptVector cannot
> help you. Further, the INT 10 interrupt handler is called in 16-bit v86
> mode, not in 32-bit protect mode. Finally, Windows display drivers
> typically only call into the BIOS to change the mode. After the mode
> has changed, there won’t BE any calls to INT 10.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

anton_bassov · March 15, 2007, 10:58pm

In addition to what Tim and Jake already said,

ISR that gets passed to IoConnectInterrupt() has nothing to do with IDT - IDT stores the address not of ISR but of interrupt handler stub that saves execution context and raises IRQL to the level, corresponding to the device, before transferring execution to ISR
IRQ-to-vector mapping is different on PIC and APIC HALs. On PIC HAL vector is 0x30+IRQ, with interrupt priority implied by IRQ. On APIC HAL things are totally different - IOAPIC gives OS designers a full discretion when mappind IRQs to vectors and defining interrupt trigger mode , with interrupt priority=vector/16. Therefore, as Jake already told you, most parameters to IoConnectInterrupt() are just “cookies” that identify the target device to the system - drivers themselves just cannot define such things as IRQ-to-vector mapping, priority and trigger mode for their target interrupts, so that you have just to pass on parameters that you have received from the system

Anton Bassov