8e bugcheck

Hi,

I am developing a TDI driver to filter TCP communication. The filtering part works fine but the driver is causing 8e crash because of unhandled exception. I some help to analyse the root cause of the exception.

I suspect that the the crash seems is happening because of unavailability of parameter to KeAcquireInStackQueuedSpinLock(). I have stored the RuleSpinlock in device extension and I am not able to understand why it will not be available to the device at any point in time.

Here is the code which crashes
NTSTATUS tdi_Dispatch( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp )
{
// variable init

pirp_stack = IoGetCurrentIrpStackLocation(Irp);

if (DeviceObject->DeviceType == FILE_DEVICE_NETWORK)
{
pDeviceExt = ((PDEVICE_EXTENSION) DeviceObject->DeviceExtension);

if( (pirp_stack->MajorFunction == IRP_MJ_INTERNAL_DEVICE_CONTROL)&&
(pirp_stack->MinorFunction == TDI_CONNECT) )
{
PTDI_REQUEST_KERNEL_SENDDG pParams = (PTDI_REQUEST_KERNEL_SENDDG)(&pirp_stack->Parameters);
TA_ADDRESS *pRemoteAddress = ((TRANSPORT_ADDRESS *)(pParams->SendDatagramInformation->RemoteAddress))->Address;
TDI_ADDRESS_IP *pAddrr = (TDI_ADDRESS_IP*)pRemoteAddress->Address;

Port = (pAddrr->sin_port >> 8) | (pAddrr->sin_port << 8);

IoGetRequestorSessionId(Irp, &lSessionID);

//Some time this runs at DISPATCH level therefore using Spinlog instead of mutex here
KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock), &LockQueueHandle);

// do the filtering

KeReleaseInStackQueuedSpinLock (&LockQueueHandle);

}
}

//
// Pass the IRP to the target without touching the IRP
//
IoSkipCurrentIrpStackLocation(Irp);

return IoCallDriver(pDeviceExt->TopOfStack, Irp);
}

Here is !analyze -v

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8085647e, The address that the exception occurred at
Arg3: f69f4900, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!MmGetSessionId+8
8085647e f680f801000004 test byte ptr [eax+1F8h],4

TRAP_FRAME: f69f4900 – (.trap 0xfffffffff69f4900)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=823fb240 edx=00bd0100 esi=82381a28 edi=81f90978
eip=8085647e esp=f69f4974 ebp=f69f4974 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!MmGetSessionId+0x8:
8085647e f680f801000004 test byte ptr [eax+1F8h],4 ds:0023:000001f8=00
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0x8E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 8081c948 to 8085647e

STACK_TEXT:
f69f4974 8081c948 00000000 f69f49f4 f7860550 nt!MmGetSessionId+0x8
f69f4980 f7860550 823fb240 f69f49f0 81f90978 nt!IoGetRequestorSessionId+0x1a
f69f49f4 8081d5a3 82354020 823fb240 823fb240 XcdmTDIFlt!tdi_Dispatch+0xf0 [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
f69f4a08 f6d1f35b 81ff0fcc 823ef008 81ff0ed8 nt!IofCallDriver+0x45
f69f4a20 f6d1e224 81feb008 f6cca350 81ff0fcc netbt!TdiConnect+0xd8
f69f4a58 f6d1fe6b 00ff0ed8 0a010a6e 82240290 netbt!TcpSessionStart+0x9c
f69f4a98 f6d1ff28 82240290 00000000 00000000 netbt!SessionSetupContinue+0x27f
f69f4ac0 f6d3a3b4 f6d1fc49 81ff0ed8 00000000 netbt!CompleteClientReq+0x92
f69f4b64 f6d2042e 82439b80 f7a8d29c 00000001 netbt!NbtCompleteLmhSvcRequest+0x29b
f69f4ba4 f6d39282 820c3d08 f7a8d090 00000278 netbt!NtProcessLmHSvcIrp+0x130
f69f4bfc f6d391e2 820c3d08 f7a8d090 00000278 netbt!DispatchIoctls+0x586
f69f4c3c 8081d5a3 820c3d08 81ed6cc8 81f2bd20 netbt!NbtDispatchDevCtrl+0xce
f69f4c50 808ed3e1 81ed6d38 81fa6f58 81ed6cc8 nt!IofCallDriver+0x45
f69f4c64 808ee169 820c3d08 81ed6cc8 81fa6f58 nt!IopSynchronousServiceTail+0x10b
f69f4d00 808e6cca 00000158 00000124 00000000 nt!IopXxxControlFile+0x5e5
f69f4d34 80883908 00000158 00000124 00000000 nt!NtDeviceIoControlFile+0x2a
f69f4d34 7c8285ec 00000158 00000124 00000000 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0095fb54 00000000 00000000 00000000 00000000 0x7c8285ec

STACK_COMMAND: kb

FOLLOWUP_IP:
XcdmTDIFlt!tdi_Dispatch+f0 [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
f7860550 8b4dc8 mov ecx,dword ptr [ebp-38h]

FAULTING_SOURCE_CODE:
292: //check it while installation of SFA
293: IoGetRequestorSessionId(Irp, &lSessionID);
294:
295: //Some time this runs at DISPATCH level therefore using Spinlog instead of mutex here

296: KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock), &LockQueueHandle);
297:
298: pTmpRulesList = pDeviceExt->pSessRulesHead;
299: while(pTmpRulesList != NULL)
300: {
301: if(pTmpRulesList->WTSSessionID == lSessionID)

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: XcdmTDIFlt!tdi_Dispatch+f0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: XcdmTDIFlt

IMAGE_NAME: XcdmTDIFlt.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d5b012f

FAILURE_BUCKET_ID: 0x8E_XcdmTDIFlt!tdi_Dispatch+f0

BUCKET_ID: 0x8E_XcdmTDIFlt!tdi_Dispatch+f0

Followup: MachineOwner

Thanks in advance for the help…
Nilesh

Perhaps the error is in IoGetRequestorSessionId instead of
KeAcquireInStackQueuedSpinLock?

Thomas F. Divine


From:
Sent: Wednesday, February 16, 2011 5:36 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] 8e bugcheck

> Hi,
>
> I am developing a TDI driver to filter TCP communication. The filtering
> part works fine but the driver is causing 8e crash because of unhandled
> exception. I some help to analyse the root cause of the exception.
>
> I suspect that the the crash seems is happening because of unavailability
> of parameter to KeAcquireInStackQueuedSpinLock(). I have stored the
> RuleSpinlock in device extension and I am not able to understand why it
> will not be available to the device at any point in time.
>
> Here is the code which crashes
> NTSTATUS tdi_Dispatch( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp )
> {
> // variable init
>
> pirp_stack = IoGetCurrentIrpStackLocation(Irp);
>
> if (DeviceObject->DeviceType == FILE_DEVICE_NETWORK)
> {
> pDeviceExt = ((PDEVICE_EXTENSION) DeviceObject->DeviceExtension);
>
> if( (pirp_stack->MajorFunction == IRP_MJ_INTERNAL_DEVICE_CONTROL)&&
> (pirp_stack->MinorFunction == TDI_CONNECT) )
> {
> PTDI_REQUEST_KERNEL_SENDDG pParams =
> (PTDI_REQUEST_KERNEL_SENDDG)(&pirp_stack->Parameters);
> TA_ADDRESS *pRemoteAddress = ((TRANSPORT_ADDRESS
> *)(pParams->SendDatagramInformation->RemoteAddress))->Address;
> TDI_ADDRESS_IP pAddrr = (TDI_ADDRESS_IP)pRemoteAddress->Address;
>
> Port = (pAddrr->sin_port >> 8) | (pAddrr->sin_port << 8);
>
> IoGetRequestorSessionId(Irp, &lSessionID);
>
> //Some time this runs at DISPATCH level therefore using Spinlog instead of
> mutex here
> KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock),
> &LockQueueHandle);
>
> // do the filtering
>
> KeReleaseInStackQueuedSpinLock (&LockQueueHandle);
>
> }
> }
>
>
> //
> // Pass the IRP to the target without touching the IRP
> //
> IoSkipCurrentIrpStackLocation(Irp);
>
> return IoCallDriver(pDeviceExt->TopOfStack, Irp);
> }
>
>
> Here is !analyze -v
>
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>

>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
> This is a very common bugcheck. Usually the exception address pinpoints
> the driver/function that caused the problem. Always note this address
> as well as the link date of the driver/image that contains this address.
> Some common problems are exception code 0x80000003. This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG. This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but …
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG. This will let us see why this breakpoint is
> happening.
> Arguments:
> Arg1: c0000005, The exception code that was not handled
> Arg2: 8085647e, The address that the exception occurred at
> Arg3: f69f4900, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
> referenced memory at 0x%08lx. The memory could not be %s.
>
> FAULTING_IP:
> nt!MmGetSessionId+8
> 8085647e f680f801000004 test byte ptr [eax+1F8h],4
>
> TRAP_FRAME: f69f4900 – (.trap 0xfffffffff69f4900)
> ErrCode = 00000000
> eax=00000000 ebx=00000000 ecx=823fb240 edx=00bd0100 esi=82381a28
> edi=81f90978
> eip=8085647e esp=f69f4974 ebp=f69f4974 iopl=0 nv up ei ng nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010282
> nt!MmGetSessionId+0x8:
> 8085647e f680f801000004 test byte ptr [eax+1F8h],4
> ds:0023:000001f8=00
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
>
> BUGCHECK_STR: 0x8E
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from 8081c948 to 8085647e
>
> STACK_TEXT:
> f69f4974 8081c948 00000000 f69f49f4 f7860550 nt!MmGetSessionId+0x8
> f69f4980 f7860550 823fb240 f69f49f0 81f90978
> nt!IoGetRequestorSessionId+0x1a
> f69f49f4 8081d5a3 82354020 823fb240 823fb240 XcdmTDIFlt!tdi_Dispatch+0xf0
> [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
> f69f4a08 f6d1f35b 81ff0fcc 823ef008 81ff0ed8 nt!IofCallDriver+0x45
> f69f4a20 f6d1e224 81feb008 f6cca350 81ff0fcc netbt!TdiConnect+0xd8
> f69f4a58 f6d1fe6b 00ff0ed8 0a010a6e 82240290 netbt!TcpSessionStart+0x9c
> f69f4a98 f6d1ff28 82240290 00000000 00000000
> netbt!SessionSetupContinue+0x27f
> f69f4ac0 f6d3a3b4 f6d1fc49 81ff0ed8 00000000 netbt!CompleteClientReq+0x92
> f69f4b64 f6d2042e 82439b80 f7a8d29c 00000001
> netbt!NbtCompleteLmhSvcRequest+0x29b
> f69f4ba4 f6d39282 820c3d08 f7a8d090 00000278
> netbt!NtProcessLmHSvcIrp+0x130
> f69f4bfc f6d391e2 820c3d08 f7a8d090 00000278 netbt!DispatchIoctls+0x586
> f69f4c3c 8081d5a3 820c3d08 81ed6cc8 81f2bd20 netbt!NbtDispatchDevCtrl+0xce
> f69f4c50 808ed3e1 81ed6d38 81fa6f58 81ed6cc8 nt!IofCallDriver+0x45
> f69f4c64 808ee169 820c3d08 81ed6cc8 81fa6f58
> nt!IopSynchronousServiceTail+0x10b
> f69f4d00 808e6cca 00000158 00000124 00000000 nt!IopXxxControlFile+0x5e5
> f69f4d34 80883908 00000158 00000124 00000000 nt!NtDeviceIoControlFile+0x2a
> f69f4d34 7c8285ec 00000158 00000124 00000000 nt!KiFastCallEntry+0xf8
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0095fb54 00000000 00000000 00000000 00000000 0x7c8285ec
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> XcdmTDIFlt!tdi_Dispatch+f0
> [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
> f7860550 8b4dc8 mov ecx,dword ptr [ebp-38h]
>
> FAULTING_SOURCE_CODE:
> 292: //check it while installation of SFA
> 293: IoGetRequestorSessionId(Irp, &lSessionID);
> 294:
> 295: //Some time this runs at DISPATCH level therefore using Spinlog
> instead of mutex here
>> 296: KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock),
>> &LockQueueHandle);
> 297:
> 298: pTmpRulesList = pDeviceExt->pSessRulesHead;
> 299: while(pTmpRulesList != NULL)
> 300: {
> 301: if(pTmpRulesList->WTSSessionID == lSessionID)
>
>
> SYMBOL_STACK_INDEX: 2
>
> SYMBOL_NAME: XcdmTDIFlt!tdi_Dispatch+f0
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: XcdmTDIFlt
>
> IMAGE_NAME: XcdmTDIFlt.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4d5b012f
>
> FAILURE_BUCKET_ID: 0x8E_XcdmTDIFlt!tdi_Dispatch+f0
>
> BUCKET_ID: 0x8E_XcdmTDIFlt!tdi_Dispatch+f0
>
> Followup: MachineOwner
> ---------
>
> Thanks in advance for the help…
> Nilesh
>
> —
> 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

Especially as IoGetRequestorSessionId demands IRQL: <= APC_LEVEL and
the OP has modified his code to use spinlocks because he is being
invoked at DPC_LEVEL.

Mark Roddy

On Wed, Feb 16, 2011 at 5:39 PM, Thomas F. Divine wrote:
> Perhaps the error is in IoGetRequestorSessionId instead of
> KeAcquireInStackQueuedSpinLock?
>
> Thomas F. Divine
>
> --------------------------------------------------
> From:
> Sent: Wednesday, February 16, 2011 5:36 PM
> To: “Windows System Software Devs Interest List”
> Subject: [ntdev] 8e bugcheck
>
>> Hi,
>>
>> I am developing a TDI driver to filter TCP communication. The filtering
>> part works fine but the driver is causing 8e crash because of unhandled
>> exception. I some help to analyse the root cause of the exception.
>>
>> I suspect that the the crash seems is happening because of unavailability
>> of parameter to KeAcquireInStackQueuedSpinLock(). I have stored the
>> RuleSpinlock in device extension and I am not able to understand why it will
>> not be available to the device at any point in time.
>>
>> Here is the code which crashes
>> NTSTATUS tdi_Dispatch( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp )
>> {
>> // variable init
>>
>> pirp_stack = IoGetCurrentIrpStackLocation(Irp);
>>
>> if (DeviceObject->DeviceType == FILE_DEVICE_NETWORK)
>> {
>> pDeviceExt = ((PDEVICE_EXTENSION) DeviceObject->DeviceExtension);
>>
>> if( (pirp_stack->MajorFunction == IRP_MJ_INTERNAL_DEVICE_CONTROL)&&
>> (pirp_stack->MinorFunction == TDI_CONNECT) )
>> {
>> PTDI_REQUEST_KERNEL_SENDDG pParams =
>> (PTDI_REQUEST_KERNEL_SENDDG)(&pirp_stack->Parameters);
>> TA_ADDRESS *pRemoteAddress = ((TRANSPORT_ADDRESS
>> *)(pParams->SendDatagramInformation->RemoteAddress))->Address;
>> TDI_ADDRESS_IP pAddrr = (TDI_ADDRESS_IP)pRemoteAddress->Address;
>>
>> Port = (pAddrr->sin_port >> 8) | (pAddrr->sin_port << 8);
>>
>> IoGetRequestorSessionId(Irp, &lSessionID);
>>
>> //Some time this runs at DISPATCH level therefore using Spinlog instead of
>> mutex here
>> KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock),
>> &LockQueueHandle);
>>
>> // do the filtering
>>
>> KeReleaseInStackQueuedSpinLock ?(&LockQueueHandle);
>>
>> }
>> }
>>
>>
>> //
>> // Pass the IRP to the target without touching the IRP
>> //
>> IoSkipCurrentIrpStackLocation(Irp);
>>
>> return IoCallDriver(pDeviceExt->TopOfStack, Irp);
>> }
>>
>>
>> Here is !analyze -v
>>
>> kd> !analyze -v
>>
>> ***
>> *
>> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis
>> *
>>
>>

>>
>> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
>> This is a very common bugcheck. ?Usually the exception address pinpoints
>> the driver/function that caused the problem. ?Always note this address
>> as well as the link date of the driver/image that contains this address.
>> Some common problems are exception code 0x80000003. ?This means a hard
>> coded breakpoint or assertion was hit, but this system was booted
>> /NODEBUG. ?This is not supposed to happen as developers should never have
>> hardcoded breakpoints in retail code, but …
>> If this happens, make sure a debugger gets connected, and the
>> system is booted /DEBUG. ?This will let us see why this breakpoint is
>> happening.
>> Arguments:
>> Arg1: c0000005, The exception code that was not handled
>> Arg2: 8085647e, The address that the exception occurred at
>> Arg3: f69f4900, Trap Frame
>> Arg4: 00000000
>>
>> Debugging Details:
>> ------------------
>>
>>
>> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
>> referenced memory at 0x%08lx. The memory could not be %s.
>>
>> FAULTING_IP:
>> nt!MmGetSessionId+8
>> 8085647e f680f801000004 ?test ? ?byte ptr [eax+1F8h],4
>>
>> TRAP_FRAME: ?f69f4900 – (.trap 0xfffffffff69f4900)
>> ErrCode = 00000000
>> eax=00000000 ebx=00000000 ecx=823fb240 edx=00bd0100 esi=82381a28
>> edi=81f90978
>> eip=8085647e esp=f69f4974 ebp=f69f4974 iopl=0 ? ? ? ? nv up ei ng nz na po
>> nc
>> cs=0008 ?ss=0010 ?ds=0023 ?es=0023 ?fs=0030 ?gs=0000 efl=00010282
>> nt!MmGetSessionId+0x8:
>> 8085647e f680f801000004 ?test ? ?byte ptr [eax+1F8h],4 ds:0023:000001f8=00
>> Resetting default scope
>>
>> CUSTOMER_CRASH_COUNT: ?1
>>
>> DEFAULT_BUCKET_ID: ?DRIVER_FAULT_SERVER_MINIDUMP
>>
>> BUGCHECK_STR: ?0x8E
>>
>> CURRENT_IRQL: ?0
>>
>> LAST_CONTROL_TRANSFER: ?from 8081c948 to 8085647e
>>
>> STACK_TEXT:
>> f69f4974 8081c948 00000000 f69f49f4 f7860550 nt!MmGetSessionId+0x8
>> f69f4980 f7860550 823fb240 f69f49f0 81f90978
>> nt!IoGetRequestorSessionId+0x1a
>> f69f49f4 8081d5a3 82354020 823fb240 823fb240 XcdmTDIFlt!tdi_Dispatch+0xf0
>> [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
>> f69f4a08 f6d1f35b 81ff0fcc 823ef008 81ff0ed8 nt!IofCallDriver+0x45
>> f69f4a20 f6d1e224 81feb008 f6cca350 81ff0fcc netbt!TdiConnect+0xd8
>> f69f4a58 f6d1fe6b 00ff0ed8 0a010a6e 82240290 netbt!TcpSessionStart+0x9c
>> f69f4a98 f6d1ff28 82240290 00000000 00000000
>> netbt!SessionSetupContinue+0x27f
>> f69f4ac0 f6d3a3b4 f6d1fc49 81ff0ed8 00000000 netbt!CompleteClientReq+0x92
>> f69f4b64 f6d2042e 82439b80 f7a8d29c 00000001
>> netbt!NbtCompleteLmhSvcRequest+0x29b
>> f69f4ba4 f6d39282 820c3d08 f7a8d090 00000278
>> netbt!NtProcessLmHSvcIrp+0x130
>> f69f4bfc f6d391e2 820c3d08 f7a8d090 00000278 netbt!DispatchIoctls+0x586
>> f69f4c3c 8081d5a3 820c3d08 81ed6cc8 81f2bd20 netbt!NbtDispatchDevCtrl+0xce
>> f69f4c50 808ed3e1 81ed6d38 81fa6f58 81ed6cc8 nt!IofCallDriver+0x45
>> f69f4c64 808ee169 820c3d08 81ed6cc8 81fa6f58
>> nt!IopSynchronousServiceTail+0x10b
>> f69f4d00 808e6cca 00000158 00000124 00000000 nt!IopXxxControlFile+0x5e5
>> f69f4d34 80883908 00000158 00000124 00000000 nt!NtDeviceIoControlFile+0x2a
>> f69f4d34 7c8285ec 00000158 00000124 00000000 nt!KiFastCallEntry+0xf8
>> WARNING: Frame IP not in any known module. Following frames may be wrong.
>> 0095fb54 00000000 00000000 00000000 00000000 0x7c8285ec
>>
>>
>> STACK_COMMAND: ?kb
>>
>> FOLLOWUP_IP:
>> XcdmTDIFlt!tdi_Dispatch+f0
>> [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
>> f7860550 8b4dc8 ? ? ? ? ?mov ? ? ecx,dword ptr [ebp-38h]
>>
>> FAULTING_SOURCE_CODE:
>> ?292: //check it while installation of SFA
>> ?293: IoGetRequestorSessionId(Irp, &lSessionID);
>> ?294:
>> ?295: //Some time this runs at DISPATCH level therefore using Spinlog
>> instead of mutex here
>>>
>>> ?296: KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock),
>>> &LockQueueHandle);
>>
>> ?297:
>> ?298: pTmpRulesList = pDeviceExt->pSessRulesHead;
>> ?299: while(pTmpRulesList != NULL)
>> ?300: {
>> ?301: if(pTmpRulesList->WTSSessionID == lSessionID)
>>
>>
>> SYMBOL_STACK_INDEX: ?2
>>
>> SYMBOL_NAME: ?XcdmTDIFlt!tdi_Dispatch+f0
>>
>> FOLLOWUP_NAME: ?MachineOwner
>>
>> MODULE_NAME: XcdmTDIFlt
>>
>> IMAGE_NAME: ?XcdmTDIFlt.sys
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: ?4d5b012f
>>
>> FAILURE_BUCKET_ID: ?0x8E_XcdmTDIFlt!tdi_Dispatch+f0
>>
>> BUCKET_ID: ?0x8E_XcdmTDIFlt!tdi_Dispatch+f0
>>
>> Followup: MachineOwner
>> ---------
>>
>> Thanks in advance for the help…
>> Nilesh
>>
>> —
>> 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
>
>
> —
> 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
>

Thats very likely scenario…

Is there a way I can confirm current IRQL in crash dump?
kd> !pcr
Cannot get PRCB address
kd> !irql
Debugger saved IRQL for processor 0x0 – 0 (LOW_LEVEL)

!irql says its 0, but I am not sure if thats reliable or not. And if that is, then the crash did not happen because of high IRQL.

Nilesh

The IRQL is correct. I think the IRQL issue is a problem, but not your
current problem. Note that EAX is zero and that the crashing
instruction sequence is:

FAULTING_IP:
nt!MmGetSessionId+8
8085647e f680f801000004 test byte ptr [eax+1F8h],4

and that the first parameter ot MmGetSessionId is zero:
69f4974 8081c948 00000000 f69f49f4 f7860550 nt!MmGetSessionId+0x8

So I think you have managed to provide dubious garbage to
IoGetRequestorSessionId, which in turn has gone off and called
MmGetSessionId with junk.

That is the easy part. Why is a bit more difficult. :slight_smile:

Mark Roddy

On Wed, Feb 16, 2011 at 5:36 PM, wrote:
> Hi,
>
> I am developing a TDI driver to filter TCP communication. The filtering part works fine but the driver is causing 8e crash because of unhandled exception. I some help to analyse the root cause of the exception.
>
> I suspect that the the crash seems is happening because of unavailability of parameter to KeAcquireInStackQueuedSpinLock(). I have stored the RuleSpinlock in device extension and I am not able to understand why it will not be available to the device at any point in time.
>
> Here is the code which crashes
> NTSTATUS tdi_Dispatch( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp )
> {
> ? ? ? ?// variable init
>
> ? ? ? ?pirp_stack = IoGetCurrentIrpStackLocation(Irp);
>
> ? ? ? ?if (DeviceObject->DeviceType == FILE_DEVICE_NETWORK)
> ? ? ? ?{
> ? ? ? ? ? ? ? ?pDeviceExt = ((PDEVICE_EXTENSION) DeviceObject->DeviceExtension);
>
> ? ? ? ? ? ? ? ?if( ? ? (pirp_stack->MajorFunction == IRP_MJ_INTERNAL_DEVICE_CONTROL)&&
> ? ? ? ? ? ? ? ? ? ? ? ?(pirp_stack->MinorFunction == TDI_CONNECT) ? ? ?)
> ? ? ? ? ? ? ? ?{
> ? ? ? ? ? ? ? ? ? ? ? ?PTDI_REQUEST_KERNEL_SENDDG pParams = (PTDI_REQUEST_KERNEL_SENDDG)(&pirp_stack->Parameters);
> ? ? ? ? ? ? ? ? ? ? ? ?TA_ADDRESS *pRemoteAddress = ((TRANSPORT_ADDRESS *)(pParams->SendDatagramInformation->RemoteAddress))->Address;
> ? ? ? ? ? ? ? ? ? ? ? ?TDI_ADDRESS_IP pAddrr = (TDI_ADDRESS_IP)pRemoteAddress->Address;
>
> ? ? ? ? ? ? ? ? ? ? ? ?Port = (pAddrr->sin_port >> 8) | (pAddrr->sin_port << 8);
>
> ? ? ? ? ? ? ? ? ? ? ? ?IoGetRequestorSessionId(Irp, &lSessionID);
>
> ? ? ? ? ? ? ? ? ? ? ? ?//Some time this runs at DISPATCH level therefore using Spinlog instead of mutex here
> ? ? ? ? ? ? ? ? ? ? ? ?KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock), &LockQueueHandle);
>
> ? ? ? ? ? ? ? ? ? ? ? ?// do the filtering
>
> ? ? ? ? ? ? ? ? ? ? ? ?KeReleaseInStackQueuedSpinLock ?(&LockQueueHandle);
>
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
>
> ? ? ? ?//
> ? ? ? ?// Pass the IRP to the target without touching the IRP
> ? ? ? ?//
> ? ? ? ?IoSkipCurrentIrpStackLocation(Irp);
>
> ? ? ? ?return IoCallDriver(pDeviceExt->TopOfStack, Irp);
> }
>
>
> Here is !analyze -v
>
> kd> !analyze -v
> *
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>

>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
> This is a very common bugcheck. ?Usually the exception address pinpoints
> the driver/function that caused the problem. ?Always note this address
> as well as the link date of the driver/image that contains this address.
> Some common problems are exception code 0x80000003. ?This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG. ?This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but …
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG. ?This will let us see why this breakpoint is
> happening.
> Arguments:
> Arg1: c0000005, The exception code that was not handled
> Arg2: 8085647e, The address that the exception occurred at
> Arg3: f69f4900, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
>
> FAULTING_IP:
> nt!MmGetSessionId+8
> 8085647e f680f801000004 ?test ? ?byte ptr [eax+1F8h],4
>
> TRAP_FRAME: ?f69f4900 – (.trap 0xfffffffff69f4900)
> ErrCode = 00000000
> eax=00000000 ebx=00000000 ecx=823fb240 edx=00bd0100 esi=82381a28 edi=81f90978
> eip=8085647e esp=f69f4974 ebp=f69f4974 iopl=0 ? ? ? ? nv up ei ng nz na po nc
> cs=0008 ?ss=0010 ?ds=0023 ?es=0023 ?fs=0030 ?gs=0000 ? ? ? ? ? ? efl=00010282
> nt!MmGetSessionId+0x8:
> 8085647e f680f801000004 ?test ? ?byte ptr [eax+1F8h],4 ? ? ?ds:0023:000001f8=00
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: ?1
>
> DEFAULT_BUCKET_ID: ?DRIVER_FAULT_SERVER_MINIDUMP
>
> BUGCHECK_STR: ?0x8E
>
> CURRENT_IRQL: ?0
>
> LAST_CONTROL_TRANSFER: ?from 8081c948 to 8085647e
>
> STACK_TEXT:
> f69f4974 8081c948 00000000 f69f49f4 f7860550 nt!MmGetSessionId+0x8
> f69f4980 f7860550 823fb240 f69f49f0 81f90978 nt!IoGetRequestorSessionId+0x1a
> f69f49f4 8081d5a3 82354020 823fb240 823fb240 XcdmTDIFlt!tdi_Dispatch+0xf0 [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
> f69f4a08 f6d1f35b 81ff0fcc 823ef008 81ff0ed8 nt!IofCallDriver+0x45
> f69f4a20 f6d1e224 81feb008 f6cca350 81ff0fcc netbt!TdiConnect+0xd8
> f69f4a58 f6d1fe6b 00ff0ed8 0a010a6e 82240290 netbt!TcpSessionStart+0x9c
> f69f4a98 f6d1ff28 82240290 00000000 00000000 netbt!SessionSetupContinue+0x27f
> f69f4ac0 f6d3a3b4 f6d1fc49 81ff0ed8 00000000 netbt!CompleteClientReq+0x92
> f69f4b64 f6d2042e 82439b80 f7a8d29c 00000001 netbt!NbtCompleteLmhSvcRequest+0x29b
> f69f4ba4 f6d39282 820c3d08 f7a8d090 00000278 netbt!NtProcessLmHSvcIrp+0x130
> f69f4bfc f6d391e2 820c3d08 f7a8d090 00000278 netbt!DispatchIoctls+0x586
> f69f4c3c 8081d5a3 820c3d08 81ed6cc8 81f2bd20 netbt!NbtDispatchDevCtrl+0xce
> f69f4c50 808ed3e1 81ed6d38 81fa6f58 81ed6cc8 nt!IofCallDriver+0x45
> f69f4c64 808ee169 820c3d08 81ed6cc8 81fa6f58 nt!IopSynchronousServiceTail+0x10b
> f69f4d00 808e6cca 00000158 00000124 00000000 nt!IopXxxControlFile+0x5e5
> f69f4d34 80883908 00000158 00000124 00000000 nt!NtDeviceIoControlFile+0x2a
> f69f4d34 7c8285ec 00000158 00000124 00000000 nt!KiFastCallEntry+0xf8
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0095fb54 00000000 00000000 00000000 00000000 0x7c8285ec
>
>
> STACK_COMMAND: ?kb
>
> FOLLOWUP_IP:
> XcdmTDIFlt!tdi_Dispatch+f0 [c:\development\cvsrepository\tdifilter\tdidriver.c @ 296]
> f7860550 8b4dc8 ? ? ? ? ?mov ? ? ecx,dword ptr [ebp-38h]
>
> FAULTING_SOURCE_CODE:
> ? 292: ? ? ? ? ? ? ? ? ? ? ? ? //check it while installation of SFA
> ? 293: ? ? ? ? ? ? ? ? ? ? ? ? IoGetRequestorSessionId(Irp, &lSessionID);
> ? 294:
> ? 295: ? ? ? ? ? ? ? ? ? ? ? ? //Some time this runs at DISPATCH level therefore using Spinlog instead of mutex here
>> ?296: ? ? ? ? ? ? ? ? ? ? ? ? KeAcquireInStackQueuedSpinLock(&(pDeviceExt->RuleSpinlock), &LockQueueHandle);
> ? 297:
> ? 298: ? ? ? ? ? ? ? ? ? ? ? ? pTmpRulesList = pDeviceExt->pSessRulesHead;
> ? 299: ? ? ? ? ? ? ? ? ? ? ? ? while(pTmpRulesList != NULL)
> ? 300: ? ? ? ? ? ? ? ? ? ? ? ? {
> ? 301: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if(pTmpRulesList->WTSSessionID == lSessionID)
>
>
> SYMBOL_STACK_INDEX: ?2
>
> SYMBOL_NAME: ?XcdmTDIFlt!tdi_Dispatch+f0
>
> FOLLOWUP_NAME: ?MachineOwner
>
> MODULE_NAME: XcdmTDIFlt
>
> IMAGE_NAME: ?XcdmTDIFlt.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: ?4d5b012f
>
> FAILURE_BUCKET_ID: ?0x8E_XcdmTDIFlt!tdi_Dispatch+f0
>
> BUCKET_ID: ?0x8E_XcdmTDIFlt!tdi_Dispatch+f0
>
> Followup: MachineOwner
> ---------
>
> Thanks in advance for the help…
> Nilesh
>
> —
> 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
>

Mark,

The parameters to IoGetRequestorSessionId() are PIRP and PULONG.

I am passing IRP from the input to my dispatch function and ULONG is just a local variable!

What can I miss there?

Nilesh

I’m going to guess that sometimes the TDI Irps are not threaded, and
that calling IoGetRequestor* on a non-threaded IRP is likely to cause
bugchecks, rather than simply returning an error. However as I am no
longer privileged enough to go research this answer, it is simply a
guess.

Perhaps using these functions in a TDI filter is dubious?

Mark Roddy

On Thu, Feb 17, 2011 at 11:17 AM, wrote:
> Mark,
>
> The parameters to IoGetRequestorSessionId() are PIRP and PULONG.
>
> I am passing IRP from the input to my dispatch function and ULONG is just a local variable!
>
> What can I miss there?
>
> Nilesh
>
> —
> 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
>

IoGetRequestor* do attempt to see if the PIRP is threaded or not by checking Irp->Tail.Overlay.Thread for != NULL. If NULL, these APIs return either null or zero. If it is != NULL but invalid, you will blow up. What is the value of Irp->Tail.Overlay.Thread when your call fails? If you run !thread does it show a valid thread?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, February 17, 2011 8:43 AM
To: Windows System Software Devs Interest List
Cc: xxxxx@yahoo.com
Subject: Re: [ntdev] 8e bugcheck

I’m going to guess that sometimes the TDI Irps are not threaded, and that calling IoGetRequestor* on a non-threaded IRP is likely to cause bugchecks, rather than simply returning an error. However as I am no longer privileged enough to go research this answer, it is simply a guess.

Perhaps using these functions in a TDI filter is dubious?

Mark Roddy

On Thu, Feb 17, 2011 at 11:17 AM, wrote:
> Mark,
>
> The parameters to IoGetRequestorSessionId() are PIRP and PULONG.
>
> I am passing IRP from the input to my dispatch function and ULONG is just a local variable!
>
> What can I miss there?
>
> Nilesh
>
> —
> 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
>


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

For TDI process information is only available when a TDI IRP_MJ_CREATE call
is being handled. Not available during any other calls.

Thomas F. Divine
http://www.pcausa.com


From: “Mark Roddy”
Sent: Thursday, February 17, 2011 11:43 AM
To: “Windows System Software Devs Interest List”
Cc:
Subject: Re: [ntdev] 8e bugcheck

> I’m going to guess that sometimes the TDI Irps are not threaded, and
> that calling IoGetRequestor* on a non-threaded IRP is likely to cause
> bugchecks, rather than simply returning an error. However as I am no
> longer privileged enough to go research this answer, it is simply a
> guess.
>
> Perhaps using these functions in a TDI filter is dubious?
>
> Mark Roddy
>
>
>
> On Thu, Feb 17, 2011 at 11:17 AM, wrote:
>> Mark,
>>
>> The parameters to IoGetRequestorSessionId() are PIRP and PULONG.
>>
>> I am passing IRP from the input to my dispatch function and ULONG is just
>> a local variable!
>>
>> What can I miss there?
>>
>> Nilesh
>>
>> —
>> 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
>>
>
> —
> 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

Doron,

The Irp->Tail.Overlay.Thread is 0x81c6d438. But !thread 0x81c6d438 is not able to give any information.

kd> !thread 0x81c6d438
GetPointerFromAddress: unable to read from 808958e8
81c6d438: Unable to get thread contents

Also I noticed that all bugchecks have happened when the connect request is to port 445. Thats SMB port and if I understand correct SMB operations do not happen in any process context (??).

Could that be the cause of the bugcheck?

Nilesh

Thomas,

The code in question is only running in case of TDI_CONNECT request and I am able to get correct information in all cases except when the port is TDI_CONNECT is for port 445.

Nilesh

TDI operations other than IRP_MJ_CREATE are done in arbitrary thread
context.

The fact that you an fetch process information in TDI_CONNECT is pure luck,
IMHO.

FWIW from one who has been tinkering with TDI from NT 4 days.

Thomas F. Divine
http://www.pcausa.com


From:
Sent: Thursday, February 17, 2011 4:37 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] 8e bugcheck

> Thomas,
>
> The code in question is only running in case of TDI_CONNECT request and I
> am able to get correct information in all cases except when the port is
> TDI_CONNECT is for port 445.
>
> Nilesh
>
> —
> 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