System getting hang

I have two drivers one is virtual com port and second one is usb driver. We are communicating to usb device through the virtual com port. Now we have need to send the usb vendor request to check the status of usb device.

I am continuously sending an IOCTL from the virtual com port to usb device to send the vendor request to get the device status.

I am perfectly getting the status of the usb device on serial application but problem is that when i am sending the data through the serial application to the usb device system getting hang randomly.

I am sending the vendor request at passive level from the USB driver to USB device. please do the needful because this issues is totally random.

One approach I use is to run with the debugger and once the hang occurs use
!process 0 7 to get all the data on the threads in the system. Then search
the output for all the threads that are using the drivers I have created.
This can give you an idea if you have a deadlock or an unfulfilled wait
condition.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, April 12, 2017 12:54 PM
To: Kernel Debugging Interest List
Subject: [windbg] System getting hang

I have two drivers one is virtual com port and second one is usb driver. We
are communicating to usb device through the virtual com port. Now we have
need to send the usb vendor request to check the status of usb device.

I am continuously sending an IOCTL from the virtual com port to usb device
to send the vendor request to get the device status.

I am perfectly getting the status of the usb device on serial application
but problem is that when i am sending the data through the serial
application to the usb device system getting hang randomly.

I am sending the vendor request at passive level from the USB driver to USB
device. please do the needful because this issues is totally random.


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:>

Thanks Don Burn for suggestion. here I want to mention one more point, when i am debugging the driver code through the windbg then hanging issues comes very rarely.

Run with WinDbg but set no breakpoints, once the hang occurs break into the
debugger, and perform the o operation.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, April 12, 2017 1:19 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] System getting hang

Thanks Don Burn for suggestion. here I want to mention one more point, when
i am debugging the driver code through the windbg then hanging issues comes
very rarely.


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:>

Assertion failure - code c0000420 (first chance)
nt!KeSetCoalescableTimer+0x8de:
82c97bf4 cd2c int 2Ch

After putting the command kd> !process 0 7

**** NT ACTIVE PROCESS DUMP ****
NT symbols are incorrect, please fix symbols

After that putting .sympath command but still getting same issue

!process 0 7

**** NT ACTIVE PROCESS DUMP ****
NT symbols are incorrect, please fix symbols

Setup the Microsoft symbol server which will get you the correct symbols.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, April 12, 2017 2:06 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] System getting hang

Assertion failure - code c0000420 (first chance)
nt!KeSetCoalescableTimer+0x8de:
82c97bf4 cd2c int 2Ch

After putting the command kd> !process 0 7

NT ACTIVE PROCESS DUMP
NT symbols are incorrect, please fix symbols

After that putting .sympath command but still getting same issue

!process 0 7

NT ACTIVE PROCESS DUMP
NT symbols are incorrect, please fix symbols


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:>

.symfix
.reload

You may also want to try !stacks 2, it’s a bit easier to scan than looking
at the full !process output.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@windbg…

Assertion failure - code c0000420 (first chance)
nt!KeSetCoalescableTimer+0x8de:
82c97bf4 cd2c int 2Ch

After putting the command kd> !process 0 7

**** NT ACTIVE PROCESS DUMP ****
NT symbols are incorrect, please fix symbols

After that putting .sympath command but still getting same issue

!process 0 7

**** NT ACTIVE PROCESS DUMP ****
NT symbols are incorrect, please fix symbols

When Putting the !analyze -v command getting this response.

PROCESS_NAME: SerialApplication_

DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

DPC_TIME_LIMIT: 784

FAULTING_IP:
nt!KeAccumulateTicks+3c5
82c80bf4 cd2c int 2Ch

ERROR_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x133

CURRENT_IRQL: 1c

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

LAST_CONTROL_TRANSFER: from 82c800be to 82c80bf4

STACK_TEXT:
8dae2a18 82c800be 00026161 00000000 00018300 nt!KeAccumulateTicks+0x3c5
8dae2a58 82c7ff6b 8301a749 ab65f6a8 00000000 nt!KeUpdateRunTime+0x145
8dae2ab4 82c84c17 05000002 05000002 000000d1 nt!KeUpdateSystemTime+0x613
8dae2ab4 8301a749 05000002 05000002 000000d1 nt!KeUpdateSystemTimeAssist+0x13
8dae2b38 8b87e3db 87266818 86e85ee8 86785010 hal!KeAcquireSpinLockRaiseToSynch+0x39
8dae2b4c 8b83a5b9 8dae2b78 86e85ee8 86785010 Wdf01000!FxCallbackSpinLock::Lock+0x56
8dae2b7c 8b83a241 7917a110 8dae2bc4 86e85ee8 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x30d
8dae2b9c 8b83d9da 86785000 00000000 86785010 Wdf01000!FxIoQueue::DispatchEvents+0x4af
8dae2bbc 8b83b96c 86785000 86e85ee8 8781272c Wdf01000!FxIoQueue::QueueRequest+0x204
8dae2bf0 8b835bc2 872112c8 86ab9670 872112c8 Wdf01000!FxPkgIo::Dispatch+0x3ba
8dae2c18 8b835a33 00ab9670 872112c8 872c4e30 Wdf01000!FxDevice::Dispatch+0x155
8dae2c34 82c3c593 86ab9670 872112c8 872112c8 Wdf01000!FxDevice::DispatchWithLock+0x77
8dae2c4c 82e3099f 872c4e30 872112c8 87211380 nt!IofCallDriver+0x63
8dae2c6c 82e76619 86ab9670 872c4e30 00000001 nt!IopSynchronousServiceTail+0x1f8
8dae2d08 82c431ea 86ab9670 000001fc 00000000 nt!NtWriteFile+0x6e8
8dae2d08 776270b4 86ab9670 000001fc 00000000 nt!KiFastCallEntry+0x12a
002ef534 77626a74 75899788 00000204 000001fc ntdll!KiFastSystemCallRet
002ef538 75899788 00000204 000001fc 00000000 ntdll!NtWriteFile+0xc
002ef59c 7705144e 00000204 004f63f8 000001f7 KERNELBASE!WriteFile+0xaa
002ef5b8 00f784a1 00000204 004f63f8 000001f7 kernel32!WriteFileImplementation+0x76
WARNING: Stack unwind information not available. Following frames may be wrong.
002ef5f0 00f7892a 00527c80 000001f7 14937edf SerialApplication+0x84a1
002ef620 00f73857 00506a60 14937ebb 005177b0 SerialApplication+0x892a
002ef644 00f7de1b 00527888 14937e77 7fffffff SerialApplication+0x3857
002ef688 00f8dace 00000003 14937fab 005177b0 SerialApplication+0xde1b
002ef754 00f8ef35 00000113 00000003 00000000 SerialApplication+0x1dace
002ef778 00f89d07 00000113 00000003 00000000 SerialApplication+0x1ef35
002ef7ec 00f8a4c4 005177b0 00030358 00000113 SerialApplication+0x19d07
002ef80c 75c0c4e7 00030358 00000113 00000003 SerialApplication+0x1a4c4
002ef838 75c0c5e7 00f8a490 00030358 00000113 USER32!InternalCallWinProc+0x23
002ef8b0 75c0cc19 00000000 00f8a490 00030358 USER32!UserCallWinProcCheckWow+0x14b
002ef910 75c0cc70 00f8a490 00000000 002ef950 USER32!DispatchMessageWorker+0x35e
002ef920 00fb546a 004d7460 0117d810 00fb58f5 USER32!DispatchMessageW+0xf
002ef950 01102fdb 00000000 0117d968 7ffd3000 SerialApplication+0x4546a
002ef968 010e1e50 00f70000 00000000 004917f2 SerialApplication+0x192fdb
002ef9b4 77053c45 7ffd3000 002efa00 776437f5 SerialApplication+0x171e50
002ef9c0 776437f5 7ffd3000 7751347f 00000000 kernel32!BaseThreadInitThunk+0xe
002efa00 776437c8 010e1ec2 7ffd3000 00000000 ntdll!__RtlUserThreadStart+0x70
002efa18 00000000 010e1ec2 7ffd3000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxCallbackSpinLock::Lock+56
8b87e3db 8b4d08 mov ecx,dword ptr [ebp+8]

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: Wdf01000!FxCallbackSpinLock::Lock+56

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5010ac41

FAILURE_BUCKET_ID: 0x133_Wdf01000!FxCallbackSpinLock::Lock+56

BUCKET_ID: 0x133_Wdf01000!FxCallbackSpinLock::Lock+56

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x133_wdf01000!fxcallbackspinlock::lock+56

FAILURE_ID_HASH: {289c15d2-3c95-e469-692b-72f93cd10532}

Followup: MachineOwner

The Framework is spinning on a spinlock that isn’t getting released. Check
the other processors with !running -it

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@windbg…

When Putting the !analyze -v command getting this response.

PROCESS_NAME: SerialApplication_

DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

DPC_TIME_LIMIT: 784

FAULTING_IP:
nt!KeAccumulateTicks+3c5
82c80bf4 cd2c int 2Ch

ERROR_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x133

CURRENT_IRQL: 1c

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

LAST_CONTROL_TRANSFER: from 82c800be to 82c80bf4

STACK_TEXT:
8dae2a18 82c800be 00026161 00000000 00018300 nt!KeAccumulateTicks+0x3c5
8dae2a58 82c7ff6b 8301a749 ab65f6a8 00000000 nt!KeUpdateRunTime+0x145
8dae2ab4 82c84c17 05000002 05000002 000000d1 nt!KeUpdateSystemTime+0x613
8dae2ab4 8301a749 05000002 05000002 000000d1
nt!KeUpdateSystemTimeAssist+0x13
8dae2b38 8b87e3db 87266818 86e85ee8 86785010
hal!KeAcquireSpinLockRaiseToSynch+0x39
8dae2b4c 8b83a5b9 8dae2b78 86e85ee8 86785010
Wdf01000!FxCallbackSpinLock::Lock+0x56
8dae2b7c 8b83a241 7917a110 8dae2bc4 86e85ee8
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x30d
8dae2b9c 8b83d9da 86785000 00000000 86785010
Wdf01000!FxIoQueue::DispatchEvents+0x4af
8dae2bbc 8b83b96c 86785000 86e85ee8 8781272c
Wdf01000!FxIoQueue::QueueRequest+0x204
8dae2bf0 8b835bc2 872112c8 86ab9670 872112c8
Wdf01000!FxPkgIo::Dispatch+0x3ba
8dae2c18 8b835a33 00ab9670 872112c8 872c4e30
Wdf01000!FxDevice::Dispatch+0x155
8dae2c34 82c3c593 86ab9670 872112c8 872112c8
Wdf01000!FxDevice::DispatchWithLock+0x77
8dae2c4c 82e3099f 872c4e30 872112c8 87211380 nt!IofCallDriver+0x63
8dae2c6c 82e76619 86ab9670 872c4e30 00000001
nt!IopSynchronousServiceTail+0x1f8
8dae2d08 82c431ea 86ab9670 000001fc 00000000 nt!NtWriteFile+0x6e8
8dae2d08 776270b4 86ab9670 000001fc 00000000 nt!KiFastCallEntry+0x12a
002ef534 77626a74 75899788 00000204 000001fc ntdll!KiFastSystemCallRet
002ef538 75899788 00000204 000001fc 00000000 ntdll!NtWriteFile+0xc
002ef59c 7705144e 00000204 004f63f8 000001f7 KERNELBASE!WriteFile+0xaa
002ef5b8 00f784a1 00000204 004f63f8 000001f7
kernel32!WriteFileImplementation+0x76
WARNING: Stack unwind information not available. Following frames may be
wrong.
002ef5f0 00f7892a 00527c80 000001f7 14937edf SerialApplication+0x84a1
002ef620 00f73857 00506a60 14937ebb 005177b0 SerialApplication+0x892a
002ef644 00f7de1b 00527888 14937e77 7fffffff SerialApplication+0x3857
002ef688 00f8dace 00000003 14937fab 005177b0 SerialApplication+0xde1b
002ef754 00f8ef35 00000113 00000003 00000000 SerialApplication+0x1dace
002ef778 00f89d07 00000113 00000003 00000000 SerialApplication+0x1ef35
002ef7ec 00f8a4c4 005177b0 00030358 00000113 SerialApplication+0x19d07
002ef80c 75c0c4e7 00030358 00000113 00000003 SerialApplication+0x1a4c4
002ef838 75c0c5e7 00f8a490 00030358 00000113 USER32!InternalCallWinProc+0x23
002ef8b0 75c0cc19 00000000 00f8a490 00030358
USER32!UserCallWinProcCheckWow+0x14b
002ef910 75c0cc70 00f8a490 00000000 002ef950
USER32!DispatchMessageWorker+0x35e
002ef920 00fb546a 004d7460 0117d810 00fb58f5 USER32!DispatchMessageW+0xf
002ef950 01102fdb 00000000 0117d968 7ffd3000 SerialApplication+0x4546a
002ef968 010e1e50 00f70000 00000000 004917f2 SerialApplication+0x192fdb
002ef9b4 77053c45 7ffd3000 002efa00 776437f5 SerialApplication+0x171e50
002ef9c0 776437f5 7ffd3000 7751347f 00000000
kernel32!BaseThreadInitThunk+0xe
002efa00 776437c8 010e1ec2 7ffd3000 00000000 ntdll!__RtlUserThreadStart+0x70
002efa18 00000000 010e1ec2 7ffd3000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxCallbackSpinLock::Lock+56
8b87e3db 8b4d08 mov ecx,dword ptr [ebp+8]

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: Wdf01000!FxCallbackSpinLock::Lock+56

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5010ac41

FAILURE_BUCKET_ID: 0x133_Wdf01000!FxCallbackSpinLock::Lock+56

BUCKET_ID: 0x133_Wdf01000!FxCallbackSpinLock::Lock+56

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x133_wdf01000!fxcallbackspinlock::lock+56

FAILURE_ID_HASH: {289c15d2-3c95-e469-692b-72f93cd10532}

Followup: MachineOwner

I am sending synchronously an IOCTL from the virtual com port to usb driver at dispatch level. I have read the document where mention that synchronous ioctl send at passive level.

case IOCTL_SERIAL_GET_MODEMSTATUS:
.
.
.
.
.

WDF_REQUEST_SEND_OPTIONS_INIT(&SendOptions,
WDF_REQUEST_SEND_OPTION_SYNCHRONOUS);

WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&SendOptions,
WDF_REL_TIMEOUT_IN_SEC(60));

Status = WdfRequestAllocateTimer(IoctlRequest);
if (!NT_SUCCESS(Status)) {

goto TestReadWriteEnd;
}

if (!WdfRequestSend(IoctlRequest,UsbTarget, &SendOptions)) {

Status = WdfRequestGetStatus(IoctlRequest);
}

break;

How I can send this IOCTL at passive level my com port IOCTL at dispatch level ?

I have tried to set the serial IOCTL IRQL passive level with the help of attributes but after that window does not load the com port driver and showing yellow marking in device manager.

xxxxx@gmail.com wrote:

I am sending synchronously an IOCTL from the virtual com port to usb driver at dispatch level. I have read the document where mention that synchronous ioctl send at passive level.

This is not really the right mailing list for this question. It would
be better on [ntdev].

case IOCTL_SERIAL_GET_MODEMSTATUS:

Are you quite sure your ioctl handler is not running at passive level?
Do you know WHY it is not?

WDF_REQUEST_SEND_OPTIONS_INIT(&SendOptions,
WDF_REQUEST_SEND_OPTION_SYNCHRONOUS);

WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&SendOptions,
WDF_REL_TIMEOUT_IN_SEC(60));

Status = WdfRequestAllocateTimer(IoctlRequest);
if (!NT_SUCCESS(Status)) {

goto TestReadWriteEnd;
}

Why use the dreaded “goto”? Why not just “break”?


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

xxxxx@gmail.com wrote:

I have tried to set the serial IOCTL IRQL passive level with the help of attributes but after that window does not load the com port driver and showing yellow marking in device manager.

How, exactly, did you do that?


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

Thanks Tim for Reply.

I have tried to set the serial IOCTL IRQL passive level with the help of
attributes but after that window does not load the com port driver and showing
yellow marking in device manager.

How, exactly, did you do that?

WDF_OBJECT_ATTRIBUTES attributes;

WDF_OBJECT_ATTRIBUTES_INIT(&attributes);

attributes.ParentObject = Device;

attributes.ExecutionLevel = WdfExecutionLevelPassive;

WDF_IO_QUEUE_CONFIG_INIT(&queueConfig, WdfIoQueueDispatchSequential);
queueConfig.EvtIoDeviceControl = EvtIoControl;
status = WdfIoQueueCreate( Device,
&queueConfig,
&attributes,
&deviceContext->IoctlQueue
);
if (!NT_SUCCESS(status)) {
KdPrint((DRIVERNAME"Failed with Status 0x%x<-------------------\n", status));
return status;
}
status = WdfDeviceConfigureRequestDispatching(Device, deviceContext->IoctlQueue, WdfRequestTypeDeviceControl);

if (!NT_SUCCESS(status))
{
KdPrint((DRIVERNAME" failed 0x%x\n", status));
return status;
}