Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


System getting hang

pritosh_mishrapritosh_mishra Member Posts: 38
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.

Comments

  • Don_BurnDon_Burn Member - All Emails Posts: 1,711
    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: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    Sent: Wednesday, April 12, 2017 12:54 PM
    To: Kernel Debugging Interest List <[email protected]>
    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://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer&gt;
  • pritosh_mishrapritosh_mishra Member Posts: 38
    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.
  • Don_BurnDon_Burn Member - All Emails Posts: 1,711
    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: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    Sent: Wednesday, April 12, 2017 1:19 PM
    To: Kernel Debugging Interest List <[email protected]>
    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://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer&gt;
  • pritosh_mishrapritosh_mishra Member Posts: 38
    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
  • Don_BurnDon_Burn Member - All Emails Posts: 1,711
    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: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    Sent: Wednesday, April 12, 2017 2:06 PM
    To: Kernel Debugging Interest List <[email protected]>
    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://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer&gt;
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,352
    .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:[email protected]

    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

    -scott
    OSR

  • pritosh_mishrapritosh_mishra Member Posts: 38
    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
    ---------
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,352
    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:[email protected]

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

    -scott
    OSR

  • pritosh_mishrapritosh_mishra Member Posts: 38
    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 ?
  • pritosh_mishrapritosh_mishra Member Posts: 38
    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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,629
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,629
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • pritosh_mishrapritosh_mishra Member Posts: 38
    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;
    }
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE