HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI filter

Hi

In my TDI filter driver, I’m calling the function IoGetRequesterProcessId
(Irp) from a completion routine (of my TDI_CONNECT filter function) and
sometimes I get BSOD of IRQL_NO_LESS_OR_EQUAL (a). Driver verifier is also
running in the background.

I started to analyze the dump, and found that

  1. The irp is valid.

  2. IoGetRequesterProcessId () calls IoGetProcess() in order to get EPROCESS
    structure of the requested process, and the structure I get is invalid (all
    structure data is invalid) but IoGetProcess() still returns success to
    IoGetRequesterProcessId () !!

The first thing I thought of is that the process was already ended, and
therefore IoGetProcess got an invalid EPROCESS, but how can process be ended
if I still have it’s irp in my completion routine?

Another idea is that this function is only supported in IFS ?! (I got it
from there)

Thanks for any help, I really need it.

IoGetRequesterProcessId only works for PIRPs that are send by the I/O manager itself. If AFD or some other driver is creating and sending the PIRP on its own, then this function cannot work. If I remember how TDI is set up, you will not be able to use this function.

d


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Saturday, April 01, 2006 3:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI filter

Hi
?
In my TDI filter driver, I’m calling the function IoGetRequesterProcessId (Irp) from a completion routine (of my TDI_CONNECT filter function) and sometimes I get BSOD of IRQL_NO_LESS_OR_EQUAL (a). Driver verifier is also running in the background.
?
I started to analyze the dump, and found that

  1. The irp is valid.
  2. IoGetRequesterProcessId () calls IoGetProcess() in order to get EPROCESS structure of the requested process, and the structure I get is invalid (all structure data is invalid) but IoGetProcess() still returns success to IoGetRequesterProcessId () !!
    ?
    The first thing I thought of is that the process was already ended, and therefore IoGetProcess got an invalid EPROCESS, but how can process be ended if I still have it’s irp in my completion routine?
    ?
    Another idea is that this function is only supported in IFS ?! (I got it from there)
    ?
    Thanks for any help, I really need it.
    — 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

Hi Doron,

Few points + I’m attaching the WinDbg output:

I put my TDI filter over TCP and UDP.

Driver Verifier was active while this BSOD happened. Maybe it’s the cause?

The filter ran on 5 computers for several days, so this function worked most
of the time.

Even if what you are saying is true, IoGetRequestorProcessId() calls
IoGetRequestorProcess() and it returns SUCCESS !! (it returns pointer to
EPROCESS instead of null which indicates success but again, the EPROCESS
itself is invalid). So according to what you are saying,
IoGetRequestorProcess() had to fail, but it didn’t !

How can IRP be not connected to the IO manager? I think that the irp was
created by TdiBuildConnect(), but it was allocated by
TdiBuildInternalDeviceControlIrp().

Is there a way to identify that an IRP is not connected to the IO
manager? (And
maybe then i’ll use some other function instead? I’ve checked
ThreadListEntry filed

In the IRP and it was empty.

If you have other working alternative to get Process ID in TDI filter
completions I’ll be glad.

Thanks a lot.

kd> !analyze -v

*******************************************************************************

*
*

* Bugcheck Analysis
*

*
*

*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at
an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 313730b7, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 805000ad, address which referenced memory

Debugging Details:


***** Kernel symbols are WRONG. Please fix symbols to do analysis.

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 442aea61

READ_ADDRESS: unable to get nt!MmSpecialPoolStart

unable to get nt!MmSpecialPoolEnd

unable to get nt!MmPoolCodeStart

unable to get nt!MmPoolCodeEnd

313730b7

CURRENT_IRQL: 2

FAULTING_IP:

nt!IoGetRequestorProcessId+11

805000ad 8b8084000000 mov eax,[eax+0x84]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 805000ad to 804e187f

STACK_TEXT:

WARNING: Stack unwind information not available. Following frames may be
wrong.

8054fa98 805000ad badb0d00 8687c4b0 00000000 nt!Kei386EoiHelper+0x2823

8054fb0c eec839bf 8846af20 8846af20 8054fc14 nt!IoGetRequestorProcessId+0x11

8054fb8c 80669ef9 8672a3f8 8846af20 8672a4b0
tdipassl!TDIFltTdiConnectComplete+0x25f [tdifilterprobedispatch.c @ 252]

8054fbb0 804e3d38 8672a3f8 8846af20 8054fc14 nt!RtlCompressBuffer+0x28a2

8054fbe0 8066a3c9 8846af20 861ab620 00000000 nt!IofCompleteRequest+0x142

8054fc4c eec9cad2 86649700 86606a38 00000002 nt!RtlCompressBuffer+0x2d72

8054fc64 eeca2cc8 8846af20 00000000 00000000 tcpip!IPTransmit+0x1e94

8054fc78 eeca3ba5 8846af20 00000000 00000000 tcpip!ARPRcv+0x5855

8054fc98 eeca5a5a 86606a38 8054fe58 00000000 tcpip!ARPRcv+0x6732

8054fd1c eec99ef5 869f3180 7e14a8c0 0b0aa8c0 tcpip!ARPRcv+0x85e7

8054fd7c eec99b19 00000020 869f3180 eec9c076 tcpip!IPFreeBuff+0x634

8054fdf8 eec99836 eecd93f0 869f3180 864fe018 tcpip!IPFreeBuff+0x258

8054feb0 eec98922 869f3180 864fe02c 0000001c tcpip!IPRcvPacket+0x296

8054fef0 eec9884d 00000000 8654ae68 864fe00a tcpip!ARPRcvPacket+0x128

8054ff2c badb1f45 868b11c8 00000000 f6e86b40 tcpip!ARPRcvPacket+0x53

8054ff80 f6e8101d 006d01d8 86765380 00000001
NDIS!FddiFilterDprIndicateReceive+0xd4d

8054ff94 f6e811b4 86773608 86765380 00000001
psched!RegisterPsComponent+0x6cef

8054ffb8 f6e815f9 86668010 00000000 86773608
psched!RegisterPsComponent+0x6e86

8054ffd0 badb1d40 86668008 866f9008 00000001
psched!RegisterPsComponent+0x72cb

80550020 f6fb659e 006d01d8 80550060 00000001
NDIS!FddiFilterDprIndicateReceive+0xb48

80550170 f6fb7471 006f9008 8055019f 8686b308 e1000325+0x59e

80550194 bada7f09 006f9008 80558e80 80558c20 e1000325+0x1471

805501ac 804dbbd4 866f9460 866f944c 00000000 NDIS!NdisCompletePnPEvent+0x17b

ffdff980 00000000 f78a7000 00002e44 00000000 nt!KiDispatchInterrupt+0x360

STACK_COMMAND: kb

FOLLOWUP_IP:

tdipassl!TDIFltTdiConnectComplete+25f [tdifilterprobedispatch.c @ 252]

eec839bf 8b4dcc mov ecx,[ebp-0x34]

FAULTING_SOURCE_CODE:

248: }

249:

250:

251:
pCommunicationInfo->FileObject
= IrpSp->FileObject;

252: pCommunicationInfo->ProcessId
= (UINT32)IoGetRequestorProcessId( Irp );

253:

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdipassl!TDIFltTdiConnectComplete+25f

MODULE_NAME: tdipassl

IMAGE_NAME: tdipassl.sys

kd> dt tdipassl!_IRP 8846af20

+0x000 Type : 6

+0x002 Size : 0xdc

+0x004 MdlAddress : (null)

+0x008 Flags : 0x40000000

+0x00c AssociatedIrp : __unnamed

+0x010 ThreadListEntry : _LIST_ENTRY [0x8846af30 - 0x8846af30]

+0x018 IoStatus : _IO_STATUS_BLOCK

+0x020 RequestorMode : 0 ‘’

+0x021 PendingReturned : 0x1 ‘’

+0x022 StackCount : 3 ‘’

+0x023 CurrentLocation : 2 ‘’

+0x024 Cancel : 0 ‘’

+0x025 CancelIrql : 0 ‘’

+0x026 ApcEnvironment : 0 ‘’

+0x027 AllocationFlags : 0x80 ‘’

+0x028 UserIosb : (null)

+0x02c UserEvent : (null)

+0x030 Overlay : __unnamed

+0x038 CancelRoutine : (null)

+0x03c UserBuffer : (null)

+0x040 Tail : __unnamed

On 4/2/06, Doron Holan wrote:
>
> IoGetRequesterProcessId only works for PIRPs that are send by the I/O
> manager itself. If AFD or some other driver is creating and sending the
> PIRP on its own, then this function cannot work. If I remember how TDI is
> set up, you will not be able to use this function.
>
> d
>
> ________________________________________
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Zed y
> Sent: Saturday, April 01, 2006 3:16 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI
> filter
>
> Hi
>
> In my TDI filter driver, I’m calling the function
> IoGetRequesterProcessId (Irp) from a completion routine (of my TDI_CONNECT
> filter function) and sometimes I get BSOD of IRQL_NO_LESS_OR_EQUAL
> (a). Driver verifier is also running in the background.
>
> I started to analyze the dump, and found that
> 1. The irp is valid.
> 2. IoGetRequesterProcessId () calls IoGetProcess() in order to get
> EPROCESS structure of the requested process, and the structure I get is
> invalid (all structure data is invalid) but IoGetProcess() still returns
> success to IoGetRequesterProcessId () !!
>
> The first thing I thought of is that the process was already ended, and
> therefore IoGetProcess got an invalid EPROCESS, but how can process be ended
> if I still have it’s irp in my completion routine?
>
> Another idea is that this function is only supported in IFS ?! (I got it
> from there)
>
> Thanks for any help, I really need it.
> — 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
>

Say Zed,

Do you think that message “***** Kernel symbols are WRONG. Please fix
symbols to do analysis.” MIGHT be a clue.

Just as a sanity check, do you think functions listed on the stack trace
related to FDDI (a fiber optic network that’s very rarely used anymore)
could possible be correct. Offhand, confidence that IoGetRequestorProcessId
is involved with this crash is low.

FIX YOUR SYMBOLS! With the bogus data you have presented, we’re all just
wasting our time.

  • Jan

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Sunday, April 02, 2006 1:03 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI
filter

Hi Doron,

Few points + I’m attaching the WinDbg output:

I put my TDI filter over TCP and UDP.

Driver Verifier was active while this BSOD happened. Maybe it’s the cause?

The filter ran on 5 computers for several days, so this function worked most
of the time.

Even if what you are saying is true, IoGetRequestorProcessId() calls
IoGetRequestorProcess() and it returns SUCCESS !! (it returns pointer to
EPROCESS instead of null which indicates success but again, the EPROCESS
itself is invalid). So according to what you are saying,
IoGetRequestorProcess() had to fail, but it didn’t !

How can IRP be not connected to the IO manager? I think that the irp was
created by TdiBuildConnect(), but it was allocated by
TdiBuildInternalDeviceControlIrp().

Is there a way to identify that an IRP is not connected to the IO manager?
(And maybe then i’ll use some other function instead? I’ve checked
ThreadListEntry filed

In the IRP and it was empty.

If you have other working alternative to get Process ID in TDI filter
completions I’ll be glad.

Thanks a lot.

kd> !analyze -v

****************************************************************************
***

*
*

* Bugcheck Analysis
*

*
*

****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at
an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 313730b7, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 805000ad, address which referenced memory

Debugging Details:


***** Kernel symbols are WRONG. Please fix symbols to do analysis.

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 442aea61

READ_ADDRESS: unable to get nt!MmSpecialPoolStart

unable to get nt!MmSpecialPoolEnd

unable to get nt!MmPoolCodeStart

unable to get nt!MmPoolCodeEnd

313730b7

CURRENT_IRQL: 2

FAULTING_IP:

nt!IoGetRequestorProcessId+11

805000ad 8b8084000000 mov eax,[eax+0x84]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 805000ad to 804e187f

STACK_TEXT:

WARNING: Stack unwind information not available. Following frames may be
wrong.

8054fa98 805000ad badb0d00 8687c4b0 00000000 nt!Kei386EoiHelper+0x2823

8054fb0c eec839bf 8846af20 8846af20 8054fc14 nt!IoGetRequestorProcessId+0x11

8054fb8c 80669ef9 8672a3f8 8846af20 8672a4b0
tdipassl!TDIFltTdiConnectComplete+0x25f [tdifilterprobedispatch.c @ 252]

8054fbb0 804e3d38 8672a3f8 8846af20 8054fc14 nt!RtlCompressBuffer+0x28a2

8054fbe0 8066a3c9 8846af20 861ab620 00000000 nt!IofCompleteRequest+0x142

8054fc4c eec9cad2 86649700 86606a38 00000002 nt!RtlCompressBuffer+0x2d72

8054fc64 eeca2cc8 8846af20 00000000 00000000 tcpip!IPTransmit+0x1e94

8054fc78 eeca3ba5 8846af20 00000000 00000000 tcpip!ARPRcv+0x5855

8054fc98 eeca5a5a 86606a38 8054fe58 00000000 tcpip!ARPRcv+0x6732

8054fd1c eec99ef5 869f3180 7e14a8c0 0b0aa8c0 tcpip!ARPRcv+0x85e7

8054fd7c eec99b19 00000020 869f3180 eec9c076 tcpip!IPFreeBuff+0x634

8054fdf8 eec99836 eecd93f0 869f3180 864fe018 tcpip!IPFreeBuff+0x258

8054feb0 eec98922 869f3180 864fe02c 0000001c tcpip!IPRcvPacket+0x296

8054fef0 eec9884d 00000000 8654ae68 864fe00a tcpip!ARPRcvPacket+0x128

8054ff2c badb1f45 868b11c8 00000000 f6e86b40 tcpip!ARPRcvPacket+0x53

8054ff80 f6e8101d 006d01d8 86765380 00000001
NDIS!FddiFilterDprIndicateReceive+0xd4d

8054ff94 f6e811b4 86773608 86765380 00000001
psched!RegisterPsComponent+0x6cef

8054ffb8 f6e815f9 86668010 00000000 86773608
psched!RegisterPsComponent+0x6e86

8054ffd0 badb1d40 86668008 866f9008 00000001
psched!RegisterPsComponent+0x72cb

80550020 f6fb659e 006d01d8 80550060 00000001
NDIS!FddiFilterDprIndicateReceive+0xb48

80550170 f6fb7471 006f9008 8055019f 8686b308 e1000325+0x59e

80550194 bada7f09 006f9008 80558e80 80558c20 e1000325+0x1471

805501ac 804dbbd4 866f9460 866f944c 00000000 NDIS!NdisCompletePnPEvent+0x17b

ffdff980 00000000 f78a7000 00002e44 00000000 nt!KiDispatchInterrupt+0x360

STACK_COMMAND: kb

FOLLOWUP_IP:

tdipassl!TDIFltTdiConnectComplete+25f [tdifilterprobedispatch.c @ 252]

eec839bf 8b4dcc mov ecx,[ebp-0x34]

FAULTING_SOURCE_CODE:

248: }

249:

250:

251:
pCommunicationInfo->FileObject = IrpSp->FileObject;

252:
pCommunicationInfo->ProcessId = (UINT32)IoGetRequestorProcessId( Irp );

253:

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdipassl!TDIFltTdiConnectComplete+25f

MODULE_NAME: tdipassl

IMAGE_NAME: tdipassl.sys

kd> dt tdipassl!_IRP 8846af20

+0x000 Type : 6

+0x002 Size : 0xdc

+0x004 MdlAddress : (null)

+0x008 Flags : 0x40000000

+0x00c AssociatedIrp : __unnamed

+0x010 ThreadListEntry : _LIST_ENTRY [0x8846af30 - 0x8846af30]

+0x018 IoStatus : _IO_STATUS_BLOCK

+0x020 RequestorMode : 0 ‘’

+0x021 PendingReturned : 0x1 ‘’

+0x022 StackCount : 3 ‘’

+0x023 CurrentLocation : 2 ‘’

+0x024 Cancel : 0 ‘’

+0x025 CancelIrql : 0 ‘’

+0x026 ApcEnvironment : 0 ‘’

+0x027 AllocationFlags : 0x80 ‘’

+0x028 UserIosb : (null)

+0x02c UserEvent : (null)

+0x030 Overlay : __unnamed

+0x038 CancelRoutine : (null)

+0x03c UserBuffer : (null)

+0x040 Tail : __unnamed

On 4/2/06, Doron Holan wrote:

IoGetRequesterProcessId only works for PIRPs that are send by the I/O
manager itself. If AFD or some other driver is creating and sending the
PIRP on its own, then this function cannot work. If I remember how TDI is
set up, you will not be able to use this function.

d

________________________________________
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Saturday, April 01, 2006 3:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI
filter

Hi

In my TDI filter driver, I’m calling the function IoGetRequesterProcessId
(Irp) from a completion routine (of my TDI_CONNECT filter function) and
sometimes I get BSOD of IRQL_NO_LESS_OR_EQUAL (a). Driver verifier is also
running in the background.

I started to analyze the dump, and found that
1. The irp is valid.
2. IoGetRequesterProcessId () calls IoGetProcess() in order to get EPROCESS
structure of the requested process, and the structure I get is invalid (all
structure data is invalid) but IoGetProcess() still returns success to
IoGetRequesterProcessId () !!

The first thing I thought of is that the process was already ended, and
therefore IoGetProcess got an invalid EPROCESS, but how can process be ended
if I still have it’s irp in my completion routine?

Another idea is that this function is only supported in IFS ?! (I got it
from there)

Thanks for any help, I really need it.
— 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

— 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

Hi Jan,

You are right in your complain in most of the cases, but not here.
The wrong symbols occurred because I’ve used symbols of ntoskernel for
multi-threaded cpu (ntkrnlpa.pdb)
instead of single threaded (ntoskrnl.pdb). the driver symbols are UP TO
DATE.

After putting the right kernel symbols, i did a .reload and got exactly the
same stack trace and parameters.
Also, IoGetRequestorProcessId () calls IoGetRequestorProcess() that returns
an invalid EPROCESS, so it’s makes sense it will crash.

So it’s ok, you are not wasting your time :slight_smile:
Sorry for the miss understood.

On 4/2/06, Jan Bottorff wrote:
>
> Say Zed,
>
>
>
> Do you think that message “*****Kernel symbols are WRONG. Please fix
> symbols to do analysis.” MIGHT be a clue.
>
>
>
> Just as a sanity check, do you think functions listed on the stack trace
> related to FDDI (a fiber optic network that’s very rarely used anymore)
> could possible be correct. Offhand, confidence that IoGetRequestorProcessId
> is involved with this crash is low.
>
>
>
> FIX YOUR SYMBOLS! With the bogus data you have presented, we’re all just
> wasting our time.
>
>
>
> - Jan
>
>
>
>
> ------------------------------
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Zed y
> Sent: Sunday, April 02, 2006 1:03 AM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside
> TDI filter
>
>
>
> Hi Doron,
>
>
>
> Few points + I’m attaching the WinDbg output:
>
>
>
> I put my TDI filter over TCP and UDP.
>
>
>
> Driver Verifier was active while this BSOD happened. Maybe it’s the cause?
>
>
>
> The filter ran on 5 computers for several days, so this function worked
> most of the time.
>
>
>
> Even if what you are saying is true, IoGetRequestorProcessId() calls
> IoGetRequestorProcess() and it returns SUCCESS !! (it returns pointer to
> EPROCESS instead of null which indicates success but again, the EPROCESS
> itself is invalid). So according to what you are saying,
> IoGetRequestorProcess() had to fail, but it didn’t !
>
>
>
> How can IRP be not connected to the IO manager? I think that the irp was
> created by TdiBuildConnect(), but it was allocated by
> TdiBuildInternalDeviceControlIrp().
>
> Is there a way to identify that an IRP is not connected to the IO
> manager? (And maybe then i’ll use some other function instead? I’ve checked
> ThreadListEntry filed
>
> In the IRP and it was empty.
>
>
>
> If you have other working alternative to get Process ID in TDI filter
> completions I’ll be glad.
>
>
>
> Thanks a lot.
>
>
>
> kd> !analyze -v
>
>
>
*****************************************************************************
>
> *
> *
>
> * Bugcheck
> Analysis *
>
> *
> *
>
>
> **************************************************************************
>
>
>
> IRQL_NOT_LESS_OR_EQUAL (a)
>
> An attempt was made to access a pageable (or completely invalid) address
> at an
>
> interrupt request level (IRQL) that is too high. This is usually
>
> caused by drivers using improper addresses.
>
> If a kernel debugger is available get the stack backtrace.
>
> Arguments:
>
> Arg1: 313730b7, memory referenced
>
> Arg2: 00000002, IRQL
>
> Arg3: 00000000, value 0 = read operation, 1 = write operation
>
> Arg4: 805000ad, address which referenced memory
>
>
>
> Debugging Details:
>
> ------------------
>
>
>
>
Kernel symbols are WRONG. Please fix symbols to do analysis.
>
>
>
> FAULTING_MODULE: 804d7000 nt
>
>
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 442aea61
>
>
>
> READ_ADDRESS: unable to get nt!MmSpecialPoolStart
>
> unable to get nt!MmSpecialPoolEnd
>
> unable to get nt!MmPoolCodeStart
>
> unable to get nt!MmPoolCodeEnd
>
> 313730b7
>
>
>
> CURRENT_IRQL: 2
>
>
>
> FAULTING_IP:
>
> nt!IoGetRequestorProcessId+11
>
> 805000ad 8b8084000000 mov eax,[eax+0x84]
>
>
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
>
>
> BUGCHECK_STR: 0xA
>
>
>
> LAST_CONTROL_TRANSFER: from 805000ad to 804e187f
>
>
>
> STACK_TEXT:
>
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
>
> 8054fa98 805000ad badb0d00 8687c4b0 00000000 nt!Kei386EoiHelper+0x2823
>
> 8054fb0c eec839bf 8846af20 8846af20 8054fc14
> nt!IoGetRequestorProcessId+0x11
>
> 8054fb8c 80669ef9 8672a3f8 8846af20 8672a4b0
> tdipassl!TDIFltTdiConnectComplete+0x25f [tdifilterprobedispatch.c @ 252]
>
> 8054fbb0 804e3d38 8672a3f8 8846af20 8054fc14 nt!RtlCompressBuffer+0x28a2
>
> 8054fbe0 8066a3c9 8846af20 861ab620 00000000 nt!IofCompleteRequest+0x142
>
> 8054fc4c eec9cad2 86649700 86606a38 00000002 nt!RtlCompressBuffer+0x2d72
>
> 8054fc64 eeca2cc8 8846af20 00000000 00000000 tcpip!IPTransmit+0x1e94
>
> 8054fc78 eeca3ba5 8846af20 00000000 00000000 tcpip!ARPRcv+0x5855
>
> 8054fc98 eeca5a5a 86606a38 8054fe58 00000000 tcpip!ARPRcv+0x6732
>
> 8054fd1c eec99ef5 869f3180 7e14a8c0 0b0aa8c0 tcpip!ARPRcv+0x85e7
>
> 8054fd7c eec99b19 00000020 869f3180 eec9c076 tcpip!IPFreeBuff+0x634
>
> 8054fdf8 eec99836 eecd93f0 869f3180 864fe018 tcpip!IPFreeBuff+0x258
>
> 8054feb0 eec98922 869f3180 864fe02c 0000001c tcpip!IPRcvPacket+0x296
>
> 8054fef0 eec9884d 00000000 8654ae68 864fe00a tcpip!ARPRcvPacket+0x128
>
> 8054ff2c badb1f45 868b11c8 00000000 f6e86b40 tcpip!ARPRcvPacket+0x53
>
> 8054ff80 f6e8101d 006d01d8 86765380 00000001
> NDIS!FddiFilterDprIndicateReceive+0xd4d
>
> 8054ff94 f6e811b4 86773608 86765380 00000001
> psched!RegisterPsComponent+0x6cef
>
> 8054ffb8 f6e815f9 86668010 00000000 86773608
> psched!RegisterPsComponent+0x6e86
>
> 8054ffd0 badb1d40 86668008 866f9008 00000001
> psched!RegisterPsComponent+0x72cb
>
> 80550020 f6fb659e 006d01d8 80550060 00000001
> NDIS!FddiFilterDprIndicateReceive+0xb48
>
> 80550170 f6fb7471 006f9008 8055019f 8686b308 e1000325+0x59e
>
> 80550194 bada7f09 006f9008 80558e80 80558c20 e1000325+0x1471
>
> 805501ac 804dbbd4 866f9460 866f944c 00000000
> NDIS!NdisCompletePnPEvent+0x17b
>
> ffdff980 00000000 f78a7000 00002e44 00000000 nt!KiDispatchInterrupt+0x360
>
>
>
>
>
> STACK_COMMAND: kb
>
>
>
> FOLLOWUP_IP:
>
> tdipassl!TDIFltTdiConnectComplete+25f [tdifilterprobedispatch.c @ 252]
>
> eec839bf 8b4dcc mov ecx,[ebp-0x34]
>
>
>
> FAULTING_SOURCE_CODE:
>
> 248: }
>
> 249:
>
> 250:
>
> 251:
> pCommunicationInfo->FileObject = IrpSp->FileObject;
>
> > 252:
> pCommunicationInfo->ProcessId = (UINT32)IoGetRequestorProcessId( Irp );
>
> 253:
>
>
>
>
>
>
>
> SYMBOL_STACK_INDEX: 2
>
>
>
> FOLLOWUP_NAME: MachineOwner
>
>
>
> SYMBOL_NAME: tdipassl!TDIFltTdiConnectComplete+25f
>
>
>
> MODULE_NAME: tdipassl
>
>
>
> IMAGE_NAME: tdipassl.sys
>
>
>
> kd> dt tdipassl!IRP 8846af20
>
> +0x000 Type : 6
>
> +0x002 Size : 0xdc
>
> +0x004 MdlAddress : (null)
>
> +0x008 Flags : 0x40000000
>
> +0x00c AssociatedIrp : unnamed
>
> +0x010 ThreadListEntry : LIST_ENTRY [0x8846af30 - 0x8846af30]
>
> +0x018 IoStatus : IO_STATUS_BLOCK
>
> +0x020 RequestorMode : 0 ‘’
>
> +0x021 PendingReturned : 0x1 ‘’
>
> +0x022 StackCount : 3 ‘’
>
> +0x023 CurrentLocation : 2 ‘’
>
> +0x024 Cancel : 0 ‘’
>
> +0x025 CancelIrql : 0 ‘’
>
> +0x026 ApcEnvironment : 0 ‘’
>
> +0x027 AllocationFlags : 0x80 ‘’
>
> +0x028 UserIosb : (null)
>
> +0x02c UserEvent : (null)
>
> +0x030 Overlay :unnamed
>
> +0x038 CancelRoutine : (null)
>
> +0x03c UserBuffer : (null)
>
> +0x040 Tail : unnamed
>
>
>
> On 4/2/06, Doron Holan wrote:
>
> IoGetRequesterProcessId only works for PIRPs that are send by the I/O
> manager itself. If AFD or some other driver is creating and sending the
> PIRP on its own, then this function cannot work. If I remember how TDI is
> set up, you will not be able to use this function.
>
> d
>
>
_______________________________
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com
>] On Behalf Of Zed y
> Sent: Saturday, April 01, 2006 3:16 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI
> filter
>
> Hi
>
> In my TDI filter driver, I’m calling the function
> IoGetRequesterProcessId (Irp) from a completion routine (of my TDI_CONNECT
> filter function) and sometimes I get BSOD of IRQL_NO_LESS_OR_EQUAL
> (a). Driver verifier is also running in the background.
>
> I started to analyze the dump, and found that
> 1. The irp is valid.
> 2. IoGetRequesterProcessId () calls IoGetProcess() in order to get
> EPROCESS structure of the requested process, and the structure I get is
> invalid (all structure data is invalid) but IoGetProcess() still returns
> success to IoGetRequesterProcessId () !!
>
> The first thing I thought of is that the process was already ended, and
> therefore IoGetProcess got an invalid EPROCESS, but how can process be ended
> if I still have it’s irp in my completion routine?
>
> Another idea is that this function is only supported in IFS ?! (I got it
> from there)
>
> Thanks for any help, I really need it.
> — 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
>
>
>
> — 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
>

Jan,

The location NDIS!FddiFilterDprIndicateReceive+0xd4d just happens to be wher
WinDbg matched a nearest public symbol. I happens to be a perfectly
reasonable return location within the NDIS “ethernet” built-in filtering
package and has nothing per se to do with FDDI. As odd as I may seem, the
presence of the NDIS!FddiFilterDprIndicateReceive symbol is not an
indication that the NDIS symbols are wrong. Such is life with only ‘public’
symbols.

Regards,
Dave Cattley
Consulting Engineer
Systems Software Development


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Sunday, April 02, 2006 5:54 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI
filter

Say Zed,

Do you think that message ?***** Kernel symbols are WRONG. Please fix
symbols to do analysis.? MIGHT be a clue.

Just as a sanity check, do you think functions listed on the stack trace
related to FDDI (a fiber optic network that?s very rarely used anymore)
could possible be correct. Offhand, confidence that IoGetRequestorProcessId
is involved with this crash is low.

FIX YOUR SYMBOLS! With the bogus data you have presented, we?re all just
wasting our time.

  • Jan

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Sunday, April 02, 2006 1:03 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI
filter

Hi Doron,

Few points + I’m attaching the WinDbg output:

I put my TDI filter over TCP and UDP.

Driver Verifier was active while this BSOD happened. Maybe it’s the cause?

The filter ran on 5 computers for several days, so this function worked most
of the time.

Even if what you are saying is true, IoGetRequestorProcessId() calls
IoGetRequestorProcess() and it returns SUCCESS !! (it returns pointer to
EPROCESS instead of null which indicates success but again, the EPROCESS
itself is invalid). So according to what you are saying,
IoGetRequestorProcess() had to fail, but it didn’t !

How can IRP be not connected to the IO manager? I think that the irp was
created by TdiBuildConnect(), but it was allocated by
TdiBuildInternalDeviceControlIrp().

Is there a way to identify that an IRP is not connected to the IO manager?
(And maybe then i’ll use some other function instead? I’ve checked
ThreadListEntry filed

In the IRP and it was empty.

If you have other working alternative to get Process ID in TDI filter
completions I’ll be glad.

Thanks a lot.

kd> !analyze -v

****************************************************************************
***

*
*

* Bugcheck Analysis
*

*
*

****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at
an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 313730b7, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 805000ad, address which referenced memory

Debugging Details:


***** Kernel symbols are WRONG. Please fix symbols to do analysis.

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 442aea61

READ_ADDRESS: unable to get nt!MmSpecialPoolStart

unable to get nt!MmSpecialPoolEnd

unable to get nt!MmPoolCodeStart

unable to get nt!MmPoolCodeEnd

313730b7

CURRENT_IRQL: 2

FAULTING_IP:

nt!IoGetRequestorProcessId+11

805000ad 8b8084000000 mov eax,[eax+0x84]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 805000ad to 804e187f

STACK_TEXT:

WARNING: Stack unwind information not available. Following frames may be
wrong.

8054fa98 805000ad badb0d00 8687c4b0 00000000 nt!Kei386EoiHelper+0x2823

8054fb0c eec839bf 8846af20 8846af20 8054fc14 nt!IoGetRequestorProcessId+0x11

8054fb8c 80669ef9 8672a3f8 8846af20 8672a4b0
tdipassl!TDIFltTdiConnectComplete+0x25f [tdifilterprobedispatch.c @ 252]

8054fbb0 804e3d38 8672a3f8 8846af20 8054fc14 nt!RtlCompressBuffer+0x28a2

8054fbe0 8066a3c9 8846af20 861ab620 00000000 nt!IofCompleteRequest+0x142

8054fc4c eec9cad2 86649700 86606a38 00000002 nt!RtlCompressBuffer+0x2d72

8054fc64 eeca2cc8 8846af20 00000000 00000000 tcpip!IPTransmit+0x1e94

8054fc78 eeca3ba5 8846af20 00000000 00000000 tcpip!ARPRcv+0x5855

8054fc98 eeca5a5a 86606a38 8054fe58 00000000 tcpip!ARPRcv+0x6732

8054fd1c eec99ef5 869f3180 7e14a8c0 0b0aa8c0 tcpip!ARPRcv+0x85e7

8054fd7c eec99b19 00000020 869f3180 eec9c076 tcpip!IPFreeBuff+0x634

8054fdf8 eec99836 eecd93f0 869f3180 864fe018 tcpip!IPFreeBuff+0x258

8054feb0 eec98922 869f3180 864fe02c 0000001c tcpip!IPRcvPacket+0x296

8054fef0 eec9884d 00000000 8654ae68 864fe00a tcpip!ARPRcvPacket+0x128

8054ff2c badb1f45 868b11c8 00000000 f6e86b40 tcpip!ARPRcvPacket+0x53

8054ff80 f6e8101d 006d01d8 86765380 00000001
NDIS!FddiFilterDprIndicateReceive+0xd4d

8054ff94 f6e811b4 86773608 86765380 00000001
psched!RegisterPsComponent+0x6cef

8054ffb8 f6e815f9 86668010 00000000 86773608
psched!RegisterPsComponent+0x6e86

8054ffd0 badb1d40 86668008 866f9008 00000001
psched!RegisterPsComponent+0x72cb

80550020 f6fb659e 006d01d8 80550060 00000001
NDIS!FddiFilterDprIndicateReceive+0xb48

80550170 f6fb7471 006f9008 8055019f 8686b308 e1000325+0x59e

80550194 bada7f09 006f9008 80558e80 80558c20 e1000325+0x1471

805501ac 804dbbd4 866f9460 866f944c 00000000 NDIS!NdisCompletePnPEvent+0x17b

ffdff980 00000000 f78a7000 00002e44 00000000 nt!KiDispatchInterrupt+0x360

STACK_COMMAND: kb

FOLLOWUP_IP:

tdipassl!TDIFltTdiConnectComplete+25f [tdifilterprobedispatch.c @ 252]

eec839bf 8b4dcc mov ecx,[ebp-0x34]

FAULTING_SOURCE_CODE:

248: }

249:

250:

251:
pCommunicationInfo->FileObject = IrpSp->FileObject;

252:
pCommunicationInfo->ProcessId = (UINT32)IoGetRequestorProcessId( Irp );

253:

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdipassl!TDIFltTdiConnectComplete+25f

MODULE_NAME: tdipassl

IMAGE_NAME: tdipassl.sys

kd> dt tdipassl!_IRP 8846af20

+0x000 Type : 6

+0x002 Size : 0xdc

+0x004 MdlAddress : (null)

+0x008 Flags : 0x40000000

+0x00c AssociatedIrp : __unnamed

+0x010 ThreadListEntry : _LIST_ENTRY [0x8846af30 - 0x8846af30]

+0x018 IoStatus : _IO_STATUS_BLOCK

+0x020 RequestorMode : 0 ‘’

+0x021 PendingReturned : 0x1 ‘’

+0x022 StackCount : 3 ‘’

+0x023 CurrentLocation : 2 ‘’

+0x024 Cancel : 0 ‘’

+0x025 CancelIrql : 0 ‘’

+0x026 ApcEnvironment : 0 ‘’

+0x027 AllocationFlags : 0x80 ‘’

+0x028 UserIosb : (null)

+0x02c UserEvent : (null)

+0x030 Overlay : __unnamed

+0x038 CancelRoutine : (null)

+0x03c UserBuffer : (null)

+0x040 Tail : __unnamed

On 4/2/06, Doron Holan wrote:

IoGetRequesterProcessId only works for PIRPs that are send by the I/O
manager itself. If AFD or some other driver is creating and sending the
PIRP on its own, then this function cannot work. If I remember how TDI is
set up, you will not be able to use this function.

d

________________________________________
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com
mailto:xxxxx] On Behalf Of Zed y
Sent: Saturday, April 01, 2006 3:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI
filter

Hi

In my TDI filter driver, I’m calling the function IoGetRequesterProcessId
(Irp) from a completion routine (of my TDI_CONNECT filter function) and
sometimes I get BSOD of IRQL_NO_LESS_OR_EQUAL (a). Driver verifier is also
running in the background.

I started to analyze the dump, and found that
1. The irp is valid.
2. IoGetRequesterProcessId () calls IoGetProcess() in order to get EPROCESS
structure of the requested process, and the structure I get is invalid (all
structure data is invalid) but IoGetProcess() still returns success to
IoGetRequesterProcessId () !!

The first thing I thought of is that the process was already ended, and
therefore IoGetProcess got an invalid EPROCESS, but how can process be ended
if I still have it’s irp in my completion routine?

Another idea is that this function is only supported in IFS ?! (I got it
from there)

Thanks for any help, I really need it.
— 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
http:

— 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</http:></mailto:xxxxx>

“Connected to the I/O manager” is not the right term. Let’s use the functionality in terms described by the DDK. There are threaded PIRPS and non threaded PIRPs.

Threaded PIRPs are irps allocated by the i/o manager when a user mode process initiates I/O. They are also PIRPs allocated by calling the IoBuildXxxRequest APIs. These PIRPs are tied to particular thread and will prevent that thread from exiting if these IRPs are still pending. Furthermore, one must complete the PIRP with a call to IoCompleteRequest so that eventually the I/O manager gets it back, removes it from the PETHREAD and can do its bookkeeping and free the PIRP. Note that the i/o manager does not validate the thread in the PIRP so if there is no thread, you bugcheck.

Non threaded PIRPs are PIRPs allocated by a driver via IoAllocateIrp or IoInitializeIrp (or any TdiBuildXxx routines). These are not associated with any thread. These PIRPs are not freed by the driver which allocated it by calling IoCompleteRequest, rather STATUS_MORE_PROCESSING_REQUIRED *MUST* be returned by the topmost completion routine and prevent the I/O manager from post processing the PIRP.

So, now back to your issue. IoGetRequestorProcess() can be returning garbage b/c there is no validation done on the thread field in the irp which is used to get the process. Furthermore, any driver can act as a TDI initiator (emulating AFD.sys’s behavior) and send PIRPs that they have allocated on their own and these PIRPs will not be threaded PIRPs. This means that you must handle the mix of both types of PIRPs.

d


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Sunday, April 02, 2006 1:03 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI filter

Hi Doron,
?
Few points + I’m attaching the WinDbg output:
?
I put my TDI filter over TCP and UDP.
?
Driver Verifier was active while this BSOD happened. Maybe it’s the cause?
?
The filter ran on 5 computers for several days, so this function worked most of the time.
?
Even if what you are saying is true, IoGetRequestorProcessId() calls IoGetRequestorProcess() and it returns SUCCESS !! (it returns pointer to EPROCESS instead of null which indicates success but again, the EPROCESS itself is invalid). So according to what you are saying, IoGetRequestorProcess() had to fail, but it didn’t !
?
How can IRP be not connected to the IO manager? I think that the irp was created by TdiBuildConnect(), but it was allocated by TdiBuildInternalDeviceControlIrp().
Is there a way to identify that an IRP is not connected to the IO manager? (And maybe then i’ll use some other function instead? I’ve checked ThreadListEntry filed
In the IRP and it was empty.
?
If you have other working alternative to get Process ID in TDI filter completions I’ll be glad.
?
Thanks a lot.
??
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
?
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 313730b7, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 805000ad, address which referenced memory
?
Debugging Details:

?
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
?
FAULTING_MODULE: 804d7000 nt
?
DEBUG_FLR_IMAGE_TIMESTAMP: 442aea61
?
READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
313730b7
?
CURRENT_IRQL: 2
?
FAULTING_IP:
nt!IoGetRequestorProcessId+11
805000ad 8b8084000000 mov eax,[eax+0x84]
?
DEFAULT_BUCKET_ID: DRIVER_FAULT
?
BUGCHECK_STR: 0xA
?
LAST_CONTROL_TRANSFER: from 805000ad to 804e187f
?
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
8054fa98 805000ad badb0d00 8687c4b0 00000000 nt!Kei386EoiHelper+0x2823
8054fb0c eec839bf 8846af20 8846af20 8054fc14 nt!IoGetRequestorProcessId+0x11
8054fb8c 80669ef9 8672a3f8 8846af20 8672a4b0 tdipassl!TDIFltTdiConnectComplete+0x25f [tdifilterprobedispatch.c @ 252]
8054fbb0 804e3d38 8672a3f8 8846af20 8054fc14 nt!RtlCompressBuffer+0x28a2
8054fbe0 8066a3c9 8846af20 861ab620 00000000 nt!IofCompleteRequest+0x142
8054fc4c eec9cad2 86649700 86606a38 00000002 nt!RtlCompressBuffer+0x2d72
8054fc64 eeca2cc8 8846af20 00000000 00000000 tcpip!IPTransmit+0x1e94
8054fc78 eeca3ba5 8846af20 00000000 00000000 tcpip!ARPRcv+0x5855
8054fc98 eeca5a5a 86606a38 8054fe58 00000000 tcpip!ARPRcv+0x6732
8054fd1c eec99ef5 869f3180 7e14a8c0 0b0aa8c0 tcpip!ARPRcv+0x85e7
8054fd7c eec99b19 00000020 869f3180 eec9c076 tcpip!IPFreeBuff+0x634
8054fdf8 eec99836 eecd93f0 869f3180 864fe018 tcpip!IPFreeBuff+0x258
8054feb0 eec98922 869f3180 864fe02c 0000001c tcpip!IPRcvPacket+0x296
8054fef0 eec9884d 00000000 8654ae68 864fe00a tcpip!ARPRcvPacket+0x128
8054ff2c badb1f45 868b11c8 00000000 f6e86b40 tcpip!ARPRcvPacket+0x53
8054ff80 f6e8101d 006d01d8 86765380 00000001 NDIS!FddiFilterDprIndicateReceive+0xd4d
8054ff94 f6e811b4 86773608 86765380 00000001 psched!RegisterPsComponent+0x6cef
8054ffb8 f6e815f9 86668010 00000000 86773608 psched!RegisterPsComponent+0x6e86
8054ffd0 badb1d40 86668008 866f9008 00000001 psched!RegisterPsComponent+0x72cb
80550020 f6fb659e 006d01d8 80550060 00000001 NDIS!FddiFilterDprIndicateReceive+0xb48
80550170 f6fb7471 006f9008 8055019f 8686b308 e1000325+0x59e
80550194 bada7f09 006f9008 80558e80 80558c20 e1000325+0x1471
805501ac 804dbbd4 866f9460 866f944c 00000000 NDIS!NdisCompletePnPEvent+0x17b
ffdff980 00000000 f78a7000 00002e44 00000000 nt!KiDispatchInterrupt+0x360
?
?
STACK_COMMAND: kb
?
FOLLOWUP_IP:
tdipassl!TDIFltTdiConnectComplete+25f [tdifilterprobedispatch.c @ 252]
eec839bf 8b4dcc mov ecx,[ebp-0x34]
?
FAULTING_SOURCE_CODE:
248: }
249:
250:
251: pCommunicationInfo->FileObject = IrpSp->FileObject;

252: pCommunicationInfo->ProcessId = (UINT32)IoGetRequestorProcessId( Irp );
253:

?
?
SYMBOL_STACK_INDEX: 2
?
FOLLOWUP_NAME: MachineOwner
?
SYMBOL_NAME: tdipassl!TDIFltTdiConnectComplete+25f
?
MODULE_NAME: tdipassl
?
IMAGE_NAME: tdipassl.sys
?
kd> dt tdipassl!_IRP 8846af20
+0x000 Type : 6
+0x002 Size : 0xdc
+0x004 MdlAddress : (null)
+0x008 Flags : 0x40000000
+0x00c AssociatedIrp : __unnamed
+0x010 ThreadListEntry : _LIST_ENTRY [0x8846af30 - 0x8846af30]
+0x018 IoStatus : _IO_STATUS_BLOCK
+0x020 RequestorMode : 0 ‘’
+0x021 PendingReturned : 0x1 ‘’
+0x022 StackCount : 3 ‘’
+0x023 CurrentLocation : 2 ‘’
+0x024 Cancel : 0 ‘’
+0x025 CancelIrql : 0 ‘’
+0x026 ApcEnvironment : 0 ‘’
+0x027 AllocationFlags : 0x80 ‘’
+0x028 UserIosb : (null)
+0x02c UserEvent : (null)
+0x030 Overlay : __unnamed
+0x038 CancelRoutine : (null)
+0x03c UserBuffer : (null)
+0x040 Tail : __unnamed
?
On 4/2/06, Doron Holan wrote:
IoGetRequesterProcessId only works for PIRPs that are send by the I/O manager itself.??If AFD or some other driver is creating and sending the PIRP on its own, then this function cannot work.??If I remember how TDI is set up, you will not be able to use this function.

d

________________________________________
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Saturday, April 01, 2006 3:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI filter

Hi

In my TDI filter driver, I’m calling the function?? IoGetRequesterProcessId (Irp) from a completion routine (of my??TDI_CONNECT filter function) and sometimes I get BSOD of IRQL_NO_LESS_OR_EQUAL (a).??Driver verifier is also running in the background.

I started to analyze the dump, and found that
1. The irp is valid.
2. IoGetRequesterProcessId () calls IoGetProcess() in order to get EPROCESS structure of the requested process, and the structure I get is invalid (all structure data is invalid) but IoGetProcess() still returns success to IoGetRequesterProcessId () !!

The first thing I thought of is that the process was already ended, and therefore IoGetProcess got an invalid EPROCESS, but how can process be ended if I still have it’s irp in my completion routine?

Another idea is that this function is only supported in IFS ?!?? (I got it from there)

Thanks for any help, I really need it.
— 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

— 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

Zed y wrote:

Few points + I’m attaching the WinDbg output:

I put my TDI filter over TCP and UDP.

Driver Verifier was active while this BSOD happened. Maybe it’s the cause?

The filter ran on 5 computers for several days, so this function
worked most of the time.

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid)
address at an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 313730b7, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 805000ad, address which referenced memory

Did you notice that Arg1 contains ASCII? Based on the instruction in
the dump, eax contains the ASCII digits “1703” (which would be “3071” in
memory), when it was supposed to have an address… Something isn’t
pointing where it is supposed to.


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