hello,
i am trying to port my TDI driver for Windows 2008 64 bit server. i am running
into a problem.
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: fffff80001b2a2b4, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
chips which support this level of status)
Arg4: fffff80001b2a2b4, address which referenced memory
Debugging Details:
FAULTING_SOURCE_CODE:
63: PSID_AND_ATTRIBUTES sa;
64:
65: status = ZwOpenThreadToken(NtCurrentThread(), TOKEN_QUERY, FALSE,
&token);
66: if (status == STATUS_NO_TOKEN)
67: status = ZwOpenProcessToken(NtCurrentProcess(), TOKEN_QUERY, &token);
68: if (status != STATUS_SUCCESS)
69: {
70: // TODO: report error
71: return NULL;
72: }
i googled it and noticed people have similar problems with this function,
this function should be called at PASSIVE_LEVEL.
however i am calling this function when i receive the TDI_CONNECT IRP and before
setting up completion routine for TDI_CONNECT.
i guess TDI_CONNECT gets issued at PASSIVE_LEVEL. how should i resolve it.
this occures only on 2008 64 bit Server NOT on 2008 32 bit Server.
could someone show light on this.
P.S. started a new separate thread for this issue. since it is not related to TDI.
i guess.
am i doing any thing wrong here?. may be missing some basic thing.
i even looked at the tutorial present at OSR for getting the SID.
http://www.osronline.com/article.cfm?id=50
but did not find any clues. looks like again some things has changed from XP to VISTA+
regard
deep
Post the entire output of !analyze -v with symbols loaded for the OS.
As an aside, you really need to use the documented ZwOpenThreadTokenEx/ZwOpenProcessTokenEx + specify OBJ_KERNEL_HANDLE instead of the non-Ex versions. The non-Ex versions are not documented.
-----Original Message-----
From: xxxxx@yahoo.co.in
Sent: Tuesday, May 12, 2009 04:03
To: Windows System Software Devs Interest List
Subject: [ntdev] TDI_CONNECT and ZwOpenProcessToken + BSOD
hello,
i am trying to port my TDI driver for Windows 2008 64 bit server. i am running
into a problem.
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: fffff80001b2a2b4, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
chips which support this level of status)
Arg4: fffff80001b2a2b4, address which referenced memory
Debugging Details:
------------------
FAULTING_SOURCE_CODE:
63: PSID_AND_ATTRIBUTES sa;
64:
65: status = ZwOpenThreadToken(NtCurrentThread(), TOKEN_QUERY, FALSE,
&token);
66: if (status == STATUS_NO_TOKEN)
> 67: status = ZwOpenProcessToken(NtCurrentProcess(), TOKEN_QUERY, &token);
68: if (status != STATUS_SUCCESS)
69: {
70: // TODO: report error
71: return NULL;
72: }
i googled it and noticed people have similar problems with this function,
this function should be called at PASSIVE_LEVEL.
however i am calling this function when i receive the TDI_CONNECT IRP and before
setting up completion routine for TDI_CONNECT.
i guess TDI_CONNECT gets issued at PASSIVE_LEVEL. how should i resolve it.
this occures only on 2008 64 bit Server NOT on 2008 32 bit Server.
could someone show light on this.
P.S. started a new separate thread for this issue. since it is not related to TDI.
i guess.
am i doing any thing wrong here?. may be missing some basic thing.
i even looked at the tutorial present at OSR for getting the SID.
http://www.osronline.com/article.cfm?id=50
but did not find any clues. looks like again some things has changed from XP to VISTA+
regard
deep
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
hello Ken,
here is the stack trace!
1: kd> u fffff80001b2a2b4
nt!NtOpenProcessToken:
fffff80001b2a2b4 4d8bc8 mov r9,r8 fffff80001b2a2b7 4533c0 xor r8d,r8d
fffff80001b2a2ba e9a9feffff jmp nt!NtOpenProcessTokenEx (fffff80001b2a168)
fffff80001b2a2bf 90 nop fffff80001b2a2c0 90 nop
fffff80001b2a2c1 90 nop fffff80001b2a2c2 90 nop
fffff800`01b2a2c3 90 nop
0000000000000002 0000000000000008 : nt!KeBugCheckEx
fffffa600171a580 fffff800018b700b : 0000000000000008 0000000000000000 fffffa600171aa00 fffffa60005f5d40 : nt!KiBugCheckDispatch+0x6e
fffffa600171a6c0 fffff80001b2a2b4 : fffff800018b7e33 fffffa8003758900 fffffa600171a8c8 0000000000910000 : nt!KiPageFault+0x20b
fffffa600171a858 fffff800018b7e33 : fffffa8003758900 fffffa600171a8c8 0000000000910000 fffff8000194d15f : nt!NtOpenProcessToken
fffffa600171a860 fffff800018b8340 : fffffa6002586456 fffff980065dce50 0000000000000002 fffffa8002e26de0 : nt!KiSystemServiceCopyEnd+0x13
fffffa600171a9f8 fffffa6002586456 : fffff980065dce50 0000000000000002 fffffa8002e26de0 fffffa800392ccd0 : nt!KiServiceLinkage
fffffa600171aa00 fffffa6002586f0e : fffff98004d64fb0 fffffa60009e16f0 fffffa8002e2aae8 fffff980065dcfb0 : MyTDI!getCallerSid+0x46 [c:\driver\sa.c @ 67]
fffffa600171aa60 fffffa6002586d62 : fffff980065dce50 fffffa600171ab60 fffffa600171ab68 500056d214000000 : MyTDI!HandleTDIConnect+0x9e [c:\driver\TDIsnoop.c @ 430]
fffffa600171aae0 fffffa60025858d7 : fffff980065dce50 fffffa600171ab60 fffffa600171ab68 fffffa60009e16f0 : MyTDI!snoopHandleRequest+0x182 [c:\driver\TDIsnoop.c @ 366]
fffffa600171ab30 fffffa6002585d17 : fffffa8002e26de0 fffff980065dce50 fffffa8001d21d50 00000000000001a8 : MyTDI!snoopDispatch+0x27 [c:\driver\main.c @ 56]
fffffa600171abb0 fffff80001cc859a : fffffa8002e26de0 fffff980065dce50 fffffa60009e16f0 0000000000000000 : MyTDI!dispatch+0xd7 [c:\driver\main.c @ 142]
fffffa600171ac20 fffffa6002673442 : fffffa600171ace0 fffffa8002e26de0 fffff98006462e50 fffffa800392ccd0 : nt!IovCallDriver+0x34a
fffffa600171ac60 fffffa6002674ef8 : fffff98006462e50 00000000ac10000b 000000000b0010ac fffffa6002673320 : netbt!TdiConnect+0x111
fffffa600171acb0 fffffa6002673248 : 00000000ac10000b fffffa8002e5eb10 fffffa8003a2a220 fffffa8002e2a930 : netbt!TcpSessionStart+0xc8
fffffa600171ad10 fffffa6002672067 : 0000000000000012 fffffa60ac10000b fffffa8002e2a930 fffffa8003a2a220 : netbt!SessionSetupContinue+0x319
fffffa600171ad80 fffffa60026775f6 : 0000000000000000 0000000000000000 fffffa8002e2a930 0000000000000002 : netbt!CompleteClientReq+0x93
fffffa600171adf0 fffffa600267763c : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : netbt!QueryFromNet+0x7d2
fffffa600171af10 fffffa6002676d32 : fffffa8002e4a108 0000000000000000 0000000000000000 0000000000000000 : netbt!NameSrvHndlrNotOs+0xc6
fffffa600171af50 fffffa600256a192 : fffffa8002eb7540 0000000000000000 0000000000000000 fffffa8002b19350 : netbt!TdiRcvNameSrvHandler+0x35b
fffffa600171aff0 fffffa6000e4d8e3 : fffffa8002eb7540 fffffa8002eb7540 fffffa8002eb7540 fffffa6000000000 : tdx!TdxEventReceiveMessagesTransportAddress+0x56b
fffffa600171b1e0 fffffa6000e4d5c8 : fffffa8002aa0000 fffffa8002eb7540 fffffa8000000000 fffffa6001fea02c : tcpip!UdpDeliverDatagrams+0x163
fffffa600171b340 fffffa6000e76f5f : fffffa8002e46010 0000000000000000 fffffa6001710002 fffff80001cc41ed : tcpip!UdpReceiveDatagrams+0x1c8
fffffa600171b420 fffffa6000e7437b : fffffa8002e27720 fffffa8002e44120 fffffa8002c80011 fffffa6000970002 : tcpip!IpFlcReceivePreValidatedPackets+0x6ff
fffffa600171b570 fffffa60009ac33c : fffffa8002e27010 0000000000000000 fffffa600171b700 fffffa8002b941a0 : tcpip!FlReceiveNetBufferListChain+0x9b
fffffa600171b5c0 fffffa6000975266 : fffffa600171b720 fffffa600171b730 0000000000000001 0000000000000001 : NDIS!ndisMIndicateNetBufferListsToOpen+0xac
fffffa600171b610 fffffa6000809867 : fffffa8002b941a0 0000000000000002 0000000040000000 0000000000000002 : NDIS!ndisMDispatchReceiveNetBufferLists+0x1d6
fffffa600171ba90 fffffa60020323e2 : 0000000000000000 0000000000000000 0000000000000000 0000000051d9e53a : NDIS!NdisMIndicateReceiveNetBufferLists+0x67
fffffa600171bad0 fffffa6002032e1b : fffffa8002c22000 0000000000000000 0000000000000047 fffffa600171bb01 : b57nd60a!shoot_nbls_up+0xc6
fffffa600171bb40 fffffa6002023f70 : fffffa8000000000 0000000000000001 43454e4e4f434400 2020202000000000 : b57nd60a!nd6x_ServiceRxRetProdRing+0x783
fffffa600171bc00 fffffa6002013726 : 01c9cdb4e0dfd986 00000000000000dd 0000000000000000 fffffa8003a40b80 : b57nd60a!LM_ServiceInterrupts+0x208
fffffa600171bc30 fffffa600201479e : fffffa8002c22000 0000000000000000 fffffa60005ef580 0000000000000000 : b57nd60a!UM_IndicateLinkToOs+0xb82
fffffa600171bc60 fffffa60008222b7 : fffffa8002c30000 0000000000000000 fffffa60005ef580 0000000000000000 : b57nd60a!UM_Dpc+0xbe
fffffa600171bc90 fffff800018c19d7 : 0000000000000000 fffff800018d37e0 0000000000000000 fffffa60005ef580 : NDIS! ?? ::FNODOBFM::`string’+0x48fc
regards
deep
You need to be at passive to invoke any Zw routine. Note that you’re being called by a DPC here.
-----Original Message-----
From: xxxxx@yahoo.co.in
Sent: Tuesday, May 12, 2009 20:34
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] TDI_CONNECT and ZwOpenProcessToken + BSOD
hello Ken,
here is the stack trace!
---------
1: kd> u fffff80001b2a2b4
nt!NtOpenProcessToken:
fffff80001b2a2b4 4d8bc8 mov r9,r8<br>fffff80001b2a2b7 4533c0 xor r8d,r8d
fffff80001b2a2ba e9a9feffff jmp nt!NtOpenProcessTokenEx (fffff80001b2a168)
fffff80001b2a2bf 90 nop<br>fffff80001b2a2c0 90 nop
fffff80001b2a2c1 90 nop<br>fffff80001b2a2c2 90 nop
fffff80001b2a2c3 90 nop<br><br>0000000000000002 0000000000000008 : nt!KeBugCheckEx<br>fffffa600171a580 fffff800018b700b : 0000000000000008 0000000000000000 fffffa600171aa00 fffffa60005f5d40 : nt!KiBugCheckDispatch+0x6e<br>fffffa600171a6c0 fffff80001b2a2b4 : fffff800018b7e33 fffffa8003758900 fffffa600171a8c8 0000000000910000 : nt!KiPageFault+0x20b<br>fffffa600171a858 fffff800018b7e33 : fffffa8003758900 fffffa600171a8c8 0000000000910000 fffff8000194d15f : nt!NtOpenProcessToken<br>fffffa600171a860 fffff800018b8340 : fffffa6002586456 fffff980065dce50 0000000000000002 fffffa8002e26de0 : nt!KiSystemServiceCopyEnd+0x13<br>fffffa600171a9f8 fffffa6002586456 : fffff980065dce50 0000000000000002 fffffa8002e26de0 fffffa800392ccd0 : nt!KiServiceLinkage<br>fffffa600171aa00 fffffa6002586f0e : fffff98004d64fb0 fffffa60009e16f0 fffffa8002e2aae8 fffff980065dcfb0 : MyTDI!getCallerSid+0x46 [c:\driver\sa.c @ 67]<br>fffffa600171aa60 fffffa6002586d62 : fffff980065dce50 fffffa600171ab60 fffffa600171ab68 500056d214000000 : MyTDI!HandleTDIConnect+0x9e [c:\driver\TDIsnoop.c @ 430]<br>fffffa600171aae0 fffffa60025858d7 : fffff980065dce50 fffffa600171ab60 fffffa600171ab68 fffffa60009e16f0 : MyTDI!snoopHandleRequest+0x182 [c:\driver\TDIsnoop.c @ 366]<br>fffffa600171ab30 fffffa6002585d17 : fffffa8002e26de0 fffff980065dce50 fffffa8001d21d50 00000000000001a8 : MyTDI!snoopDispatch+0x27 [c:\driver\main.c @ 56]<br>fffffa600171abb0 fffff80001cc859a : fffffa8002e26de0 fffff980065dce50 fffffa60009e16f0 0000000000000000 : MyTDI!dispatch+0xd7 [c:\driver\main.c @ 142]<br>fffffa600171ac20 fffffa6002673442 : fffffa600171ace0 fffffa8002e26de0 fffff98006462e50 fffffa800392ccd0 : nt!IovCallDriver+0x34a<br>fffffa600171ac60 fffffa6002674ef8 : fffff98006462e50 00000000ac10000b 000000000b0010ac fffffa6002673320 : netbt!TdiConnect+0x111<br>fffffa600171acb0 fffffa6002673248 : 00000000ac10000b fffffa8002e5eb10 fffffa8003a2a220 fffffa8002e2a930 : netbt!TcpSessionStart+0xc8<br>fffffa600171ad10 fffffa6002672067 : 0000000000000012 fffffa60ac10000b fffffa8002e2a930 fffffa8003a2a220 : netbt!SessionSetupContinue+0x319<br>fffffa600171ad80 fffffa60026775f6 : 0000000000000000 0000000000000000 fffffa8002e2a930 0000000000000002 : netbt!CompleteClientReq+0x93<br>fffffa600171adf0 fffffa600267763c : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : netbt!QueryFromNet+0x7d2<br>fffffa600171af10 fffffa6002676d32 : fffffa8002e4a108 0000000000000000 0000000000000000 0000000000000000 : netbt!NameSrvHndlrNotOs+0xc6<br>fffffa600171af50 fffffa600256a192 : fffffa8002eb7540 0000000000000000 0000000000000000 fffffa8002b19350 : netbt!TdiRcvNameSrvHandler+0x35b<br>fffffa600171aff0 fffffa6000e4d8e3 : fffffa8002eb7540 fffffa8002eb7540 fffffa8002eb7540 fffffa6000000000 : tdx!TdxEventReceiveMessagesTransportAddress+0x56b<br>fffffa600171b1e0 fffffa6000e4d5c8 : fffffa8002aa0000 fffffa8002eb7540 fffffa8000000000 fffffa6001fea02c : tcpip!UdpDeliverDatagrams+0x163<br>fffffa600171b340 fffffa6000e76f5f : fffffa8002e46010 0000000000000000 fffffa6001710002 fffff80001cc41ed : tcpip!UdpReceiveDatagrams+0x1c8<br>fffffa600171b420 fffffa6000e7437b : fffffa8002e27720 fffffa8002e44120 fffffa8002c80011 fffffa6000970002 : tcpip!IpFlcReceivePreValidatedPackets+0x6ff<br>fffffa600171b570 fffffa60009ac33c : fffffa8002e27010 0000000000000000 fffffa600171b700 fffffa8002b941a0 : tcpip!FlReceiveNetBufferListChain+0x9b<br>fffffa600171b5c0 fffffa6000975266 : fffffa600171b720 fffffa600171b730 0000000000000001 0000000000000001 : NDIS!ndisMIndicateNetBufferListsToOpen+0xac<br>fffffa600171b610 fffffa6000809867 : fffffa8002b941a0 0000000000000002 0000000040000000 0000000000000002 : NDIS!ndisMDispatchReceiveNetBufferLists+0x1d6<br>fffffa600171ba90 fffffa60020323e2 : 0000000000000000 0000000000000000 0000000000000000 0000000051d9e53a : NDIS!NdisMIndicateReceiveNetBufferLists+0x67<br>fffffa600171bad0 fffffa6002032e1b : fffffa8002c22000 0000000000000000 0000000000000047 fffffa600171bb01 : b57nd60a!shoot_nbls_up+0xc6<br>fffffa600171bb40 fffffa6002023f70 : fffffa8000000000 0000000000000001 43454e4e4f434400 2020202000000000 : b57nd60a!nd6x_ServiceRxRetProdRing+0x783<br>fffffa600171bc00 fffffa6002013726 : 01c9cdb4e0dfd986 00000000000000dd 0000000000000000 fffffa8003a40b80 : b57nd60a!LM_ServiceInterrupts+0x208<br>fffffa600171bc30 fffffa600201479e : fffffa8002c22000 0000000000000000 fffffa60005ef580 0000000000000000 : b57nd60a!UM_IndicateLinkToOs+0xb82<br>fffffa600171bc60 fffffa60008222b7 : fffffa8002c30000 0000000000000000 fffffa60005ef580 0000000000000000 : b57nd60a!UM_Dpc+0xbe<br>fffffa600171bc90 fffff800018c19d7 : 0000000000000000 fffff800018d37e0 0000000000000000 fffffa60005ef580 : NDIS! ?? ::FNODOBFM::string’+0x48fc
regards
deep
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
hello Ken ,
thanks for your input.
here is what i think according to your suggestion.
-
when i get OpenAddress() . i will allocate the memory from NP pool and save the “FileObject” field. then i would enque it to the list.
-
later i am going to get TDI_CONNECT i will serch in the list for FileObject that is passed with TDI_CONNECT. i will remove this record from the list and fill the other info like Address and would enque to different list which will be processed when it gets IOCTL from the Application !!
does this make any sense?
regards
deep
hello,
here is one more trouble i found.
as i explained . i am maintaining a Double Link List for keeping track of FILE
objects.
and when i get TDI_CONNECT i seach through the List to find out the
FileObject.
now as this is being called at DISPATCH_LEVEL and perhaps DPC. i am hitting a time out. as list treaversing may take time.
so system gets hanged!!
will someone please suggest me how to get the SID at appropriate place?
here is the stack trace
Child-SP RetAddr Call Site
fffffa600bb51408 fffff800018ad3d7 nt!RtlpBreakWithStatusInstruction
fffffa600bb51410 fffff80001857eba nt! ?? ::FNODOBFM::string'+0x356a fffffa600bb51450 fffff80001d3140f nt!KeUpdateSystemTime+0xea fffffa600bb51480 fffff8000185fb2d hal!HalpRtcClockInterrupt+0x127 fffffa600bb514b0 fffffa60023c43b8 nt!KiInterruptDispatchNoLock+0x14d fffffa600bb51640 fffffa60023c443d MyTDI!FindSnoopEvent+0x98 [c:\driver\snoop.c @ 534] fffffa600bb51690 fffffa60023c4212 MyTDI!HandleTDIConnect+0x4d [c:\driver\snoop.c @ 553] fffffa600bb516e0 fffffa60023c28d7 MyTDI!snoopHandleRequest+0x182 [c:\driver\snoop.c @ 461] fffffa600bb51730 fffffa60023c2d17 MyTDI!snoopDispatch+0x27 [c:\driver\main.c @ 56] fffffa600bb517b0 fffffa600a851f5d MyTDI!dispatch+0xd7 [c:\driver\main.c @ 142] fffffa600bb51820 fffff80001ae425a afd! ?? ::GFJBLGFE::string’+0x880b
fffffa600bb519f0 fffff80001afcf76 nt!IopXxxControlFile+0x5da
fffffa600bb51b40 fffff8000185de33 nt!NtDeviceIoControlFile+0x56
fffffa600bb51bb0 0000000077375aea nt!KiSystemServiceCopyEnd+0x13
000000000209d0d8 000007fefce060ec ntdll!ZwDeviceIoControlFile+0xa
regards
deep
hello,
will someone please tell me. what i am doing wrong. i notice a system hang and call stack does not reveal much
Child-SP RetAddr Call Site
fffff80002afbaa8 fffff800018f23d7 nt!RtlpBreakWithStatusInstruction
fffff80002afbab0 fffff8000189ceba nt! ?? ::FNODOBFM::string'+0x356a fffff80002afbaf0 fffff8000181840f nt!KeUpdateSystemTime+0xea fffff80002afbb20 fffff800018a4b2d hal!HalpRtcClockInterrupt+0x127 fffff80002afbb50 fffffa60020bc7a2 nt!KiInterruptDispatchNoLock+0x14d fffff80002afbce8 fffffa60020bb685 intelppm!C1Halt+0x2 fffff80002afbcf0 fffff800018be7c8 intelppm!C1Idle+0x9 fffff80002afbd20 fffff800018adb31 nt!PoIdle+0x148 fffff80002afbd80 fffff80001a7b5c0 nt!KiIdleLoop+0x21 fffff80002afbdb0 00000000fffff800 nt!zzz_AsmCodeRange_End+0x4 fffff80002af50b0 00000000`00000000 0xfffff800
i am sure this is because of my driver. what is the other way of keeping track of IRP_MJ_CREATE and TDI_CONNECT. so that i could query SID at IRP_MJ_CREATE and address Info at TDI_CONNECT
regards
deep
hello to all,
here is my further investigation.
i have struct called ksnoop_event_Partial_t
{
LIST_ENTRY list;
ULONG_PTR fileobj;
PSID_AND_ATTRIBUTES sa;
ULONG sa_size;
}
when ever i get an OpenAddress() Request i add one structure entry to the Double Link List.
after filling the File Object with SID.
now when i get TDI_CONNECT. i traverse through the list like this
ksnoop_event_Partial_t* FindSnoopEvent( ULONG_PTR FileObject )
{
KIRQL irql;
//get the device extension
dev_ext_t* dxctl = (dev_ext_t *)g_dev->DeviceExtension;
ksnoop_event_Partial_t *evt = NULL;
ksnoop_event_Partial_t *evtRet = NULL;
PLIST_ENTRY pEntry = NULL;
KeAcquireSpinLock(&dxctl->Partial_evt_lock, &irql);
pEntry = dxctl->evt_Partial_queue.Flink;
while(pEntry != &dxctl->evt_Partial_queue)
{
evt = (ksnoop_event_Partial_t *) CONTAINING_RECORD(pEntry,ksnoop_event_Partial_t,list);
if(evt->fileobj == FileObject)
{
RemoveEntryList(pEntry);
dxctl->evt_Partial_queue_len–;
evtRet = evt;
break;
}
pEntry = pEntry->Flink;
}
KeReleaseSpinLock(&dxctl->Partial_evt_lock, irql);
return evtRet;
}
i think this traversing is taking too much time. as i am comparing the 64 bit pointers.
hence when when my code is run by DPC. system gets hanged.
am i right here, or doing this completely wrong?
i looked at osronline for hashing and found a sample . do you think that if i implement hashing here
it will resolve my problem?
regards
deep
How many items are in the list when you think you are spending too much time at dpc?
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@yahoo.co.in
Sent: Thursday, May 14, 2009 4:51 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] TDI_CONNECT and ZwOpenProcessToken + BSOD
hello to all,
here is my further investigation.
i have struct called ksnoop_event_Partial_t
{
LIST_ENTRY list;
ULONG_PTR fileobj;
PSID_AND_ATTRIBUTES sa;
ULONG sa_size;
}
when ever i get an OpenAddress() Request i add one structure entry to the Double Link List.
after filling the File Object with SID.
now when i get TDI_CONNECT. i traverse through the list like this
ksnoop_event_Partial_t* FindSnoopEvent( ULONG_PTR FileObject )
{
KIRQL irql;
//get the device extension
dev_ext_t* dxctl = (dev_ext_t *)g_dev->DeviceExtension;
ksnoop_event_Partial_t *evt = NULL;
ksnoop_event_Partial_t *evtRet = NULL;
PLIST_ENTRY pEntry = NULL;
KeAcquireSpinLock(&dxctl->Partial_evt_lock, &irql);
pEntry = dxctl->evt_Partial_queue.Flink;
while(pEntry != &dxctl->evt_Partial_queue)
{
evt = (ksnoop_event_Partial_t *) CONTAINING_RECORD(pEntry,ksnoop_event_Partial_t,list);
if(evt->fileobj == FileObject)
{
RemoveEntryList(pEntry);
dxctl->evt_Partial_queue_len–;
evtRet = evt;
break;
}
pEntry = pEntry->Flink;
}
KeReleaseSpinLock(&dxctl->Partial_evt_lock, irql);
return evtRet;
}
i think this traversing is taking too much time. as i am comparing the 64 bit pointers.
hence when when my code is run by DPC. system gets hanged.
am i right here, or doing this completely wrong?
i looked at osronline for hashing and found a sample . do you think that if i implement hashing here
it will resolve my problem?
regards
deep
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
xxxxx@yahoo.co.in wrote:
hello to all,
here is my further investigation.
…
i think this traversing is taking too much time. as i am comparing the 64 bit pointers.
hence when when my code is run by DPC. system gets hanged.
am i right here, or doing this completely wrong?
You THINK this is taking too much time? Are you saying you have never
once set a breakpoint on this routine and single-stepped through it to
see why it takes so much time? That would have been the FIRST thing I
did. I suspect you will find that your list head pointer is not
properly initialized, although there are other things that could cause
trouble here.
i looked at osronline for hashing and found a sample . do you think that if i implement hashing here
it will resolve my problem?
This is called “debugging through wishful thinking”, and is almost never
a successful path.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
hello Tim and Doron,
thanks for your reply. sorry for late reply.
Tim.
it is not that i was not doing debugging or stepping through the code.
this problem was somewhere else. why i guessed that is because of the stack trace i got.
i was using a TDI building a macro that should only be called at PASSIVE_LEVEL.
i replaced it with the IoAllocateIrp(). and thing worked fine.
i am thankful to you since after your reply i re-think and checked the logs. 
i have a small question that as i told you that i am using a list for keeping track of
FILE_OBJECT in IRP_NJ_CREATE and TDI_CONNECT. the list size i am keeping is 1024.
what could be the best size of list that will not degrade the system performance.
as i am allocating from NP memory.
regards
deep
hello,
may be this could help you to provide me a better suggestion.
i am only concerned in SID and IP addresses. and on the machine multiple user could connect,
i have to find out the IP with SID of the user and send it to the User Mode app.
since the number of FILE_OBJECT could be as large as possible depending on number of the users
logged on. i need to build a efficient method for it.
may be hash of 0x1000 entries…
regards
deep