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.
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>