ISR called with only ~800 Bytes of Stack?

NTDEV
1

Hi!
It’s been some time since I last posted on this list. I hope you don’t mind
if I now turn to you (again) for advice on a problem that completely
puzzles me.

Some years ago I wrote a driver for my company, for a custom PCI board that
we use in thousands of PCs (PC based entertainment kiosks).
The board and driver work fine with many different mainboards, CPUs,
chipsets etc. OS is Windows XP Pro SP2.

Now we got a new developement PC for a newly hired employee, and my driver
causes a BSOD. There are 2 strange things.

  1. It only crashes when booting the PC with the driver installed & device
    enabled. When the driver is installed after booting, everything is fine.
    When the device is disabled while booting and enabled by hand afterwards,
    everything is fine too.

  2. I saved a crashdump (kernel memory dump), and well, it looks like the
    ISR of my driver is called with only about 800 Bytes of stack left.
    “!analyze -v” shows me this:

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

TSS: 00000028 – (.tss 0x28)
eax=00000001 ebx=00000048 ecx=806ef3a0 edx=00000000 esi=baa65174
edi=baa650b8
eip=806e7ec8 esp=baa64ff4 ebp=baa65008 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
hal!HalpPCIConfig+0x8:
806e7ec8 56 push esi
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: csrss.exe

LAST_CONTROL_TRANSFER: from 806e8436 to 806e7ec8

STACK_TEXT:
baa65008 806e8436 baa6504c 00000000 baa65174 hal!HalpPCIConfig+0x8
baa65028 806e90ec baa6504c 00000000 baa65174 hal!HalpReadPCIConfig+0x48
baa650b8 ba768ae0 00000000 00000003 00000000
hal!HaliPciInterfaceReadConfig+0x34
baa650dc ba768b4c 8a8595e0 00000000 baa65174
pci!PciReadWriteConfigSpace+0x38
baa650fc ba768dbb 8a859410 baa65174 00000048 pci!PciReadDeviceConfig+0x1e
baa65230 ba76bc28 8a859410 baa65298 00000048
pci!PciExternalReadDeviceConfig+0x55
baa65254 ba768323 8a859410 00000000 baa65298 pci!PciReadDeviceSpace+0x5e
baa65274 ba07bb47 8a859410 00000000 baa65298 pci!PciPnpReadConfig+0x1d
baa6529c ba07a004 8a6b7000 00000000 0000ff20
TABIO_WDM!TABIO_WDM_Device_PCI::IsMyInterrupt+0x57
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
3083]
baa652bc ba075dfc 8a575300 00000000 8054471c
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProc+0x14
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
2549]
baa652c8 8054471c 8a64b710 8a575300 00000007
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProcLINK+0xc
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.h @ 68]
baa652e0 805446bc 00000000 baa652fc 805446c9
nt!KiChainedDispatch2ndLvl+0x44
baa652e0 00000000 00000000 baa652fc 805446c9 nt!KiChainedDispatch+0x1c

STACK_COMMAND: .tss 0x28 ; kb

FOLLOWUP_IP:
pci!PciReadWriteConfigSpace+38
ba768ae0 3b4518 cmp eax,dword ptr [ebp+18h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: pci!PciReadWriteConfigSpace+38

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: pci

IMAGE_NAME: pci.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107d31

FAILURE_BUCKET_ID: 0x7f_8_pci!PciReadWriteConfigSpace+38

BUCKET_ID: 0x7f_8_pci!PciReadWriteConfigSpace+38

Followup: MachineOwner

And “!thread” shows me this:

THREAD 8a5a9508 Cid 02a8.02ac Teb: 7ffde000 Win32Thread: e2128298 RUNNING
on processor 0
IRP List:
8a622008: (0006,0190) Flags: 00000884 Mdl: 00000000
Not impersonating
DeviceMap e10086c8
Owning Process 8a5aea20 Image: csrss.exe
Wait Start TickCount 1835 Ticks: 15 (0:00:00:00.234)
Context Switch Count 38 LargeStack
UserTime 00:00:00.000
KernelTime 00:00:00.343
Start Address 0x4a6811a3
Stack Init baa68000 Current baa6677c Base baa68000 Limit baa65000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
00000000 806e7ec8 00000000 00000000 00000000 nt!KiTrap08+0x48 (FPO: TSS
28:0)
baa65008 806e8436 baa6504c 00000000 baa65174 hal!HalpPCIConfig+0x8 (FPO:
[Non-Fpo])
baa65028 806e90ec baa6504c 00000000 baa65174 hal!HalpReadPCIConfig+0x48
(FPO: [Non-Fpo])
baa650b8 ba768ae0 00000000 00000003 00000000
hal!HaliPciInterfaceReadConfig+0x34 (FPO: [Non-Fpo])
baa650dc ba768b4c 8a8595e0 00000000 baa65174
pci!PciReadWriteConfigSpace+0x38 (FPO: [Non-Fpo])
baa650fc ba768dbb 8a859410 baa65174 00000048 pci!PciReadDeviceConfig+0x1e
(FPO: [Non-Fpo])
baa65230 ba76bc28 8a859410 baa65298 00000048
pci!PciExternalReadDeviceConfig+0x55 (FPO: [Non-Fpo])
baa65254 ba768323 8a859410 00000000 baa65298 pci!PciReadDeviceSpace+0x5e
(FPO: [Non-Fpo])
baa65274 ba07bb47 8a859410 00000000 baa65298 pci!PciPnpReadConfig+0x1d
(FPO: [Non-Fpo])
baa6529c ba07a004 8a6b7000 00000000 0000ff20
TABIO_WDM!TABIO_WDM_Device_PCI::IsMyInterrupt+0x57 (FPO: [Non-Fpo]) (CONV:
thiscall)
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
3083]
baa652bc ba075dfc 8a575300 00000000 8054471c
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProc+0x14 (FPO: [Non-Fpo]) (CONV:
stdcall)
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
2549]
baa652c8 8054471c 8a64b710 8a575300 00000007
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProcLINK+0xc (FPO: [Non-Fpo]) (CONV:
stdcall)
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.h @ 68]
baa652e0 805446bc 00000000 baa652fc 805446c9
nt!KiChainedDispatch2ndLvl+0x44 (FPO: [0,3,0])
baa652e0 00000000 00000000 baa652fc 805446c9 nt!KiChainedDispatch+0x1c
(FPO: [0,2] TrapFrame @ 00000000)

So appearently KiChainedDispatch has it’s stack frame at baa652e0. The
stack starts at baa68000 and ends at baa65000.
baa652e0 - baa65000 = 2e0 = 736 (dec)
Regarding the functions in the callstack: TABIO_WDM_Device::Irq0_IsrProc is
my interrupt handler, called via the “LinkTo” mechanism of the Compuware
DriverWorks framework.
TABIO_WDM_Device_PCI::IsMyInterrupt is the first function called in
Irq0_IsrProc to check if the interrupt originates from “my” PCI board.
IsMyInterrupt then calls the “GetBusData” function from the
BUS_INTERFACE_STANDARD interface of the PDO. The BUS_INTERFACE_STANDARD is
initialized at that point.

So I’m completely puzzeled, I really don’t know what’s going on here.

If anybody has any idea what could be going on here (and how to fix it),
I’d really appreciate your input.

Cheers,
Paul

2

Why are you accessing the PCI config space from the ISR?

It is a hardware misdesign, and was so since around 1999 when MS published
the PCI hardware design guidelines (as a .PPT file).

“No status and control registers in config space” - this is a requirement.
Config space is only for some mode-control registers which are touched only at
init or some mode changes, but not during the usual device IO procedures.

This also means - do not ever touch the config space from the ISR.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi!
> It’s been some time since I last posted on this list. I hope you don’t mind
> if I now turn to you (again) for advice on a problem that completely
> puzzles me.
>
> ----
>
> Some years ago I wrote a driver for my company, for a custom PCI board that
> we use in thousands of PCs (PC based entertainment kiosks).
> The board and driver work fine with many different mainboards, CPUs,
> chipsets etc. OS is Windows XP Pro SP2.
>
> Now we got a new developement PC for a newly hired employee, and my driver
> causes a BSOD. There are 2 strange things.
>
> 1) It only crashes when booting the PC with the driver installed & device
> enabled. When the driver is installed after booting, everything is fine.
> When the device is disabled while booting and enabled by hand afterwards,
> everything is fine too.
>
> 2) I saved a crashdump (kernel memory dump), and well, it looks like the
> ISR of my driver is called with only about 800 Bytes of stack left.
> “!analyze -v” shows me this:
>
>
*****
>
>
> * Bugcheck Analysis
>
>
>
>
>
> UNEXPECTED_KERNEL_MODE_TRAP (7f)
> This means a trap occurred in kernel mode, and it’s a trap of a kind
> that the kernel isn’t allowed to have/catch (bound trap) or that
> is always instant death (double fault). The first number in the
> bugcheck params is the number of the trap (8 = double fault, etc)
> Consult an Intel x86 family manual to learn more about what these
> traps are. Here is a portion of those codes:
> If kv shows a taskGate
> use .tss on the part before the colon, then kv.
> Else if kv shows a trapframe
> use .trap on that value
> Else
> .trap on the appropriate frame will show where the trap was taken
> (on x86, this will be the ebp that goes with the procedure KiTrap)
> Endif
> kb will then show the corrected stack.
> Arguments:
> Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
> Arg2: 80042000
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0x7f_8
>
> TSS: 00000028 – (.tss 0x28)
> eax=00000001 ebx=00000048 ecx=806ef3a0 edx=00000000 esi=baa65174
> edi=baa650b8
> eip=806e7ec8 esp=baa64ff4 ebp=baa65008 iopl=0 nv up ei ng nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010282
> hal!HalpPCIConfig+0x8:
> 806e7ec8 56 push esi
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> PROCESS_NAME: csrss.exe
>
> LAST_CONTROL_TRANSFER: from 806e8436 to 806e7ec8
>
> STACK_TEXT:
> baa65008 806e8436 baa6504c 00000000 baa65174 hal!HalpPCIConfig+0x8
> baa65028 806e90ec baa6504c 00000000 baa65174 hal!HalpReadPCIConfig+0x48
> baa650b8 ba768ae0 00000000 00000003 00000000
> hal!HaliPciInterfaceReadConfig+0x34
> baa650dc ba768b4c 8a8595e0 00000000 baa65174
> pci!PciReadWriteConfigSpace+0x38
> baa650fc ba768dbb 8a859410 baa65174 00000048 pci!PciReadDeviceConfig+0x1e
> baa65230 ba76bc28 8a859410 baa65298 00000048
> pci!PciExternalReadDeviceConfig+0x55
> baa65254 ba768323 8a859410 00000000 baa65298 pci!PciReadDeviceSpace+0x5e
> baa65274 ba07bb47 8a859410 00000000 baa65298 pci!PciPnpReadConfig+0x1d
> baa6529c ba07a004 8a6b7000 00000000 0000ff20
> TABIO_WDM!TABIO_WDM_Device_PCI::IsMyInterrupt+0x57
> [c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
> 3083]
> baa652bc ba075dfc 8a575300 00000000 8054471c
> TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProc+0x14
> [c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
> 2549]
> baa652c8 8054471c 8a64b710 8a575300 00000007
> TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProcLINK+0xc
> [c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.h @ 68]
> baa652e0 805446bc 00000000 baa652fc 805446c9
> nt!KiChainedDispatch2ndLvl+0x44
> baa652e0 00000000 00000000 baa652fc 805446c9 nt!KiChainedDispatch+0x1c
>
>
> STACK_COMMAND: .tss 0x28 ; kb
>
> FOLLOWUP_IP:
> pci!PciReadWriteConfigSpace+38
> ba768ae0 3b4518 cmp eax,dword ptr [ebp+18h]
>
> SYMBOL_STACK_INDEX: 3
>
> SYMBOL_NAME: pci!PciReadWriteConfigSpace+38
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: pci
>
> IMAGE_NAME: pci.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107d31
>
> FAILURE_BUCKET_ID: 0x7f_8_pci!PciReadWriteConfigSpace+38
>
> BUCKET_ID: 0x7f_8_pci!PciReadWriteConfigSpace+38
>
> Followup: MachineOwner
>
> ----------------------------------------------------------
>
> And “!thread” shows me this:
>
> THREAD 8a5a9508 Cid 02a8.02ac Teb: 7ffde000 Win32Thread: e2128298 RUNNING
> on processor 0
> IRP List:
> 8a622008: (0006,0190) Flags: 00000884 Mdl: 00000000
> Not impersonating
> DeviceMap e10086c8
> Owning Process 8a5aea20 Image: csrss.exe
> Wait Start TickCount 1835 Ticks: 15 (0:00:00:00.234)
> Context Switch Count 38 LargeStack
> UserTime 00:00:00.000
> KernelTime 00:00:00.343
> Start Address 0x4a6811a3
> Stack Init baa68000 Current baa6677c Base baa68000 Limit baa65000 Call 0
> Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 16
> ChildEBP RetAddr Args to Child
> 00000000 806e7ec8 00000000 00000000 00000000 nt!KiTrap08+0x48 (FPO: TSS
> 28:0)
> baa65008 806e8436 baa6504c 00000000 baa65174 hal!HalpPCIConfig+0x8 (FPO:
> [Non-Fpo])
> baa65028 806e90ec baa6504c 00000000 baa65174 hal!HalpReadPCIConfig+0x48
> (FPO: [Non-Fpo])
> baa650b8 ba768ae0 00000000 00000003 00000000
> hal!HaliPciInterfaceReadConfig+0x34 (FPO: [Non-Fpo])
> baa650dc ba768b4c 8a8595e0 00000000 baa65174
> pci!PciReadWriteConfigSpace+0x38 (FPO: [Non-Fpo])
> baa650fc ba768dbb 8a859410 baa65174 00000048 pci!PciReadDeviceConfig+0x1e
> (FPO: [Non-Fpo])
> baa65230 ba76bc28 8a859410 baa65298 00000048
> pci!PciExternalReadDeviceConfig+0x55 (FPO: [Non-Fpo])
> baa65254 ba768323 8a859410 00000000 baa65298 pci!PciReadDeviceSpace+0x5e
> (FPO: [Non-Fpo])
> baa65274 ba07bb47 8a859410 00000000 baa65298 pci!PciPnpReadConfig+0x1d
> (FPO: [Non-Fpo])
> baa6529c ba07a004 8a6b7000 00000000 0000ff20
> TABIO_WDM!TABIO_WDM_Device_PCI::IsMyInterrupt+0x57 (FPO: [Non-Fpo]) (CONV:
> thiscall)
> [c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
> 3083]
> baa652bc ba075dfc 8a575300 00000000 8054471c
> TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProc+0x14 (FPO: [Non-Fpo]) (CONV:
> stdcall)
> [c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
> 2549]
> baa652c8 8054471c 8a64b710 8a575300 00000007
> TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProcLINK+0xc (FPO: [Non-Fpo]) (CONV:
> stdcall)
> [c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.h @ 68]
> baa652e0 805446bc 00000000 baa652fc 805446c9
> nt!KiChainedDispatch2ndLvl+0x44 (FPO: [0,3,0])
> baa652e0 00000000 00000000 baa652fc 805446c9 nt!KiChainedDispatch+0x1c
> (FPO: [0,2] TrapFrame @ 00000000)
>
> ----------------------------------------------------------
>
> So appearently KiChainedDispatch has it’s stack frame at baa652e0. The
> stack starts at baa68000 and ends at baa65000.
> baa652e0 - baa65000 = 2e0 = 736 (dec)
> Regarding the functions in the callstack: TABIO_WDM_Device::Irq0_IsrProc is
> my interrupt handler, called via the “LinkTo” mechanism of the Compuware
> DriverWorks framework.
> TABIO_WDM_Device_PCI::IsMyInterrupt is the first function called in
> Irq0_IsrProc to check if the interrupt originates from “my” PCI board.
> IsMyInterrupt then calls the “GetBusData” function from the
> BUS_INTERFACE_STANDARD interface of the PDO. The BUS_INTERFACE_STANDARD is
> initialized at that point.
>
> So I’m completely puzzeled, I really don’t know what’s going on here.
>
> If anybody has any idea what could be going on here (and how to fix it),
> I’d really appreciate your input.
>
> Cheers,
> Paul
>
>

3

Try to find out what the current thread is doing that is using so much
stack. The debugger seems to be showing only the context of your interrupt,
but you can use dds to find likely call frames, and k = … to display the
stack.

I’d also look at the IRP listed in the !thread output. That might tell you
something.

It’s interesting that windbg thinks the current stack pointer is baa6677c,
which would leave plenty of space.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@tab.at
Sent: Tuesday, October 16, 2007 8:16 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ISR called with only ~800 Bytes of Stack?

Hi!
It’s been some time since I last posted on this list. I hope you don’t mind
if I now turn to you (again) for advice on a problem that completely puzzles
me.

Some years ago I wrote a driver for my company, for a custom PCI board that
we use in thousands of PCs (PC based entertainment kiosks).
The board and driver work fine with many different mainboards, CPUs,
chipsets etc. OS is Windows XP Pro SP2.

Now we got a new developement PC for a newly hired employee, and my driver
causes a BSOD. There are 2 strange things.

  1. It only crashes when booting the PC with the driver installed & device
    enabled. When the driver is installed after booting, everything is fine.
    When the device is disabled while booting and enabled by hand afterwards,
    everything is fine too.

  2. I saved a crashdump (kernel memory dump), and well, it looks like the ISR
    of my driver is called with only about 800 Bytes of stack left.
    “!analyze -v” shows me this:

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind that
the kernel isn’t allowed to have/catch (bound trap) or that is always
instant death (double fault). The first number in the bugcheck params is
the number of the trap (8 = double fault, etc) Consult an Intel x86 family
manual to learn more about what these traps are. Here is a *portion* of
those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

TSS: 00000028 – (.tss 0x28)
eax=00000001 ebx=00000048 ecx=806ef3a0 edx=00000000 esi=baa65174
edi=baa650b8
eip=806e7ec8 esp=baa64ff4 ebp=baa65008 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
hal!HalpPCIConfig+0x8:
806e7ec8 56 push esi
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: csrss.exe

LAST_CONTROL_TRANSFER: from 806e8436 to 806e7ec8

STACK_TEXT:
baa65008 806e8436 baa6504c 00000000 baa65174 hal!HalpPCIConfig+0x8
baa65028 806e90ec baa6504c 00000000 baa65174 hal!HalpReadPCIConfig+0x48
baa650b8 ba768ae0 00000000 00000003 00000000
hal!HaliPciInterfaceReadConfig+0x34
baa650dc ba768b4c 8a8595e0 00000000 baa65174
pci!PciReadWriteConfigSpace+0x38
baa650fc ba768dbb 8a859410 baa65174 00000048 pci!PciReadDeviceConfig+0x1e
baa65230 ba76bc28 8a859410 baa65298 00000048
pci!PciExternalReadDeviceConfig+0x55
baa65254 ba768323 8a859410 00000000 baa65298 pci!PciReadDeviceSpace+0x5e
baa65274 ba07bb47 8a859410 00000000 baa65298 pci!PciPnpReadConfig+0x1d
baa6529c ba07a004 8a6b7000 00000000 0000ff20
TABIO_WDM!TABIO_WDM_Device_PCI::IsMyInterrupt+0x57
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
3083] baa652bc ba075dfc 8a575300 00000000 8054471c
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProc+0x14
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
2549]
baa652c8 8054471c 8a64b710 8a575300 00000007
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProcLINK+0xc
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.h @ 68]
baa652e0 805446bc 00000000 baa652fc 805446c9
nt!KiChainedDispatch2ndLvl+0x44
baa652e0 00000000 00000000 baa652fc 805446c9 nt!KiChainedDispatch+0x1c

STACK_COMMAND: .tss 0x28 ; kb

FOLLOWUP_IP:
pci!PciReadWriteConfigSpace+38
ba768ae0 3b4518 cmp eax,dword ptr [ebp+18h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: pci!PciReadWriteConfigSpace+38

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: pci

IMAGE_NAME: pci.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107d31

FAILURE_BUCKET_ID: 0x7f_8_pci!PciReadWriteConfigSpace+38

BUCKET_ID: 0x7f_8_pci!PciReadWriteConfigSpace+38

Followup: MachineOwner

And “!thread” shows me this:

THREAD 8a5a9508 Cid 02a8.02ac Teb: 7ffde000 Win32Thread: e2128298 RUNNING
on processor 0 IRP List:
8a622008: (0006,0190) Flags: 00000884 Mdl: 00000000 Not impersonating
DeviceMap e10086c8
Owning Process 8a5aea20 Image: csrss.exe
Wait Start TickCount 1835 Ticks: 15 (0:00:00:00.234)
Context Switch Count 38 LargeStack
UserTime 00:00:00.000
KernelTime 00:00:00.343
Start Address 0x4a6811a3
Stack Init baa68000 Current baa6677c Base baa68000 Limit baa65000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 16 ChildEBP
RetAddr Args to Child 00000000 806e7ec8 00000000 00000000 00000000
nt!KiTrap08+0x48 (FPO: TSS
28:0)
baa65008 806e8436 baa6504c 00000000 baa65174 hal!HalpPCIConfig+0x8 (FPO:
[Non-Fpo])
baa65028 806e90ec baa6504c 00000000 baa65174 hal!HalpReadPCIConfig+0x48
(FPO: [Non-Fpo])
baa650b8 ba768ae0 00000000 00000003 00000000
hal!HaliPciInterfaceReadConfig+0x34 (FPO: [Non-Fpo]) baa650dc ba768b4c
8a8595e0 00000000 baa65174
pci!PciReadWriteConfigSpace+0x38 (FPO: [Non-Fpo]) baa650fc ba768dbb 8a859410
baa65174 00000048 pci!PciReadDeviceConfig+0x1e
(FPO: [Non-Fpo])
baa65230 ba76bc28 8a859410 baa65298 00000048
pci!PciExternalReadDeviceConfig+0x55 (FPO: [Non-Fpo])
baa65254 ba768323 8a859410 00000000 baa65298 pci!PciReadDeviceSpace+0x5e
(FPO: [Non-Fpo])
baa65274 ba07bb47 8a859410 00000000 baa65298 pci!PciPnpReadConfig+0x1d
(FPO: [Non-Fpo])
baa6529c ba07a004 8a6b7000 00000000 0000ff20
TABIO_WDM!TABIO_WDM_Device_PCI::IsMyInterrupt+0x57 (FPO: [Non-Fpo]) (CONV:
thiscall)
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
3083] baa652bc ba075dfc 8a575300 00000000 8054471c
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProc+0x14 (FPO: [Non-Fpo]) (CONV:
stdcall)
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.cpp @
2549]
baa652c8 8054471c 8a64b710 8a575300 00000007
TABIO_WDM!TABIO_WDM_Device::Irq0_IsrProcLINK+0xc (FPO: [Non-Fpo]) (CONV:
stdcall)
[c:\projects\common\tabio\tabiowdm\src\driver\main\tabio_wdm_device.h @ 68]
baa652e0 805446bc 00000000 baa652fc 805446c9
nt!KiChainedDispatch2ndLvl+0x44 (FPO: [0,3,0]) baa652e0 00000000 00000000
baa652fc 805446c9 nt!KiChainedDispatch+0x1c
(FPO: [0,2] TrapFrame @ 00000000)

So appearently KiChainedDispatch has it’s stack frame at baa652e0. The stack
starts at baa68000 and ends at baa65000.
baa652e0 - baa65000 = 2e0 = 736 (dec)
Regarding the functions in the callstack: TABIO_WDM_Device::Irq0_IsrProc is
my interrupt handler, called via the “LinkTo” mechanism of the Compuware
DriverWorks framework.
TABIO_WDM_Device_PCI::IsMyInterrupt is the first function called in
Irq0_IsrProc to check if the interrupt originates from “my” PCI board.
IsMyInterrupt then calls the “GetBusData” function from the
BUS_INTERFACE_STANDARD interface of the PDO. The BUS_INTERFACE_STANDARD is
initialized at that point.

So I’m completely puzzeled, I really don’t know what’s going on here.

If anybody has any idea what could be going on here (and how to fix it), I’d
really appreciate your input.

Cheers,
Paul

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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