Windows 7 / WDK 7.0 - Weird crash while calling WdfTimerStart()

Dear Gents,

I am having an interesting troubles under Windows 7 (32) with a driver compiler using the WDK 7.0.

Everything working smoothly until I enable the verifier. If I enable verifier to check only my driver everything is all right. If I configure verifier to check all the drivers installed in the system then the BSOD occurs in my driver.

This BSOD happening (0xC4 P1=8 P2=2 P4=0) while calling WdfTimerStart() in the following function. This function is itself called by HwEvtProgramWriteDma().

VOID
HwTimeoutTimerStart(
IN PDEVICE_EXTENSION DevExt
)
{

WdfTimerStart(DevExt->TimeoutTimer, DevExt->Timeout); <<<<<<=== BSOD occurs here

//
// Reset the timeout to the normal timeout.
//
DevExt->Timeout = WDF_REL_TIMEOUT_IN_SEC(2);
}

If I comment out the call to WdfTimerStart() then the BSOD is NOT happening while using verifier or not using verifier.

Note that the timer object is created in a non paged code function called by the AddDevice event. And that the driver is not signed.

This is happening as soon I proceed with DMA operations which makes sense as each DMA operation
has a timeout and the timer is started on the fly.

Anyone has a clue about what I do wrong or maybe do not understand?

Thank you!

Arnaud

Crash dump for this issue :

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000030, raising IRQL to an invalid level,
Arg2: 00000008, current IRQL,
Arg3: 00000002, new IRQL
Arg4: 00000000

Debugging Details:

Page 5fb48 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type ".hh dbgerr001" for details

BUGCHECK_STR: 0xc4_30

CURRENT_IRQL: 8

REQUESTED_IRQL: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: TEST

LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10

STACK_TEXT:
a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
a667f8e4 8298ad99 00000008 8298b31b 928c0fa8 nt!VerifierBugCheckIfAppropriate+0x30
a667f904 8298b36b 00000002 8298b31b 928c0fa8 nt!ViKeRaiseIrqlSanityChecks+0x3b
a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014 nt!VerifierKfAcquireSpinLock+0x50
a667f944 84d31030 a667f96e 00000000 a667f974 Wdf01000!FxVerifierLock::Lock+0xcd
a667f954 84d5357d a667f96e 8268efd0 8cca21e0 Wdf01000!FxNonPagedObject::Lock+0x23
a667f974 84d4479a feced300 ffffffff a667f9a0 Wdf01000!FxTimer::Start+0x1d
a667f984 8ef882de 00000000 92946f40 feced300 Wdf01000!imp_WdfTimerStart+0x62
a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68 4fm!HwTimeoutTimerStart+0x1e [d:\svn\drivers\windows\trunk\timer.c @ 51]
a667f9c4 84d2e906 00000001 00001000 00000000 4fm!HwEvtProgramWriteDma+0x17e [d:\svn\drivers\windows\trunk\write.c @ 300]
a667f9ec 8261ea2e 8cc45df0 00000000 8a000000 Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
a667fa18 829840e0 8a000000 8cc45df0 87b75000 hal!HalBuildScatterGatherList+0x1ba
a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000 nt!VfBuildScatterGatherList+0x166
a667fa9c 84d2ef6b 87b75000 02fa0020 00800000 Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
a667fad8 84d2e38c 00000000 8cca21e0 a667faf4 Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
a667fae8 84d2c85f 00000000 a667fb14 8ef888fc Wdf01000!FxDmaTransactionBase::Execute+0x67
a667faf4 8ef888fc 00000000 ac58ef68 00000000 Wdf01000!imp_WdfDmaTransactionExecute+0x5f
a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128 [d:\svn\drivers\windows\trunk\write.c @ 102]
a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000 Wdf01000!FxIoQueueIoRead::Invoke+0x2a
a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
a667fb74 84d5ca36 92838e00 00000000 9297cf40 Wdf01000!FxIoQueue::DispatchEvents+0x3be
a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00 Wdf01000!FxIoQueue::QueueRequest+0x1ec
a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3 Wdf01000!FxPkgIo::Dispatch+0x27d
a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4 Wdf01000!FxDevice::Dispatch+0x7f
a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
a667fbfc 829923d0 857c01d0 89b7cf00 8cc53738 nt!IofCallDriver+0x1b
a667fc14 829806c3 8cc537f0 89b7cf00 87b88d48 nt!ViFilterDispatchGeneric+0x5e
a667fc38 8268d473 00000000 89b7cf00 8cc53738 nt!IovCallDriver+0x258
a667fc4c 8288eeee 87b88d48 89b7cf00 89b7cfdc nt!IofCallDriver+0x1b
a667fc6c 8288f7a2 8cc53738 87b88d48 00000001 nt!IopSynchronousServiceTail+0x1f8
a667fd08 8269442a 8cc53738 00000000 00000000 nt!NtWriteFile+0x6e8
a667fd08 775564f4 8cc53738 00000000 00000000 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
02f9f958 00000000 00000000 00000000 00000000 0x775564f4

STACK_COMMAND: kb

FOLLOWUP_IP:
4fm!HwTimeoutTimerStart+1e [d:\svn\drivers\windows\trunk\timer.c @ 51]
8ef882de 834e3cff or dword ptr [esi+3Ch],0FFFFFFFFh

FAULTING_SOURCE_CODE:
No source found for 'd:\svn\drivers\windows\trunk\timer.c'

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: 4fm!HwTimeoutTimerStart+1e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: 4fm

IMAGE_NAME: 4fm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4addc9aa

FAILURE_BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

Send the output of !analyze -v

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@4dsp.com
Sent: Wednesday, October 21, 2009 12:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling WdfTimerStart()

Dear Gents,

I am having an interesting troubles under Windows 7 (32) with a driver compiler using the WDK 7.0.

Everything working smoothly until I enable the verifier. If I enable verifier to check only my driver everything is all right. If I configure verifier to check all the drivers installed in the system then the BSOD occurs in my driver.

This BSOD happening (0xC4 P1=8 P2=2 P4=0) while calling WdfTimerStart() in the following function. This function is itself called by HwEvtProgramWriteDma().

VOID
HwTimeoutTimerStart(
IN PDEVICE_EXTENSION DevExt
)
{

WdfTimerStart(DevExt->TimeoutTimer, DevExt->Timeout); <<<<<<=== BSOD occurs here

//
// Reset the timeout to the normal timeout.
//
DevExt->Timeout = WDF_REL_TIMEOUT_IN_SEC(2);
}

If I comment out the call to WdfTimerStart() then the BSOD is NOT happening while using verifier or not using verifier.

Note that the timer object is created in a non paged code function called by the AddDevice event. And that the driver is not signed.

This is happening as soon I proceed with DMA operations which makes sense as each DMA operation
has a timeout and the timer is started on the fly.

Anyone has a clue about what I do wrong or maybe do not understand?

Thank you!

Arnaud

Crash dump for this issue :
---------------------------

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b


Bugcheck Analysis



DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000030, raising IRQL to an invalid level,
Arg2: 00000008, current IRQL,
Arg3: 00000002, new IRQL
Arg4: 00000000

Debugging Details:
------------------

Page 5fb48 not present in the dump file. Type “.hh dbgerr004” for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for details

BUGCHECK_STR: 0xc4_30

CURRENT_IRQL: 8

REQUESTED_IRQL: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: TEST

LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10

STACK_TEXT:
a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
a667f8e4 8298ad99 00000008 8298b31b 928c0fa8 nt!VerifierBugCheckIfAppropriate+0x30
a667f904 8298b36b 00000002 8298b31b 928c0fa8 nt!ViKeRaiseIrqlSanityChecks+0x3b
a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014 nt!VerifierKfAcquireSpinLock+0x50
a667f944 84d31030 a667f96e 00000000 a667f974 Wdf01000!FxVerifierLock::Lock+0xcd
a667f954 84d5357d a667f96e 8268efd0 8cca21e0 Wdf01000!FxNonPagedObject::Lock+0x23
a667f974 84d4479a feced300 ffffffff a667f9a0 Wdf01000!FxTimer::Start+0x1d
a667f984 8ef882de 00000000 92946f40 feced300 Wdf01000!imp_WdfTimerStart+0x62
a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68 4fm!HwTimeoutTimerStart+0x1e [d:\svn\drivers\windows\trunk\timer.c @ 51]
a667f9c4 84d2e906 00000001 00001000 00000000 4fm!HwEvtProgramWriteDma+0x17e [d:\svn\drivers\windows\trunk\write.c @ 300]
a667f9ec 8261ea2e 8cc45df0 00000000 8a000000 Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
a667fa18 829840e0 8a000000 8cc45df0 87b75000 hal!HalBuildScatterGatherList+0x1ba
a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000 nt!VfBuildScatterGatherList+0x166
a667fa9c 84d2ef6b 87b75000 02fa0020 00800000 Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
a667fad8 84d2e38c 00000000 8cca21e0 a667faf4 Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
a667fae8 84d2c85f 00000000 a667fb14 8ef888fc Wdf01000!FxDmaTransactionBase::Execute+0x67
a667faf4 8ef888fc 00000000 ac58ef68 00000000 Wdf01000!imp_WdfDmaTransactionExecute+0x5f
a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128 [d:\svn\drivers\windows\trunk\write.c @ 102]
a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000 Wdf01000!FxIoQueueIoRead::Invoke+0x2a
a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
a667fb74 84d5ca36 92838e00 00000000 9297cf40 Wdf01000!FxIoQueue::DispatchEvents+0x3be
a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00 Wdf01000!FxIoQueue::QueueRequest+0x1ec
a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3 Wdf01000!FxPkgIo::Dispatch+0x27d
a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4 Wdf01000!FxDevice::Dispatch+0x7f
a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
a667fbfc 8299

Hey Doran,

The output you are requesting is in the email, at the end.

“1: kd> !analyze -v”

Thank you

Arnaud

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 21, 2009 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Send the output of !analyze -v

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@4dsp.com
Sent: Wednesday, October 21, 2009 12:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Dear Gents,

I am having an interesting troubles under Windows 7 (32) with a driver
compiler using the WDK 7.0.

Everything working smoothly until I enable the verifier. If I enable
verifier to check only my driver everything is all right. If I configure
verifier to check all the drivers installed in the system then the BSOD
occurs in my driver.

This BSOD happening (0xC4 P1=8 P2=2 P4=0) while calling WdfTimerStart() in
the following function. This function is itself called by
HwEvtProgramWriteDma().

VOID
HwTimeoutTimerStart(
IN PDEVICE_EXTENSION DevExt
)
{

WdfTimerStart(DevExt->TimeoutTimer, DevExt->Timeout);
<<<<<<=== BSOD occurs here

//
// Reset the timeout to the normal timeout.
//
DevExt->Timeout = WDF_REL_TIMEOUT_IN_SEC(2);
}

If I comment out the call to WdfTimerStart() then the BSOD is NOT happening
while using verifier or not using verifier.

Note that the timer object is created in a non paged code function called by
the AddDevice event. And that the driver is not signed.

This is happening as soon I proceed with DMA operations which makes sense as
each DMA operation
has a timeout and the timer is started on the fly.

Anyone has a clue about what I do wrong or maybe do not understand?

Thank you!

Arnaud

Crash dump for this issue :
---------------------------

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************



Bugcheck Analysis



*************************************************************************


DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000030, raising IRQL to an invalid level,
Arg2: 00000008, current IRQL,
Arg3: 00000002, new IRQL
Arg4: 00000000

Debugging Details:
------------------

Page 5fb48 not present in the dump file. Type “.hh dbgerr004” for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for details

BUGCHECK_STR: 0xc4_30

CURRENT_IRQL: 8

REQUESTED_IRQL: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: TEST

LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10

STACK_TEXT:
a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
a667f8e4 8298ad99 00000008 8298b31b 928c0fa8
nt!VerifierBugCheckIfAppropriate+0x30
a667f904 8298b36b 00000002 8298b31b 928c0fa8
nt!ViKeRaiseIrqlSanityChecks+0x3b
a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014
nt!VerifierKfAcquireSpinLock+0x50
a667f944 84d31030 a667f96e 00000000 a667f974
Wdf01000!FxVerifierLock::Lock+0xcd
a667f954 84d5357d a667f96e 8268efd0 8cca21e0
Wdf01000!FxNonPagedObject::Lock+0x23
a667f974 84d4479a feced300 ffffffff a667f9a0 Wdf01000!FxTimer::Start+0x1d
a667f984 8ef882de 00000000 92946f40 feced300 Wdf01000!imp_WdfTimerStart+0x62
a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68 4fm!HwTimeoutTimerStart+0x1e
[d:\svn\drivers\windows\trunk\timer.c @ 51]
a667f9c4 84d2e906 00000001 00001000 00000000 4fm!HwEvtProgramWriteDma+0x17e
[d:\svn\drivers\windows\trunk\write.c @ 300]
a667f9ec 8261ea2e 8cc45df0 00000000 8a000000
Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
a667fa18 829840e0 8a000000 8cc45df0 87b75000
hal!HalBuildScatterGatherList+0x1ba
a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000
nt!VfBuildScatterGatherList+0x166
a667fa9c 84d2ef6b 87b75000 02fa0020 00800000
Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
a667fad8 84d2e38c 00000000 8cca21e0 a667faf4
Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
a667fae8 84d2c85f 00000000 a667fb14 8ef888fc
Wdf01000!FxDmaTransactionBase::Execute+0x67
a667faf4 8ef888fc 00000000 ac58ef68 00000000
Wdf01000!imp_WdfDmaTransactionExecute+0x5f
a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128
[d:\svn\drivers\windows\trunk\write.c @ 102]
a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000
Wdf01000!FxIoQueueIoRead::Invoke+0x2a
a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
a667fb74 84d5ca36 92838e00 00000000 9297cf40
Wdf01000!FxIoQueue::DispatchEvents+0x3be
a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00
Wdf01000!FxIoQueue::QueueRequest+0x1ec
a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3
Wdf01000!FxPkgIo::Dispatch+0x27d
a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4
Wdf01000!FxDevice::Dispatch+0x7f
a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
a667fbfc 8299

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

Hmmmm,

The dump is incomplete in my previous email, sorry for that

Thank you,

Arnaud

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000030, raising IRQL to an invalid level,
Arg2: 00000008, current IRQL,
Arg3: 00000002, new IRQL
Arg4: 00000000

Debugging Details:

Page 5fb48 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type ".hh dbgerr001" for details

BUGCHECK_STR: 0xc4_30

CURRENT_IRQL: 8

REQUESTED_IRQL: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: TEST

LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10

STACK_TEXT:
a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
a667f8e4 8298ad99 00000008 8298b31b 928c0fa8
nt!VerifierBugCheckIfAppropriate+0x30
a667f904 8298b36b 00000002 8298b31b 928c0fa8
nt!ViKeRaiseIrqlSanityChecks+0x3b
a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014
nt!VerifierKfAcquireSpinLock+0x50
a667f944 84d31030 a667f96e 00000000 a667f974
Wdf01000!FxVerifierLock::Lock+0xcd
a667f954 84d5357d a667f96e 8268efd0 8cca21e0
Wdf01000!FxNonPagedObject::Lock+0x23
a667f974 84d4479a feced300 ffffffff a667f9a0 Wdf01000!FxTimer::Start+0x1d
a667f984 8ef882de 00000000 92946f40 feced300 Wdf01000!imp_WdfTimerStart+0x62
a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68 4fm!HwTimeoutTimerStart+0x1e
[d:\svn\drivers\windows\trunk\timer.c @ 51]
a667f9c4 84d2e906 00000001 00001000 00000000 4fm!HwEvtProgramWriteDma+0x17e
[d:\svn\drivers\windows\trunk\write.c @ 300]
a667f9ec 8261ea2e 8cc45df0 00000000 8a000000
Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
a667fa18 829840e0 8a000000 8cc45df0 87b75000
hal!HalBuildScatterGatherList+0x1ba
a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000
nt!VfBuildScatterGatherList+0x166
a667fa9c 84d2ef6b 87b75000 02fa0020 00800000
Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
a667fad8 84d2e38c 00000000 8cca21e0 a667faf4
Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
a667fae8 84d2c85f 00000000 a667fb14 8ef888fc
Wdf01000!FxDmaTransactionBase::Execute+0x67
a667faf4 8ef888fc 00000000 ac58ef68 00000000
Wdf01000!imp_WdfDmaTransactionExecute+0x5f
a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128
[d:\svn\drivers\windows\trunk\write.c @ 102]
a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000
Wdf01000!FxIoQueueIoRead::Invoke+0x2a
a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
a667fb74 84d5ca36 92838e00 00000000 9297cf40
Wdf01000!FxIoQueue::DispatchEvents+0x3be
a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00
Wdf01000!FxIoQueue::QueueRequest+0x1ec
a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3
Wdf01000!FxPkgIo::Dispatch+0x27d
a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4
Wdf01000!FxDevice::Dispatch+0x7f
a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
a667fbfc 829923d0 857c01d0 89b7cf00 8cc53738 nt!IofCallDriver+0x1b
a667fc14 829806c3 8cc537f0 89b7cf00 87b88d48 nt!ViFilterDispatchGeneric+0x5e
a667fc38 8268d473 00000000 89b7cf00 8cc53738 nt!IovCallDriver+0x258
a667fc4c 8288eeee 87b88d48 89b7cf00 89b7cfdc nt!IofCallDriver+0x1b
a667fc6c 8288f7a2 8cc53738 87b88d48 00000001
nt!IopSynchronousServiceTail+0x1f8
a667fd08 8269442a 8cc53738 00000000 00000000 nt!NtWriteFile+0x6e8
a667fd08 775564f4 8cc53738 00000000 00000000 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
02f9f958 00000000 00000000 00000000 00000000 0x775564f4

STACK_COMMAND: kb

FOLLOWUP_IP:
4fm!HwTimeoutTimerStart+1e [d:\svn\drivers\windows\trunk\timer.c @ 51]
8ef882de 834e3cff or dword ptr [esi+3Ch],0FFFFFFFFh

FAULTING_SOURCE_CODE:
No source found for 'd:\svn\drivers\windows\trunk\timer.c'

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: 4fm!HwTimeoutTimerStart+1e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: 4fm

IMAGE_NAME: 4fm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4addc9aa

FAILURE_BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arnaud Maye
Sent: Wednesday, October 21, 2009 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Hey Doran,

The output you are requesting is in the email, at the end.

"1: kd> !analyze -v"

Thank you

Arnaud

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 21, 2009 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Send the output of !analyze -v

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@4dsp.com
Sent: Wednesday, October 21, 2009 12:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Dear Gents,

I am having an interesting troubles under Windows 7 (32) with a driver
compiler using the WDK 7.0.

Everything working smoothly until I enable the verifier. If I enable
verifier to check only my driver everything is all right. If I configure
verifier to check all the drivers installed in the system then the BSOD
occurs in my driver.

This BSOD happening (0xC4 P1=8 P2=2 P4=0) while calling WdfTimerStart() in
the following function. This function is itself called by
HwEvtProgramWriteDma().

VOID
HwTimeoutTimerStart(
IN PDEVICE_EXTENSION DevExt
)
{

WdfTimerStart(DevExt->TimeoutTimer, DevExt->Timeout);
<<<<<<=== BSOD occurs here

//
// Reset the timeout to the normal timeout.
//
DevExt->Timeout = WDF_REL_TIMEOUT_IN_SEC(2);
}

If I comment out the call to WdfTimerStart() then the BSOD is NOT happening
while using verifier or not using verifier.

Note that the timer object is created in a non paged code function called by
the AddDevice event. And that the driver is not signed.

This is happening as soon I proceed with DMA operations which makes sense as
each DMA operation
has a timeout and the timer is started on the fly.

Anyone has a clue about what I do wrong or maybe do not understand?

Thank you!

Arnaud

Crash dump for this issue :
---------------------------

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************



Bugcheck Analysis



*************************************************************************


DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000030, raising IRQL to an invalid level,
Arg2: 00000008, current IRQL,
Arg3: 00000002, new IRQL
Arg4: 00000000

Debugging Details:
------------------

Page 5fb48 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffda00c). Type ".hh dbgerr001" for details

BUGCHECK_STR: 0xc4_30

CURRENT_IRQL: 8

REQUESTED_IRQL: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: TEST

LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10

STACK_TEXT:
a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
a667f8e4 8298ad99 00000008 8298b31b 928c0fa8
nt!VerifierBugCheckIfAppropriate+0x30
a667f904 8298b36b 00000002 8298b31b 928c0fa8
nt!ViKeRaiseIrqlSanityChecks+0x3b
a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014
nt!VerifierKfAcquireSpinLock+0x50
a667f944 84d31030 a667f96e 00000000 a667f974
Wdf01000!FxVerifierLock::Lock+0xcd
a667f954 84d5357d a667f96e 8268efd0 8cca21e0
Wdf01000!FxNonPagedObject::Lock+0x23
a667f974 84d4479a feced300 ffffffff a667f9a0 Wdf01000!FxTimer::Start+0x1d
a667f984 8ef882de 00000000 92946f40 feced300 Wdf01000!imp_WdfTimerStart+0x62
a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68 4fm!HwTimeoutTimerStart+0x1e
[d:\svn\drivers\windows\trunk\timer.c @ 51]
a667f9c4 84d2e906 00000001 00001000 00000000 4fm!HwEvtProgramWriteDma+0x17e
[d:\svn\drivers\windows\trunk\write.c @ 300]
a667f9ec 8261ea2e 8cc45df0 00000000 8a000000
Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
a667fa18 829840e0 8a000000 8cc45df0 87b75000
hal!HalBuildScatterGatherList+0x1ba
a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000
nt!VfBuildScatterGatherList+0x166
a667fa9c 84d2ef6b 87b75000 02fa0020 00800000
Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
a667fad8 84d2e38c 00000000 8cca21e0 a667faf4
Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
a667fae8 84d2c85f 00000000 a667fb14 8ef888fc
Wdf01000!FxDmaTransactionBase::Execute+0x67
a667faf4 8ef888fc 00000000 ac58ef68 00000000
Wdf01000!imp_WdfDmaTransactionExecute+0x5f
a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128
[d:\svn\drivers\windows\trunk\write.c @ 102]
a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000
Wdf01000!FxIoQueueIoRead::Invoke+0x2a
a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
a667fb74 84d5ca36 92838e00 00000000 9297cf40
Wdf01000!FxIoQueue::DispatchEvents+0x3be
a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00
Wdf01000!FxIoQueue::QueueRequest+0x1ec
a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3
Wdf01000!FxPkgIo::Dispatch+0x27d
a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4
Wdf01000!FxDevice::Dispatch+0x7f
a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
a667fbfc 8299
---
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
OSR Seminars – OSR

To unsubscribe, visit the List Server section of OSR Online at
ListServer/Forum

---
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
OSR Seminars – OSR

To unsubscribe, visit the List Server section of OSR Online at
ListServer/Forum

The analysis says you were at IRQL 8, and tried to lower the IRQL to 2 as
part of acquiring a spinlock. Is it possible you’re holding an interrupt
lock while you start the timer. If you run prefast on your driver, does is
suggest you’re doing something bad with IRQL’s or locks?

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-385098-
xxxxx@lists.osr.com] On Behalf Of Arnaud Maye
Sent: Wednesday, October 21, 2009 2:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Hmmmm,

The dump is incomplete in my previous email, sorry for that

Thank you,

Arnaud

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
***********************************************************************
*****
***
*
*
* Bugcheck Analysis
*
*
*
***********************************************************************
*****
***

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This
is
because the driver was specified in the registry as being suspect (by
the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
0xA
will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000030, raising IRQL to an invalid level,
Arg2: 00000008, current IRQL,
Arg3: 00000002, new IRQL
Arg4: 00000000

Debugging Details:

Page 5fb48 not present in the dump file. Type “.hh dbgerr004” for
details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
details

BUGCHECK_STR: 0xc4_30

CURRENT_IRQL: 8

REQUESTED_IRQL: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: TEST

LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10

STACK_TEXT:
a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
a667f8e4 8298ad99 00000008 8298b31b 928c0fa8
nt!VerifierBugCheckIfAppropriate+0x30
a667f904 8298b36b 00000002 8298b31b 928c0fa8
nt!ViKeRaiseIrqlSanityChecks+0x3b
a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014
nt!VerifierKfAcquireSpinLock+0x50
a667f944 84d31030 a667f96e 00000000 a667f974
Wdf01000!FxVerifierLock::Lock+0xcd
a667f954 84d5357d a667f96e 8268efd0 8cca21e0
Wdf01000!FxNonPagedObject::Lock+0x23
a667f974 84d4479a feced300 ffffffff a667f9a0
Wdf01000!FxTimer::Start+0x1d
a667f984 8ef882de 00000000 92946f40 feced300
Wdf01000!imp_WdfTimerStart+0x62
a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68
4fm!HwTimeoutTimerStart+0x1e
[d:\svn\drivers\windows\trunk\timer.c @ 51]
a667f9c4 84d2e906 00000001 00001000 00000000
4fm!HwEvtProgramWriteDma+0x17e
[d:\svn\drivers\windows\trunk\write.c @ 300]
a667f9ec 8261ea2e 8cc45df0 00000000 8a000000
Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
a667fa18 829840e0 8a000000 8cc45df0 87b75000
hal!HalBuildScatterGatherList+0x1ba
a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000
nt!VfBuildScatterGatherList+0x166
a667fa9c 84d2ef6b 87b75000 02fa0020 00800000
Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
a667fad8 84d2e38c 00000000 8cca21e0 a667faf4
Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
a667fae8 84d2c85f 00000000 a667fb14 8ef888fc
Wdf01000!FxDmaTransactionBase::Execute+0x67
a667faf4 8ef888fc 00000000 ac58ef68 00000000
Wdf01000!imp_WdfDmaTransactionExecute+0x5f
a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128
[d:\svn\drivers\windows\trunk\write.c @ 102]
a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000
Wdf01000!FxIoQueueIoRead::Invoke+0x2a
a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
a667fb74 84d5ca36 92838e00 00000000 9297cf40
Wdf01000!FxIoQueue::DispatchEvents+0x3be
a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00
Wdf01000!FxIoQueue::QueueRequest+0x1ec
a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3
Wdf01000!FxPkgIo::Dispatch+0x27d
a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4
Wdf01000!FxDevice::Dispatch+0x7f
a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
a667fbfc 829923d0 857c01d0 89b7cf00 8cc53738 nt!IofCallDriver+0x1b
a667fc14 829806c3 8cc537f0 89b7cf00 87b88d48
nt!ViFilterDispatchGeneric+0x5e
a667fc38 8268d473 00000000 89b7cf00 8cc53738 nt!IovCallDriver+0x258
a667fc4c 8288eeee 87b88d48 89b7cf00 89b7cfdc nt!IofCallDriver+0x1b
a667fc6c 8288f7a2 8cc53738 87b88d48 00000001
nt!IopSynchronousServiceTail+0x1f8
a667fd08 8269442a 8cc53738 00000000 00000000 nt!NtWriteFile+0x6e8
a667fd08 775564f4 8cc53738 00000000 00000000 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be
wrong.
02f9f958 00000000 00000000 00000000 00000000 0x775564f4

STACK_COMMAND: kb

FOLLOWUP_IP:
4fm!HwTimeoutTimerStart+1e [d:\svn\drivers\windows\trunk\timer.c @ 51]
8ef882de 834e3cff or dword ptr [esi+3Ch],0FFFFFFFFh

FAULTING_SOURCE_CODE:
No source found for ‘d:\svn\drivers\windows\trunk\timer.c’

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: 4fm!HwTimeoutTimerStart+1e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: 4fm

IMAGE_NAME: 4fm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4addc9aa

FAILURE_BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arnaud Maye
Sent: Wednesday, October 21, 2009 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Hey Doran,

The output you are requesting is in the email, at the end.

“1: kd> !analyze -v”

Thank you

Arnaud

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 21, 2009 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Send the output of !analyze -v

d

Sent from my phone with no t9, all spilling mistakes are not
intentional.

-----Original Message-----
From: xxxxx@4dsp.com
> Sent: Wednesday, October 21, 2009 12:21 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
> WdfTimerStart()
>
> Dear Gents,
>
> I am having an interesting troubles under Windows 7 (32) with a driver
> compiler using the WDK 7.0.
>
> Everything working smoothly until I enable the verifier. If I enable
> verifier to check only my driver everything is all right. If I
> configure
> verifier to check all the drivers installed in the system then the BSOD
> occurs in my driver.
>
> This BSOD happening (0xC4 P1=8 P2=2 P4=0) while calling WdfTimerStart()
> in
> the following function. This function is itself called by
> HwEvtProgramWriteDma().
>
>
> VOID
> HwTimeoutTimerStart(
> IN PDEVICE_EXTENSION DevExt
> )
> {
>
> WdfTimerStart(DevExt->TimeoutTimer, DevExt->Timeout);
> <<<<<<=== BSOD occurs here
>
> //
> // Reset the timeout to the normal timeout.
> //
> DevExt->Timeout = WDF_REL_TIMEOUT_IN_SEC(2);
> }
>
> If I comment out the call to WdfTimerStart() then the BSOD is NOT
> happening
> while using verifier or not using verifier.
>
> Note that the timer object is created in a non paged code function
> called by
> the AddDevice event. And that the driver is not signed.
>
> This is happening as soon I proceed with DMA operations which makes
> sense as
> each DMA operation
> has a timeout and the timer is started on the fly.
>
> Anyone has a clue about what I do wrong or maybe do not understand?
>
> Thank you!
>
> Arnaud
>
>
>
>
> Crash dump for this issue :
> ---------------------------
>
> 1: kd> !analyze -v
> ERROR: FindPlugIns 8007007b
> ***
>

>
>
>
> * Bugcheck Analysis
>
>
>
>

> **
>

>
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
> A device driver attempting to corrupt the system has been caught. This
> is
> because the driver was specified in the registry as being suspect (by
> the
> administrator) and the kernel has enabled substantial checking of this
> driver.
> If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
> 0xA
> will
> be among the most commonly seen crashes.
> Arguments:
> Arg1: 00000030, raising IRQL to an invalid level,
> Arg2: 00000008, current IRQL,
> Arg3: 00000002, new IRQL
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
> Page 5fb48 not present in the dump file. Type “.hh dbgerr004” for
> details
> PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
> details
> PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
> details
>
> BUGCHECK_STR: 0xc4_30
>
> CURRENT_IRQL: 8
>
> REQUESTED_IRQL: 2
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: TEST
>
> LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10
>
> STACK_TEXT:
> a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
> a667f8e4 8298ad99 00000008 8298b31b 928c0fa8
> nt!VerifierBugCheckIfAppropriate+0x30
> a667f904 8298b36b 00000002 8298b31b 928c0fa8
> nt!ViKeRaiseIrqlSanityChecks+0x3b
> a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014
> nt!VerifierKfAcquireSpinLock+0x50
> a667f944 84d31030 a667f96e 00000000 a667f974
> Wdf01000!FxVerifierLock::Lock+0xcd
> a667f954 84d5357d a667f96e 8268efd0 8cca21e0
> Wdf01000!FxNonPagedObject::Lock+0x23
> a667f974 84d4479a feced300 ffffffff a667f9a0
> Wdf01000!FxTimer::Start+0x1d
> a667f984 8ef882de 00000000 92946f40 feced300
> Wdf01000!imp_WdfTimerStart+0x62
> a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68
> 4fm!HwTimeoutTimerStart+0x1e
> [d:\svn\drivers\windows\trunk\timer.c @ 51]
> a667f9c4 84d2e906 00000001 00001000 00000000
> 4fm!HwEvtProgramWriteDma+0x17e
> [d:\svn\drivers\windows\trunk\write.c @ 300]
> a667f9ec 8261ea2e 8cc45df0 00000000 8a000000
> Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
> a667fa18 829840e0 8a000000 8cc45df0 87b75000
> hal!HalBuildScatterGatherList+0x1ba
> a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000
> nt!VfBuildScatterGatherList+0x166
> a667fa9c 84d2ef6b 87b75000 02fa0020 00800000
> Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
> a667fad8 84d2e38c 00000000 8cca21e0 a667faf4
> Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
> a667fae8 84d2c85f 00000000 a667fb14 8ef888fc
> Wdf01000!FxDmaTransactionBase::Execute+0x67
> a667faf4 8ef888fc 00000000 ac58ef68 00000000
> Wdf01000!imp_WdfDmaTransactionExecute+0x5f
> a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128
> [d:\svn\drivers\windows\trunk\write.c @ 102]
> a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000
> Wdf01000!FxIoQueueIoRead::Invoke+0x2a
> a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00
> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
> a667fb74 84d5ca36 92838e00 00000000 9297cf40
> Wdf01000!FxIoQueue::DispatchEvents+0x3be
> a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00
> Wdf01000!FxIoQueue::QueueRequest+0x1ec
> a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3
> Wdf01000!FxPkgIo::Dispatch+0x27d
> a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4
> Wdf01000!FxDevice::Dispatch+0x7f
> a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
> a667fbfc 8299
> —
> 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
>
>
> —
> 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 Jan,

Prefast did not complain about this but I believe prefast is not able to
track these issues if this is happening in a sub function. Actually I’ve
seen this on another part of this driver. WdfRequestComplete called in a sub
function inside the spinlock would not be detected by prefast.

Indeed. In the function HwEvtProgramReadDma() we have something like :

  1. WdfInterruptAcquireLock( devExt->Interrupt );
  2. Some code
  3. HwTimeoutTimerStart(devExt);
  4. WdfInterruptReleaseLock( devExt->Interrupt );

I’ve confirmed that by inverting 3) and 4), start the timer out of the
spinlock seems to fix the issue I have.

I understand why the issue is happening but starting the timer without being
interrupted seems to be correct in my point of view.

Well anyway I guess I will rewrite this driver from scratch, especially the
timer module.

Thank you Jan!

Arnaud

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, October 21, 2009 1:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

The analysis says you were at IRQL 8, and tried to lower the IRQL to 2 as
part of acquiring a spinlock. Is it possible you’re holding an interrupt
lock while you start the timer. If you run prefast on your driver, does is
suggest you’re doing something bad with IRQL’s or locks?

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-385098-
xxxxx@lists.osr.com] On Behalf Of Arnaud Maye
Sent: Wednesday, October 21, 2009 2:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Hmmmm,

The dump is incomplete in my previous email, sorry for that

Thank you,

Arnaud

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
***********************************************************************
*****
***
*
*
* Bugcheck Analysis
*
*
*
***********************************************************************
*****
***

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This
is
because the driver was specified in the registry as being suspect (by
the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
0xA
will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000030, raising IRQL to an invalid level,
Arg2: 00000008, current IRQL,
Arg3: 00000002, new IRQL
Arg4: 00000000

Debugging Details:

Page 5fb48 not present in the dump file. Type “.hh dbgerr004” for
details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
details
PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
details

BUGCHECK_STR: 0xc4_30

CURRENT_IRQL: 8

REQUESTED_IRQL: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: TEST

LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10

STACK_TEXT:
a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
a667f8e4 8298ad99 00000008 8298b31b 928c0fa8
nt!VerifierBugCheckIfAppropriate+0x30
a667f904 8298b36b 00000002 8298b31b 928c0fa8
nt!ViKeRaiseIrqlSanityChecks+0x3b
a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014
nt!VerifierKfAcquireSpinLock+0x50
a667f944 84d31030 a667f96e 00000000 a667f974
Wdf01000!FxVerifierLock::Lock+0xcd
a667f954 84d5357d a667f96e 8268efd0 8cca21e0
Wdf01000!FxNonPagedObject::Lock+0x23
a667f974 84d4479a feced300 ffffffff a667f9a0
Wdf01000!FxTimer::Start+0x1d
a667f984 8ef882de 00000000 92946f40 feced300
Wdf01000!imp_WdfTimerStart+0x62
a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68
4fm!HwTimeoutTimerStart+0x1e
[d:\svn\drivers\windows\trunk\timer.c @ 51]
a667f9c4 84d2e906 00000001 00001000 00000000
4fm!HwEvtProgramWriteDma+0x17e
[d:\svn\drivers\windows\trunk\write.c @ 300]
a667f9ec 8261ea2e 8cc45df0 00000000 8a000000
Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
a667fa18 829840e0 8a000000 8cc45df0 87b75000
hal!HalBuildScatterGatherList+0x1ba
a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000
nt!VfBuildScatterGatherList+0x166
a667fa9c 84d2ef6b 87b75000 02fa0020 00800000
Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
a667fad8 84d2e38c 00000000 8cca21e0 a667faf4
Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
a667fae8 84d2c85f 00000000 a667fb14 8ef888fc
Wdf01000!FxDmaTransactionBase::Execute+0x67
a667faf4 8ef888fc 00000000 ac58ef68 00000000
Wdf01000!imp_WdfDmaTransactionExecute+0x5f
a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128
[d:\svn\drivers\windows\trunk\write.c @ 102]
a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000
Wdf01000!FxIoQueueIoRead::Invoke+0x2a
a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
a667fb74 84d5ca36 92838e00 00000000 9297cf40
Wdf01000!FxIoQueue::DispatchEvents+0x3be
a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00
Wdf01000!FxIoQueue::QueueRequest+0x1ec
a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3
Wdf01000!FxPkgIo::Dispatch+0x27d
a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4
Wdf01000!FxDevice::Dispatch+0x7f
a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
a667fbfc 829923d0 857c01d0 89b7cf00 8cc53738 nt!IofCallDriver+0x1b
a667fc14 829806c3 8cc537f0 89b7cf00 87b88d48
nt!ViFilterDispatchGeneric+0x5e
a667fc38 8268d473 00000000 89b7cf00 8cc53738 nt!IovCallDriver+0x258
a667fc4c 8288eeee 87b88d48 89b7cf00 89b7cfdc nt!IofCallDriver+0x1b
a667fc6c 8288f7a2 8cc53738 87b88d48 00000001
nt!IopSynchronousServiceTail+0x1f8
a667fd08 8269442a 8cc53738 00000000 00000000 nt!NtWriteFile+0x6e8
a667fd08 775564f4 8cc53738 00000000 00000000 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be
wrong.
02f9f958 00000000 00000000 00000000 00000000 0x775564f4

STACK_COMMAND: kb

FOLLOWUP_IP:
4fm!HwTimeoutTimerStart+1e [d:\svn\drivers\windows\trunk\timer.c @ 51]
8ef882de 834e3cff or dword ptr [esi+3Ch],0FFFFFFFFh

FAULTING_SOURCE_CODE:
No source found for ‘d:\svn\drivers\windows\trunk\timer.c’

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: 4fm!HwTimeoutTimerStart+1e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: 4fm

IMAGE_NAME: 4fm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4addc9aa

FAILURE_BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

BUCKET_ID: 0xc4_30_VRF_4fm!HwTimeoutTimerStart+1e

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arnaud Maye
Sent: Wednesday, October 21, 2009 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Hey Doran,

The output you are requesting is in the email, at the end.

“1: kd> !analyze -v”

Thank you

Arnaud

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 21, 2009 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Send the output of !analyze -v

d

Sent from my phone with no t9, all spilling mistakes are not
intentional.

-----Original Message-----
From: xxxxx@4dsp.com
> Sent: Wednesday, October 21, 2009 12:21 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
> WdfTimerStart()
>
> Dear Gents,
>
> I am having an interesting troubles under Windows 7 (32) with a driver
> compiler using the WDK 7.0.
>
> Everything working smoothly until I enable the verifier. If I enable
> verifier to check only my driver everything is all right. If I
> configure
> verifier to check all the drivers installed in the system then the BSOD
> occurs in my driver.
>
> This BSOD happening (0xC4 P1=8 P2=2 P4=0) while calling WdfTimerStart()
> in
> the following function. This function is itself called by
> HwEvtProgramWriteDma().
>
>
> VOID
> HwTimeoutTimerStart(
> IN PDEVICE_EXTENSION DevExt
> )
> {
>
> WdfTimerStart(DevExt->TimeoutTimer, DevExt->Timeout);
> <<<<<<=== BSOD occurs here
>
> //
> // Reset the timeout to the normal timeout.
> //
> DevExt->Timeout = WDF_REL_TIMEOUT_IN_SEC(2);
> }
>
> If I comment out the call to WdfTimerStart() then the BSOD is NOT
> happening
> while using verifier or not using verifier.
>
> Note that the timer object is created in a non paged code function
> called by
> the AddDevice event. And that the driver is not signed.
>
> This is happening as soon I proceed with DMA operations which makes
> sense as
> each DMA operation
> has a timeout and the timer is started on the fly.
>
> Anyone has a clue about what I do wrong or maybe do not understand?
>
> Thank you!
>
> Arnaud
>
>
>
>
> Crash dump for this issue :
> ---------------------------
>
> 1: kd> !analyze -v
> ERROR: FindPlugIns 8007007b
> ***
>

>
>
>
> * Bugcheck Analysis
>
>
>
>

> **
>

>
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
> A device driver attempting to corrupt the system has been caught. This
> is
> because the driver was specified in the registry as being suspect (by
> the
> administrator) and the kernel has enabled substantial checking of this
> driver.
> If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
> 0xA
> will
> be among the most commonly seen crashes.
> Arguments:
> Arg1: 00000030, raising IRQL to an invalid level,
> Arg2: 00000008, current IRQL,
> Arg3: 00000002, new IRQL
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
> Page 5fb48 not present in the dump file. Type “.hh dbgerr004” for
> details
> PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
> details
> PEB is paged out (Peb.Ldr = 7ffda00c). Type “.hh dbgerr001” for
> details
>
> BUGCHECK_STR: 0xc4_30
>
> CURRENT_IRQL: 8
>
> REQUESTED_IRQL: 2
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: TEST
>
> LAST_CONTROL_TRANSFER: from 82985f03 to 8272dd10
>
> STACK_TEXT:
> a667f8c4 82985f03 000000c4 00000030 00000008 nt!KeBugCheckEx+0x1e
> a667f8e4 8298ad99 00000008 8298b31b 928c0fa8
> nt!VerifierBugCheckIfAppropriate+0x30
> a667f904 8298b36b 00000002 8298b31b 928c0fa8
> nt!ViKeRaiseIrqlSanityChecks+0x3b
> a667f920 84d6c7cf 8268efd0 92946f40 8ef8a014
> nt!VerifierKfAcquireSpinLock+0x50
> a667f944 84d31030 a667f96e 00000000 a667f974
> Wdf01000!FxVerifierLock::Lock+0xcd
> a667f954 84d5357d a667f96e 8268efd0 8cca21e0
> Wdf01000!FxNonPagedObject::Lock+0x23
> a667f974 84d4479a feced300 ffffffff a667f9a0
> Wdf01000!FxTimer::Start+0x1d
> a667f984 8ef882de 00000000 92946f40 feced300
> Wdf01000!imp_WdfTimerStart+0x62
> a667f9a0 8ef88790 8cca21e0 92906f08 ac58ef68
> 4fm!HwTimeoutTimerStart+0x1e
> [d:\svn\drivers\windows\trunk\timer.c @ 51]
> a667f9c4 84d2e906 00000001 00001000 00000000
> 4fm!HwEvtProgramWriteDma+0x17e
> [d:\svn\drivers\windows\trunk\write.c @ 300]
> a667f9ec 8261ea2e 8cc45df0 00000000 8a000000
> Wdf01000!FxDmaScatterGatherTransaction::_AdapterListControl+0x7e
> a667fa18 829840e0 8a000000 8cc45df0 87b75000
> hal!HalBuildScatterGatherList+0x1ba
> a667fa64 84d2e0d0 8ccd6200 8cc45df0 87b75000
> nt!VfBuildScatterGatherList+0x166
> a667fa9c 84d2ef6b 87b75000 02fa0020 00800000
> Wdf01000!FxDmaScatterGatherTransaction::BuildScatterGatherList+0x40
> a667fad8 84d2e38c 00000000 8cca21e0 a667faf4
> Wdf01000!FxDmaScatterGatherTransaction::StageTransfer+0xfd
> a667fae8 84d2c85f 00000000 a667fb14 8ef888fc
> Wdf01000!FxDmaTransactionBase::Execute+0x67
> a667faf4 8ef888fc 00000000 ac58ef68 00000000
> Wdf01000!imp_WdfDmaTransactionExecute+0x5f
> a667fb14 84d5802a 6d7c71f8 53aa90d0 00800000 4fm!HwEvtIoWrite+0x128
> [d:\svn\drivers\windows\trunk\write.c @ 102]
> a667fb30 84d5936e 6d7c71f8 53aa90d0 00800000
> Wdf01000!FxIoQueueIoRead::Invoke+0x2a
> a667fb58 84d5b9ac 53aa90d0 ac556f28 92838e00
> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x2bb
> a667fb74 84d5ca36 92838e00 00000000 9297cf40
> Wdf01000!FxIoQueue::DispatchEvents+0x3be
> a667fb94 84d5e824 ac556f28 8579d8e0 89b7cf00
> Wdf01000!FxIoQueue::QueueRequest+0x1ec
> a667fbb8 84d4da3f 89b7cf00 a667fbe8 829806c3
> Wdf01000!FxPkgIo::Dispatch+0x27d
> a667fbc4 829806c3 8cc45df0 89b7cf00 89b7cfd4
> Wdf01000!FxDevice::Dispatch+0x7f
> a667fbe8 8268d473 00000000 89b7cff8 8cc45df0 nt!IovCallDriver+0x258
> a667fbfc 8299
> —
> 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
>
>
> —
> 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

>>. WdfRequestComplete called in a sub function inside the spinlock would
not be detected by prefast.

That is because it is permitted.

Jan said specifically an “Interrupt Spinlock” which raises IRQL to Device
Level. Calling WdfRequestComplete() or any other routine with an annotated
maximum IRQL of DISPATCH_LEVEL while holding an Interrupt Spinlock is going
to be flagged as an illegal IRQL transition.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arnaud Maye
Sent: Wednesday, October 21, 2009 10:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Hello Jan,

Prefast did not complain about this but I believe prefast is not able to
track these issues if this is happening in a sub function. Actually I’ve
seen this on another part of this driver. WdfRequestComplete called in a sub
function inside the spinlock would not be detected by prefast.

Indeed. In the function HwEvtProgramReadDma() we have something like :

  1. WdfInterruptAcquireLock( devExt->Interrupt );
  2. Some code
  3. HwTimeoutTimerStart(devExt);
  4. WdfInterruptReleaseLock( devExt->Interrupt );

I’ve confirmed that by inverting 3) and 4), start the timer out of the
spinlock seems to fix the issue I have.

I understand why the issue is happening but starting the timer without being
interrupted seems to be correct in my point of view.

Well anyway I guess I will rewrite this driver from scratch, especially the
timer module.

Thank you Jan!

Arnaud

Yeah. The WdfRequestComplete() call was in an interrupt spin lock. Actually
WdfRequestCompleteWithInformation() for the rd/wr DMA was in a subfonction
and the WdfRequestComplete() for other timeout was not in a subfunction.
Prefast did only flag the call to WdfRequestComplete() to be illegal. Not
the call to WdfRequestCompleteWithInformation() in a sub function part of
the same “interrupt spin lock”.

In the case discussed with Jan, prefast was not able to figure this out as
well. I have no errors and no warning.

Maybe some specific settings required by prefast. On WDK 7.0 the prefast
analysis is “automatic” I did not change any settings.

Arnaud

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, October 21, 2009 4:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

>. WdfRequestComplete called in a sub function inside the spinlock would
not be detected by prefast.

That is because it is permitted.

Jan said specifically an “Interrupt Spinlock” which raises IRQL to Device
Level. Calling WdfRequestComplete() or any other routine with an annotated
maximum IRQL of DISPATCH_LEVEL while holding an Interrupt Spinlock is going
to be flagged as an illegal IRQL transition.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arnaud Maye
Sent: Wednesday, October 21, 2009 10:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 7 / WDK 7.0 - Weird crash while calling
WdfTimerStart()

Hello Jan,

Prefast did not complain about this but I believe prefast is not able to
track these issues if this is happening in a sub function. Actually I’ve
seen this on another part of this driver. WdfRequestComplete called in a sub
function inside the spinlock would not be detected by prefast.

Indeed. In the function HwEvtProgramReadDma() we have something like :

  1. WdfInterruptAcquireLock( devExt->Interrupt );
  2. Some code
  3. HwTimeoutTimerStart(devExt);
  4. WdfInterruptReleaseLock( devExt->Interrupt );

I’ve confirmed that by inverting 3) and 4), start the timer out of the
spinlock seems to fix the issue I have.

I understand why the issue is happening but starting the timer without being
interrupted seems to be correct in my point of view.

Well anyway I guess I will rewrite this driver from scratch, especially the
timer module.

Thank you Jan!

Arnaud


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

So, Prefast is working correctly. It’s checks are generally confined to the scope of a single function.

There are millions of errors that Prefast doesn’t catch, you know. If Prefast doesn’t give you a warning, that doesn’t mean your code is correct :slight_smile:

The aim of Prefast is just to give you some assistance, and it makes no promises about being comprehensive.

Look at the documentation for WdfRequestCompleteWithInformation:

IRQL: <=DISPATCH_LEVEL

So, this… coupled with the output of the !analyze -v clearly points to your bug…

Peter
OSR

You may want to try running Staticdv on this driver with the following command line

“Staticdv /rule:“KmdfIrql”&&staticdv /view”.

This may catch the above IRQL violation in the driver.

-Con.