IOCTL processing - concurrent

Hi,

We have developed KMDF USB-Serial driver.

Currently we are facing the issue of concurrent IOCTL handling.

Below is the checked build log:

vEnum.sys: In Serenum_IoCtl
vEnum.sys: In Serenum_DispatchPassThrough

vEnum.sys: In Serenum_IoCtl
vEnum.sys: In Serenum_DispatchPassThrough

–> vUsb_ProcessIOCTL
vUsb_ProcessIOCTL IOCTL_SERIAL_GET_BAUD_RATE - 1b0050
bef vUsb_GetVendor irql 2

–> vUsb_ProcessIOCTL
vUsb_ProcessIOCTL IOCTL_SERIAL_SET_WAIT_MASK - 1b0044
.
.
WdfRequestCompleteWithPriorityBoost…
Complete Request: 7DF68698 Stat: 0 Info: 0 MJ: e
.
.
In GetVendorCompletionRoutine status 0
exit vUsb_GetVendor Request=0x1d Value=0x0 Status=0x0
Complete Request: 7DD70DD0 Stat: 0 Info: 4 MJ: e

(vEnum.sys: In Serenum_DispatchPassThrough)
Here VEnum.sys is the upper filter (modifiied serenum ) for the function driver.

From the log: upper filter is sending back-to-back IOCTLS ( Serenum_DispatchPassThrough)

I have registered “vUsb_ProcessIOCTL” for processing these ioctls in function driver.

Here: IOCTL_SERIAL_GET_BAUD_RATE is the 1st IOCTL received, it internally sends custom USB vendor request using “vUsb_GetVendor” function

Details of vUsb_GetVendor: sends vendor commands using below options and APIs
options: WDF_REQUEST_SEND_OPTION_SYNCHRONOUS | WDF_REQUEST_SEND_OPTION_TIMEOUT

WDF_USB_CONTROL_SETUP_PACKET_INIT_VENDOR()
WdfUsbTargetDeviceFormatRequestForControlTransfer()
WdfRequestSend()

For vUsb_GetVendor: completion routine is GetVendorCompletionRoutine, which checks the completion status and copies back the data recived from the device.

Before the Get_BAud_rate ioctl is processed (i.e. its completion routine is called) function driver is getting another ioctl IOCTL_SERIAL_SET_WAIT_MASK
and after completing this, the completion routine for the get_baud_rate is called,
At this time driver is getting hanged.

Please let us know how to process concurrently and avoid the system hang.

Here is the “analyze -v” o/p post PC hang:

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

*** ERROR: Symbol file could not be found. Defaulted to export symbols for MSCOMM32.OCX -
PROCESS_NAME: SimuladorV.ex

FAULTING_IP:
nt!RtlpBreakWithStatusInstruction+0
80527c0c cc int 3

EXCEPTION_RECORD: ffffffff – (.exr 0xffffffffffffffff)
ExceptionAddress: 80527c0c (nt!RtlpBreakWithStatusInstruction)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8054ae4c
Parameter[2]: 8054c5c0

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 8054ae4c
EXCEPTION_PARAMETER3: 8054c5c0
DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x0

STACK_TEXT:
f73027e4 80541155 00000001 f7302702 000000d1 nt!RtlpBreakWithStatusInstruction
f73027e4 f84713be 00000001 f7302702 000000d1 nt!KeUpdateSystemTime+0x165
f7302878 f8471802 81f06b38 81ff8de0 00000000 wdf01000!FxVerifierLock::GetThreadTableEntry+0x3a
f73028a8 f8436030 f73028d4 81e25680 f73028cc wdf01000!FxVerifierLock::Lock+0x100
f73028b8 f84438dc f73028d4 81f3035c 00000000 wdf01000!FxNonPagedObject::Lock+0x23
f73028cc f7285e4d 00000002 8228f228 00000000 wdf01000!imp_WdfRequestCompleteWithInformation+0x6d
f73028e4 f7285e16 7dd70dd0 00000000 00000004 vUSBPP!WdfRequestCompleteWithInformation+0x1d [d:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfrequest.h @ 1038]
f7302900 f728af5f 7dd70dd0 00000000 00000004 vUSBPP!UsbCompleteRequest+0x76 [d:\jagannath\16mar11\silabs\nrt-v\nrt\utils.c @ 222]
f7302a20 f845d072 7e0cfd88 7dd70dd0 00000004 vUSBPP!vUsb_ProcessIOCTL+0x1b4f [d:\jagannath\16mar11\silabs\nrt-v\nrt\ioctl.c @ 3259]
f7302a44 f845e3d0 7e0cfd88 7dd70dd0 00000004 wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
f7302a74 f84609ac 7dd70dd0 8228f228 81f30270 wdf01000!FxIoQueue::DispatchRequestToDriver+0x31d
f7302a90 f8461a36 81f30200 00000000 81ff6a60 wdf01000!FxIoQueue::DispatchEvents+0x3be
f7302ab0 f8463824 8228f228 821205e0 81ffff38 wdf01000!FxIoQueue::QueueRequest+0x1ec
f7302ad4 f8452a3f 82be4e48 f7302b14 804ee129 wdf01000!FxPkgIo::Dispatch+0x27d
f7302ae0 804ee129 821205e0 82be4e48 806d32e8 wdf01000!FxDevice::Dispatch+0x7f
f7302af0 8064e328 82be4f88 82be4fac 81e4eae0 nt!IopfCallDriver+0x31
f7302b14 80658d56 81e4ea28 81e53468 81e88d00 nt!IovCallDriver+0xa0
f7302b28 804ee129 81e4ea28 82be4e48 806d32e8 nt!ViDriverDispatchGeneric+0x2a
f7302b38 8064e328 8219d470 82287f38 81e88d00 nt!IopfCallDriver+0x31
f7302b5c f756d9c3 80527d34 0000000e 00017e8c nt!IovCallDriver+0xa0
f7302b8c f756d4ac 8219d470 82be4e48 001b0050 vEnum!Serenum_DispatchPassThrough+0x2a3 [d:\winddk\7600.16385.1\src\serial\serenum\serenum.c @ 593]
f7302bc8 804ee129 8219d470 82be4e48 806d32e8 vEnum!Serenum_IoCtl+0x1dc [d:\winddk\7600.16385.1\src\serial\serenum\serenum.c @ 323]
f7302bd8 8064e328 82be4fd0 82be4ff4 81e88d48 nt!IopfCallDriver+0x31
f7302bfc 80658d56 81e88c90 81e53468 82be4e00 nt!IovCallDriver+0xa0
f7302c10 804ee129 81e88c90 82be4e48 806d32e8 nt!ViDriverDispatchGeneric+0x2a
f7302c20 8064e328 81f23508 806d32d0 82be4e48 nt!IopfCallDriver+0x31
f7302c44 80574e56 82be4fd8 81f23508 82be4e48 nt!IovCallDriver+0xa0
f7302c58 80575d11 81e88c90 82be4e48 81f23508 nt!IopSynchronousServiceTail+0x70
f7302d00 8056e57c 00000130 00000150 00000000 nt!IopXxxControlFile+0x5e7
f7302d34 8053d6d8 00000130 00000150 00000000 nt!NtDeviceIoControlFile+0x2a
f7302d34 7c90e514 00000130 00000150 00000000 nt!KiFastCallEntry+0xf8
0012f564 7c90d28a 7c866bf1 00000130 00000150 ntdll!KiFastSystemCallRet
0012f568 7c866bf1 00000130 00000150 00000000 ntdll!ZwDeviceIoControlFile+0xc
0012f5d0 21c146ef 00000130 0012f5ec 0015afb8 kernel32!GetCommState+0x5a
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f60c 21c12804 00000000 0012f868 21c13340 MSCOMM32!DllGetClassObject+0x30dc
0012f638 771362e8 0015b078 000000bc 00000004 MSCOMM32!DllGetClassObject+0x11f1
0012f6c8 21c142f4 00167d48 0015b078 00000000 OLEAUT32!CTypeInfo2::Invoke+0x234
0012f6f8 21c1428b 0015afb8 00000014 00167d48 MSCOMM32!DllGetClassObject+0x2ce1
0012f724 73489738 0015afb8 00000014 7343ae58 MSCOMM32!DllGetClassObject+0x2c78
0012f760 734f90f8 00d12ac4 00000014 7343ae58 MSVBVM60!OLECTL::Invoke+0x16c
0012f7b4 73527b8d 00d12ac4 00000014 7343ae58 MSVBVM60!SafeInvoke+0x68
0012f820 735279a5 00d12ac4 00000014 00000004 MSVBVM60!__vbaLateIdCall+0x3
0012f84c 73520f35 00d12ac4 00000014 fffffffd MSVBVM60!ExVarIndexStVar+0x12a
0012f938 7351d348 0044301c 00000000 00000000 MSVBVM60!lblEX_LdFixedStr+0x6
0012fb14 73471ce3 0014e0e0 0012fb30 004358e4 MSVBVM60!tblByteDisp+0x1ce
0012fb30 73471fe4 004358e4 0012fbec 00000002 MSVBVM60!CallProcWithArgs+0x1e
0012fb48 734720ca 0014e230 0012fc2c 0012fbec MSVBVM60!InvokeVtblEvent+0x32
0012fb68 73429e70 0014e0fc 73485301 00d106cc MSVBVM60!InvokeEvent+0xaf
0012fb70 73485301 00d106cc 0012fc50 7347244b MSVBVM60!DESK::AddRef+0x13
0012fb7c 7347244b 0012fc2c 0012fbec 00000002 MSVBVM60!DESK::AddCtlRef+0x16
00000000 00000000 00000000 00000000 00000000 MSVBVM60!EvtErrFireWorker+0x240

Thanks in adv.

What’s in the WDF log… do a !WDFLOGDUMP

Read: http://www.osronline.com/article.cfm?article=496

Peter
OSR

xxxxx@gmail.com wrote:

We have developed KMDF USB-Serial driver.

Currently we are facing the issue of concurrent IOCTL handling.

Here: IOCTL_SERIAL_GET_BAUD_RATE is the 1st IOCTL received, it internally sends custom USB vendor request using “vUsb_GetVendor” function

Details of vUsb_GetVendor: sends vendor commands using below options and APIs
options: WDF_REQUEST_SEND_OPTION_SYNCHRONOUS | WDF_REQUEST_SEND_OPTION_TIMEOUT

WDF_USB_CONTROL_SETUP_PACKET_INIT_VENDOR()
WdfUsbTargetDeviceFormatRequestForControlTransfer()
WdfRequestSend()

For vUsb_GetVendor: completion routine is GetVendorCompletionRoutine, which checks the completion status and copies back the data recived from the device.

Before the Get_BAud_rate ioctl is processed (i.e. its completion routine is called) function driver is getting another ioctl IOCTL_SERIAL_SET_WAIT_MASK
and after completing this, the completion routine for the get_baud_rate is called,
At this time driver is getting hanged.

Please let us know how to process concurrently and avoid the system hang.

Well, you’re going to have to debug this. This kind of thing can happen
if you set your SynchronizationScope wrong, or set
AutomaticSerialization when you didn’t really need it. It is easy in
KMDF to over-synchronize yourself, to get into situations where your
driver cannot advance because your settings do not allow it. If you
want requests to be serialized, then you should use a sequential queue.
If you want to handle requests in parallel, then you need to figure out
how much automatic synchronization you can afford and how much you
should be doing on your own.

Here is the “analyze -v” o/p post PC hang:

“analyze -v” is virtually useless in a hang situation, because there’s
nothing for it to diagnose.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Here is the wdf log for func driver:
kd> !WDFKD.WDFLOGDUMP vusbpp
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting log is: C:\WinDDK\7600.16385.1\tools\tracing\i386\Wdf01009.tmf
Log at 81c9c000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 40, 50, 100
There are 57 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x82500E28
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxVerifierLock::InitializeLockOrder - Object Type 0x1204 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
8: FxIoTarget::SubmitLocked - ignoring WDFIOTARGET 7E23C618 state, sending WDFREQUEST F893E4E8, state WdfIoTargetStarted
9: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
10: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power idle state FxIdleStarted from FxIdleStopped
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
15: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
16: FxPkgIo::ResumeProcessingForPower - Power resume all queues of WDFDEVICE 0x7E481FE0
17: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
18: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
19: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
20: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarting
22: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
23: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
24: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering power idle state FxIdleDisabled from FxIdleDisabled
25: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
26: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
27: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000014(IRP_MN_QUERY_PNP_DEVICE_STATE) IRP 0x8253CE28
28: FxPkgFdo::HandleQueryPnpDeviceStateCompletion - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0 returning PNP_DEVICE_STATE 0x0 IRP 0x8253CE28
29: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type 0xFFFFFFFF IRP 0x824E0E28
30: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type 0xFFFFFFFF IRP 0x825A6E28
31: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type TargetDeviceRelation IRP 0x824B2E28
32: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0x82348E28
33: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 7E481FE0 returning 0 devices in relations 82228FF8
34: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
35: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
36: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
37: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
38: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
39: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
40: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0x82500E28
41: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 7E481FE0 returning 0 devices in relations 8253EFF8
42: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0x82460E28
43: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 7E481FE0 returning 0 devices in relations 822C8FF8
44: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
45: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
46: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
47: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
48: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
49: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7DFE11F8 is already held, deferring to dpc or workitem
50: FxPkgPnp::Dispatch - WDFDEVICE 0x7E481FE0 !devobj 0x81CE82C0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0x82344E28
51: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 7E481FE0 returning 0 devices in relations 823AEFF8
52: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7E29A850 is already held, deferring to dpc or workitem
53: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7E29A850 is already held, deferring to dpc or workitem
54: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7E29A850 is already held, deferring to dpc or workitem
55: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7E29A850 is already held, deferring to dpc or workitem
56: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7E4C71F8 is already held, deferring to dpc or workitem
57: FxIoQueue::CanThreadDispatchEventsLocked - Presentation lock for WDFQUEUE 0x7E4C71F8 is already held, deferring to dpc or workitem
---- end of log ----

==========================================================

And for the filter driver it did not provided log
!WDFKD.WDFLOGDUMP venum.sys
Could not find vfienum in wdfldr client list

Thanks Tim,

One more thing I noticed, above resulted when verifier is on (with ff settings) for both func and filter drivers

However if verifier is made of, this issue is not coming… strange!

Not really so strange.

What are your Synchronization Scope and do you have an Execution Level constraint established?

Are you using any manual locking – because a quick look would seem to indicate that’s where your deadlock might be.

Peter
OSR

Thanks,

Sync scope is device level WdfSynchronizationScopeDevice
and there is no execution constraint set
default queue is parallel.

Yes, there are couple of locks used,
1st in AddDevice routine and surprise removal, cleanup routines
2nd in read and write routines

but the Ioctls will come after addDevice and before read/write starts
and this dead loack is happening during IOCTLs processing

Is there any way to find out which particular lock is held?

xxxxx@gmail.com wrote:

Sync scope is device level WdfSynchronizationScopeDevice
and there is no execution constraint set
default queue is parallel.

Yes, there are couple of locks used,
1st in AddDevice routine and surprise removal, cleanup routines
2nd in read and write routines

but the Ioctls will come after addDevice and before read/write starts
and this dead loack is happening during IOCTLs processing

With sync scope set to device, only one I/O callback can run at a time.
As long as your ioctl handler has not returned, no additional I/O
requests will be dispatched. You should read the page on “Using
Automatic Synchronization”. As I’ve said before, KMDF makes it very
easy to over-synchronize yourself. You need to make sure you are asking
for what you really want.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim & Peter,

I will definitely revisit the “using auto-sync” article.

One more observation, I am testing with 2 USB devices having different VID and PID

with 1st, above issue is reported, i.e. deadlock is happening when driver is trying to issue “vUsb_GetVendor” command (and its completion routine) for get_baud_rate and set_wait_mask.

However for the 2nd usb device, which doesnot expects any vendor commands, the application is working fine.
This means, deadlock is happening when vUsb_GetVendor and its completion routine are in the process.

Is there a way to synchronize this.

All the above incidents are observed on Xpx86

On Win7 x86: at the same stage I am getting assert “DPC watch dog timeout”

xxxxx@gmail.com wrote:

I will definitely revisit the “using auto-sync” article.

One more observation, I am testing with 2 USB devices having different VID and PID

with 1st, above issue is reported, i.e. deadlock is happening when driver is trying to issue “vUsb_GetVendor” command (and its completion routine) for get_baud_rate and set_wait_mask.

However for the 2nd usb device, which doesnot expects any vendor commands, the application is working fine.
This means, deadlock is happening when vUsb_GetVendor and its completion routine are in the process.

Is there a way to synchronize this.

Synchronize what? The likely problem here is that you are already
synchronizing too much. We can’t answer that question for you. YOU
have to answer it, based on your actual requirements. You need to know
whether you need to be able to handle requests while you are busy doing
something else.

What do you think you need to synchronize? Are you protecting some
shared piece of memory? If not, then are you sure you need any
automatic synchronization at all?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim for your suggestions.

I tried tweaking the design of the KMDF
1.changing sync scope from device level to indivisual queue level
2. introducing seperate queue for ioctl handling (dispacthparallel and sequential)
3. making default queue seq, and
4. autoserialization off for dpcs and timers…

however none of them provided result,

finally I registered a wdm preprocessing callback for IRP_MJ_DEVICE_CONTROL and started handling IOCTLs one by one (holding the new ioctl unless previous one is completed) this technique helped in overcoming the above reported isssue.

That is win7 complaining that you are stuck in a DPC (due to your
locking bug) for too long.

As these are spinlocks: all of the lock owning threads are resident.
!stacks in windbg will generally show you who is owning what.

Mark Roddy

On Wed, Jun 1, 2011 at 5:19 PM, wrote:
> All the above incidents are observed on Xpx86
>
> On Win7 x86: at the same stage I am getting assert “DPC watch dog timeout”
>
> —
> 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
>

Thanks Mark,

I will check with your suggestions and revert