Strange problem of tdifw.

*******************************************************************************
* *
* 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 memory

Debugging 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 scope

LAST_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:\tdifw\ev_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+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
tdifw!tdi_event_connect+135 [e:\tdifw\ev_conn.c @ 88]
ba177ce9 3d160000c0 cmp eax,0C0000016h

FAULTING_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 from sourceforge.net 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.

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.

Thanks in advance.

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

Have you inspected the structure in the debugger? You’ll be able to see from
there if the field is NULL (it almost 100% surely is).

If you checked it for NULL previously but it’s NULL now, then it’s possible
that you’re dealing with a race condition…Another possibility would be a
memory scribble. Does the rest of the structure look OK?

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@windbg…
> ***
> *
>
> * 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 memory
>
> Debugging 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 scope
>
> LAST_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:\tdifw\ev_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+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> tdifw!tdi_event_connect+135 [e:\tdifw\ev_conn.c @ 88]
> ba177ce9 3d160000c0 cmp eax,0C0000016h
>
> FAULTING_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 from
> sourceforge.net 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.
>
> 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.
>
> Thanks in advance.
>