Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

HELP: IoGetRequesterProcessId (Irp) Crashes inside TDI filter

zedyzedy Member Posts: 20
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.

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,438
    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
    d
  • zedyzedy Member Posts: 20
    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
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
  • zedyzedy Member Posts: 20
    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 :)
    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
    >
  • David_R._CattleyDavid_R._Cattley Member - All Emails Posts: 2,112
    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 <xxxxx@microsoft.com> 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@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
    <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
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,438
    "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 <xxxxx@microsoft.com> 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
    d
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,035
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA