- This topic has 2 replies, 2 voices, and was last updated 15 years, 3 months ago by
.
-
Posts
-
I’m using tdifw(sourceforge.net) on a Windows 2003 Server(Web server) and sometimes I had a sort of BSOD like this.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************Use !analyze -v to get detailed debugging information.
BugCheck D1, {0, d0000002, 0, 0}
Probably caused by : tdifw.sys ( tdifw!tdi_event_connect+135 )
Followup: MachineOwner
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: d0000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memoryDebugging Details:
READ_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
+0
00000000 ?? ???PROCESS_NAME: System
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
TRAP_FRAME: f78f693c — (.trap 0xfffffffff78f693c)
ErrCode = 00000000
eax=00000000 ebx=87ad6c04 ecx=ba17b202 edx=00000000 esi=f78f6ab0 edi=00000002
eip=00000000 esp=f78f69b0 ebp=f78f6a70 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
00000000 ?? ???
Resetting default scopeLAST_CONTROL_TRANSFER: from 00000000 to 80836df5
FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???STACK_TEXT:
f78f693c 00000000 badb0d00 00000000 00000000 nt!KiTrap0E+0x2a7
WARNING: Frame IP not in any known module. Following frames may be wrong.
f78f69ac ba177ce9 00000000 00000016 f78f6ad8 0x0
f78f6a70 b9b1a9a9 02ad6c04 00000016 f78f6ad8 tdifw!tdi_event_connect+0x135 [e:tdifwev_conn.c @ 88]
f78f6af4 b9b1abaa 87aa0560 0100007f 0000fa0a tcpip!DelayedAcceptConn+0xbe
f78f6bc8 b9b0e239 893f3990 0100007f 0100007f tcpip!TCPRcv+0xddb
f78f6c28 b9b0c45e 00000024 893f3990 b9b119a4 tcpip!DeliverToUser+0x189
f78f6cb8 b9b1821e 893f3990 f78f6d30 00000014 tcpip!IPRcvPacket+0x686
f78f6d64 f7598064 b9b4ce60 893f3990 8aa32db0 tcpip!LoopXmitRtn+0x195
f78f6d80 8082db10 893f3990 00000000 8aa32db0 TDI!CTEpEventHandler+0x32
f78f6dac 80920833 b9b4ce60 00000000 00000000 nt!ExpWorkerThread+0xeb
f78f6ddc 8083fe9f 8082da53 00000001 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16STACK_COMMAND: kb
FOLLOWUP_IP:
tdifw!tdi_event_connect+135 [e:tdifwev_conn.c @ 88]
ba177ce9 3d160000c0 cmp eax,0C0000016hFAULTING_SOURCE_CODE:
84: ((PTDI_IND_CONNECT)(ctx->old_handler)) (ctx->old_context, RemoteAddressLength, RemoteAddress,
85: UserDataLength, UserData, OptionsLength, Options, ConnectionContext,
86: AcceptIrp);
87:
> 88: if (status != STATUS_MORE_PROCESSING_REQUIRED || !*AcceptIrp) {
89: result = FILTER_DENY;
90: goto done;
91: }
92:
93: irps = IoGetCurrentIrpStackLocation(*AcceptIrp);SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: tdifw!tdi_event_connect+135
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: tdifw
IMAGE_NAME: tdifw.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4aa75af8
FAILURE_BUCKET_ID: 0xD1_VRF_CODE_AV_NULL_IP_tdifw!tdi_event_connect+135
BUCKET_ID: 0xD1_VRF_CODE_AV_NULL_IP_tdifw!tdi_event_connect+135
Followup: MachineOwner
According to analyze, BSOD has occurred because tdifw driver access illegal memory address.
I think that BSOD has occurred when the original event connect(PTDI_IND_CONNECT) is being called.
All the information above, tdifw driver seems to have bad behavior.How should I solve this problem?
Thanks in advance!It looks like ctx->old_handler = NULL. You can inspect the code to check how could it happen, may be this is a sort of race condition.
First of all, I really thank you for your advices.
I’ve already checked whether ctx->old_handler is NULL or not.
If NULL, I returned STATUS_CONNECTION_REFUSED without calling PTDI_IND_CONNECT.
That is, if(ctx->old_handler == NULL) return STATUS_CONNECTION_REFUSED;I think that there are structural problems in the tdifw.
Whenever a problem occurs, it aways related with DelayedAcceptConn operation of
the tdifw.
According to the
analysis(http://pennerslife.blogspot.com/2009/04/drvier-crash-dump-analysis.html)
of the problem similar to mine, AcceptIrp had been already freed even though
ClientEventConnect event handler returned STATUS_MORE_PROCESSING_REQUIRED.
AcceptIrp is the last output parameter of the PTDI_IND_CONNECT function.I wonder that the tdifw isn’t handling STATUS_MORE_PROCESSING_REQUIRED
correctly.
If then, how can I fix the problem?Next, is the following scenario available?
Before calling PTDI_IND_CONNECT function, I will check the validity of AcceptIrp
by calling MmIsAddressValid function.
If not valid, I will just return STATUS_CONNECTION_REFUSED without calling
PTDI_IND_CONNECT.
That is, if(!MmIsAddressValid(*AcceptIrp)) return STATUS_CONNECTION_REFUSED;
I wonder that this can be a solution to the problem.Ask advice!
- You must be logged in to reply to this topic.