A BSOD problem of tdifw.

Home Forums Discussions General A BSOD problem of tdifw.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #5303

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

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


      00000000 ?? ???

      PROCESS_NAME: System


      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

      00000000 ?? ???

      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+0x16


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

      84: ((PTDI_IND_CONNECT)(ctx->old_handler)) (ctx->old_context, RemoteAddressLength, RemoteAddress,
      85: UserDataLength, UserData, OptionsLength, Options, ConnectionContext,
      86: AcceptIrp);
      > 88: if (status != STATUS_MORE_PROCESSING_REQUIRED || !*AcceptIrp) {
      89: result = FILTER_DENY;
      90: goto done;
      91: }
      93: irps = IoGetCurrentIrpStackLocation(*AcceptIrp);


      SYMBOL_NAME: tdifw!tdi_event_connect+135

      FOLLOWUP_NAME: MachineOwner

      MODULE_NAME: tdifw

      IMAGE_NAME: tdifw.sys


      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!

      Vadim Smirnov

        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
          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
          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
          That is, if(!MmIsAddressValid(*AcceptIrp)) return STATUS_CONNECTION_REFUSED;
          I wonder that this can be a solution to the problem.

          Ask advice!

        Viewing 3 posts - 1 through 3 (of 3 total)
        • You must be logged in to reply to this topic.