none
Plug and Play Driver Test Certification Failed in Vista RRS feed

  • Question


  • I am not sure if this case is the same issue as

    http://social.msdn.microsoft.com/Forums/en-US/whck/thread/b1959475-8593-4adb-8e8f-2505b15a1fac

    because there is no task error (it cannot be selected).

    In my case, I saw client computer on which test USB device is hang in the command line windows and the command line windows show

    WDTF_PNP: - EDTSurpriseReniveDevice()

    WDTF_PNP:   Target: Quanta Mobile Broadband RmNet Adapter_USB\VID_0408&PID_EA49&MI_02\6&65CC21F&0&0002

    WDTF_PNP: Result: TestSurpriseRemove operation timeout...

    The command line window will exist until the test is over 10 hours and the Windows will show blue screen after that.

    There is some message I saw from debugview:

    00007631 3106.44458008   Blake testing IRP_MJ_PNP
    00007632 3106.44458008   Blake testing IRP_MJ_PNP,irpStack->MinorFunction=23
    00007639 3106.48803711   Blake testing IRP_MJ_PNP
    00007640 3106.48803711   Blake testing IRP_MJ_PNP,irpStack->MinorFunction=23
    00007648 3106.50000000   Blake testing IRP_MJ_PNP
    00007649 3106.50000000   Blake testing IRP_MJ_PNP,irpStack->MinorFunction=1
    00007653 3106.50000000   Blake testing IRP_MJ_PNP
    00007654 3106.50000000   Blake testing IRP_MJ_PNP,irpStack->MinorFunction=2
    00007663 3106.50195313 <qnet0001> MPFreeAdapter: ST [1, 0, 0, 0, 0, 0, 0, 0]
    00007664 3106.50195313 <qnet0001> <-- MPFreeAdapter
    00007665 3106.50195313 <qnet0001> <--- MPHalt
    00007666 3306.43408203 MSDMFilt: IoctlList is empty

    I don't understand why there is a message "00007666 3306.43408203 MSDMFilt: IoctlList is empty "

    Does anyone have some idea about it?

    Thanks a lot.

    Wednesday, December 26, 2012 5:21 AM

Answers

  • We are hitting a similar issue on this job for network driver whql test .Details referring to https://bugzilla.redhat.com/show_bug.cgi?id=834230 . We can Manual Errata #1019 to workaound it


    Best Regards, Mike

    • Marked as answer by Blake.Chen Wednesday, January 2, 2013 2:33 AM
    Wednesday, December 26, 2012 8:11 AM
  • Since 1) we have a PNP thread that's stuck (for over 2 hours per tick count above) in ndis!ndisPnPDispatch() and 2) this is on Windows Vista (or Windows XP), you qualify for manual errata #1019. Please refer to this manual errata in a ReadMe file with your submission, and the failure will get overturned manually by our submission reviewers. Thanks.

    For others, the following are the complete conditions for manual errata #1019 to apply:

    1. Test OS is Windows Vista or Windows XP (or their server equivalents)

    2. "Plug and Play Driver Test" is the test that fails. It fails with no logs after being stuck for a very long time. (HCK automatically cancels the stuck test after several hours and no logs get copied back).

    3. !pnptriage output shows that there is a thread with "ndis!ndisPnPDispatch" on the stack, and this thread has a very high tick count (appx. equal to the time the test was stuck).


    This posting is provided AS IS with no warranties, and confers no rights.



    Friday, December 28, 2012 9:24 PM
  • Hello Blake 

    It is a manual Errata i don't think you can find it in http://msdn.microsoft.com/en-us/windows/hardware/hh852367.aspx 

    you need to add a readme file when making submission package .template referring to 

    http://download.microsoft.com/download/4/C/3/4C34C72F-FD65-41C9-B89A-A0858A2C3562/windows-hardware-dashboard-submission-readme.docx

    d


    Best Regards, Mike

    • Marked as answer by Blake.Chen Monday, January 7, 2013 3:36 AM
    Sunday, January 6, 2013 6:29 AM

All replies

  • We are hitting a similar issue on this job for network driver whql test .Details referring to https://bugzilla.redhat.com/show_bug.cgi?id=834230 . We can Manual Errata #1019 to workaound it


    Best Regards, Mike

    • Marked as answer by Blake.Chen Wednesday, January 2, 2013 2:33 AM
    Wednesday, December 26, 2012 8:11 AM
  • Please see "Problem: Test is unresponsive or not running" section on our troubleshooting page:

    http://msdn.microsoft.com/en-us/library/windows/hardware/hh949802(v=vs.85).aspx

    !pnptriage may help identify any threads that are stuck while processing PNP IRPs.


    This posting is provided AS IS with no warranties, and confers no rights.

    Wednesday, December 26, 2012 7:51 PM
  • Manual Errata 1019 is only applicable when testing network drivers on Windows Vista & Windows XP (and their Server equivalents).


    This posting is provided AS IS with no warranties, and confers no rights.

    Wednesday, December 26, 2012 7:52 PM
  • Hi Mike,

    Thanks for your reply.

    I am a little confused about errata #1019.

    In the web page,  it mentioned that we have to add the readme form with 1019 to get the log, but how can we know errata #1019 really cover the issue?

    I mean, there must some way to set the errata #1019 and we can pass the test, right?

    I am downloading the HCKFilterUpdates.cab from the website:

    http://msdn.microsoft.com/en-us/windows/hardware/hh852367.aspx

    If I pass the test, do I need to fill the readme form?

    Thanks a lot.

    Thursday, December 27, 2012 2:27 AM
  • Hi Srepaka,

    Yes, I am testing the network driver in Vista.

    I am wondering how to using "Manual Errata 1019" because there is still the same problem after I download the filter from http://msdn.microsoft.com/en-us/windows/hardware/hh852367.aspx, follow the steps and run the UpdateFilter.exe.

    Thanks a lot.

    Thursday, December 27, 2012 3:03 AM
  • Can you reply with !pnptriage output from when the test stops making progress? I can look at the output and tell you if errata 1019 applies in your case. Thanks.

    This posting is provided AS IS with no warranties, and confers no rights.

    Thursday, December 27, 2012 3:39 AM
  • Can you reply with !pnptriage output from when the test stops making progress? I can look at the output and tell you if errata 1019 applies in your case. Thanks.

    This posting is provided AS IS with no warranties, and confers no rights.

    Do you mean I have to have another computer to be kernel debugger which is mentioned in http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx ?

    Does kernel debugger means WinDBG?

    Many thanks for your help.

    Thursday, December 27, 2012 3:54 AM
  • Hi Srepaka,

    I am using windbg to do the kernel debug and I am not sure if I am doing the right steps.

    Here are the log of  !pnptriage.  Many thanks for your help.

    1: kd> !pnptriage

    ********************************************************************************
    Dumping PnP DeviceAction Queue @ 0x81d84510
    ********************************************************************************

    Cannot find nt!_PNP_DEVICE_ACTION_ENTRY type.
    Dumping PnP DeviceEvent Queue @ 0x84712a68
    List = 0xab448008, 0xa8f23c38

    Dumping DeviceEventEntry @ 0xab448008
      ListEntry = 0xab40c008, 0x84712aac, Argument = 0x00000000
      CallerEvent = 0x00000000, Callback = 0x00000000, Context = 0x00000000
      VetoType = 0x00000000, VetoName = 0x00000000

      Dumping PlugPlayEventBlock @ 0xAB448028
        EventGuid = GUID_DEVICE_INTERFACE_REMOVAL
        Category = DeviceClassChangeEvent
        Result = 0x00000000, Flags = 0x00000000, TotalSize = 316
        DeviceObject = 0x00000000
          ClassGuid = AD498944-762F-11D0-8DCB-00C04FC3358C
          SymbolicLinkName = \??\USB#VID_0408&PID_EA49&MI_02#6&45567d2&0&0002#{ad498944-762f-11d0-8dcb-00c04fc3358c}\{A5130BE3-44C7-4967-9C3E-773A8B8D4F1C}

    Dumping DeviceEventEntry @ 0xab40c008
      ListEntry = 0xa5882c48, 0xab448008, Argument = 0x00000000
      CallerEvent = 0x00000000, Callback = 0x00000000, Context = 0x00000000
      VetoType = 0x00000000, VetoName = 0x00000000

      Dumping PlugPlayEventBlock @ 0xAB40C028
        EventGuid = GUID_DEVICE_INTERFACE_REMOVAL
        Category = DeviceClassChangeEvent
        Result = 0x00000000, Flags = 0x00000000, TotalSize = 238
        DeviceObject = 0x00000000
          ClassGuid = CAC88484-7515-4C03-82E6-71A87ABAC361
          SymbolicLinkName = \??\USB#VID_0408&PID_EA49&MI_02#6&45567d2&0&0002#{cac88484-7515-4c03-82e6-71a87abac361}

    Dumping DeviceEventEntry @ 0xa5882c48
      ListEntry = 0xa8f23c38, 0xab40c008, Argument = 0x00000000
      CallerEvent = 0x9fb10c4c, Callback = 0x00000000, Context = 0x00000000
      VetoType = 0x89115bcc, VetoName = 0x9fb10c3c

      Dumping PlugPlayEventBlock @ 0xA5882C68
        EventGuid = GUID_DEVICE_QUERY_AND_REMOVE
        Category = TargetDeviceChangeEvent
        Result = 0x9fb10c64, Flags = 0x00000002, TotalSize = 100
        DeviceObject = 0x8929bce0
          DeviceId:
    䀎쬺䛰ᇐ辰怀᎗㼅

    Dumping DeviceEventEntry @ 0xa8f23c38
      ListEntry = 0x84712aac, 0xa5882c48, Argument = 0x00000000
      CallerEvent = 0xad1a3c4c, Callback = 0x00000000, Context = 0x00000000
      VetoType = 0xaa29aa9c, VetoName = 0xad1a3c3c

      Dumping PlugPlayEventBlock @ 0xA8F23C58
        EventGuid = GUID_DEVICE_QUERY_AND_REMOVE
        Category = TargetDeviceChangeEvent
        Result = 0xad1a3c64, Flags = 0x00000000, TotalSize = 154
        DeviceObject = 0x9492a530
          DeviceId:
    䀎쬺䛰ᇐ辰怀᎗㼅

      Total events in the list: 4

    ********************************************************************************
    Dumping PnP DeviceCompletion Queue @ 0x81d864c0
    ********************************************************************************

    0 Pnp operation(s) dispatched (IRP pending) currently.

    Dumping pending asynchronous request list...
    Cannot find nt!_PNP_DEVICE_COMPLETION_REQUEST type.

    Dumping completed asynchronous request list...
    Cannot find nt!_PNP_DEVICE_COMPLETION_REQUEST type.

    ********************************************************************************
    Dumping devnodes with problems...
    ********************************************************************************

    Dumping IopRootDeviceNode (= 0x8476c170)

    ********************************************************************************
    Dumping PnP locks...
    ********************************************************************************


    Resource @ nt!PiEngineLock (0x81d86600)    Exclusively owned
        Contention Count = 67
         Threads: 84762828-01<*> 
    1 total locks, 1 locks currently held

    Resource @ nt!IopDeviceTreeLock (0x81d86680)    Shared 1 owning threads
        Contention Count = 1
         Threads: 84762828-01<*> 
    1 total locks, 1 locks currently held

    Resource @ nt!PnpRegistryDeviceResource (0x81d86520)    Available
        Contention Count = 2419
    1 total locks

    ********************************************************************************
    If one or more of above are NOT available, do !thread on the owner thread to find the thread hung in PnP
    ********************************************************************************


    ********************************************************************************
    Dumping currently active PnP thread (if any)...
    ********************************************************************************

    Dumping device action thread...

    00000000: Unable to get thread contents
    Dumping device event thread...

    THREAD 84762828  Cid 0004.0038  Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
        85bd3a5c  NotificationEvent
    IRP List:
        abce6e70: (0006,0190) Flags: 00000000  Mdl: 00000000
    Not impersonating
    DeviceMap                 85807ec0
    Owning Process            84716910       Image:         System
    Attached Process          N/A            Image:         N/A
    Wait Start TickCount      202567         Ticks: 638894 (0:02:46:06.810)
    Context Switch Count      10600          IdealProcessor: 0             
    UserTime                  00:00:00.000
    KernelTime                00:00:01.294
    Win32 Start Address nt!ExpWorkerThread (0x81cf7d25)
    Stack Init 85bd4000 Current 85bd3948 Base 85bd4000 Limit 85bd1000 Call 0
    Priority 13 BasePriority 12 PriorityDecrement 0 IoPriority 2 PagePriority 5
    ChildEBP RetAddr  Args to Child              
    85bd3960 81cfe372 84762828 847628b0 81d5413c nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
    85bd39a4 81c99f38 84762828 00000000 00000000 nt!KiSwapThread+0x44f
    85bd39f8 81f422c1 85bd3a5c 00000000 00000000 nt!KeWaitForSingleObject+0x492
    85bd3a24 849517e1 85bd3a5c 00000000 00000000 nt!VerifierKeWaitForSingleObject+0x8d
    85bd3a84 81f356be 80ddd380 abce6e70 886866e8 ndis!ndisPnPDispatch+0x8f0 (FPO: [Non-Fpo])
    85bd3aa8 81c9692d abce6fdc abce6e70 80ddd380 nt!IovCallDriver+0x23f
    85bd3abc a11ad58d abce6e70 85bd3aec a11aefcf nt!IofCallDriver+0x1b
    85bd3ac8 a11aefcf 886866e8 abce6e70 abce6e70 MSDMFilt!FilterPassIrp+0x2d (FPO: [Non-Fpo])
    85bd3aec a11ae310 886866e8 abce6e70 9df7b0e0 MSDMFilt!FilterSurpriseRemove+0x5d (FPO: [2,1,4])
    85bd3b08 81f356be 886866e8 abce6e70 abce7000 MSDMFilt!FilterDispatchPnp+0x9a (FPO: [Non-Fpo])
    85bd3b2c 81c9692d abce6fdc 85bd3bcc 886866e8 nt!IovCallDriver+0x23f
    85bd3b40 81e00a43 9492a530 9492a530 94928758 nt!IofCallDriver+0x1b
    85bd3b74 81ecb08f 9492a530 85bd3ba8 00000000 nt!IopSynchronousCall+0xce
    85bd3bd0 81ec4717 9492a530 00000017 aa2e35c8 nt!IopRemoveDevice+0xd1
    85bd3bfc 81ec45d4 00000308 00000000 9492a870 nt!PnpSurpriseRemoveLockedDeviceNode+0xc4
    85bd3c10 81ec488f 00000003 00000000 00000000 nt!PnpDeleteLockedDeviceNode+0x20
    85bd3c44 81ec8327 9492a530 aa2e35c8 00000003 nt!PnpDeleteLockedDeviceNodes+0x4c
    85bd3d04 81db8991 85bd3d34 00000000 aa3e7578 nt!PnpProcessQueryRemoveAndEject+0x594
    85bd3d1c 81de4493 00000000 81d5413c 84762828 nt!PnpProcessTargetDeviceEvent+0x38
    85bd3d44 81cf7e22 a2a350c0 00000000 84762828 nt!PnpDeviceEventWorker+0x201
    85bd3d7c 81e27f7a a2a350c0 40f7495e 00000000 nt!ExpWorkerThread+0xfd
    85bd3dc0 81c90efe 81cf7d25 00000001 00000000 nt!PspSystemThreadStartup+0x9d
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

    Friday, December 28, 2012 2:48 PM
  • Since 1) we have a PNP thread that's stuck (for over 2 hours per tick count above) in ndis!ndisPnPDispatch() and 2) this is on Windows Vista (or Windows XP), you qualify for manual errata #1019. Please refer to this manual errata in a ReadMe file with your submission, and the failure will get overturned manually by our submission reviewers. Thanks.

    For others, the following are the complete conditions for manual errata #1019 to apply:

    1. Test OS is Windows Vista or Windows XP (or their server equivalents)

    2. "Plug and Play Driver Test" is the test that fails. It fails with no logs after being stuck for a very long time. (HCK automatically cancels the stuck test after several hours and no logs get copied back).

    3. !pnptriage output shows that there is a thread with "ndis!ndisPnPDispatch" on the stack, and this thread has a very high tick count (appx. equal to the time the test was stuck).


    This posting is provided AS IS with no warranties, and confers no rights.



    Friday, December 28, 2012 9:24 PM
  • Since 1) we have a PNP thread that's stuck (for over 2 hours per tick count above) in ndis!ndisPnPDispatch() 



    Hi Spepaka,

    I appreciate your help!

    For one more question, how can I know that PNP thread is stuck in ndis!ndisPnPDispatch?

    Is there any document about how to analyze !pnptriage log?

    Thanks for your help.

    Blake

    Wednesday, January 2, 2013 1:45 AM
  • Hello Blake 

    It is a manual Errata i don't think you can find it in http://msdn.microsoft.com/en-us/windows/hardware/hh852367.aspx 

    you need to add a readme file when making submission package .template referring to 

    http://download.microsoft.com/download/4/C/3/4C34C72F-FD65-41C9-B89A-A0858A2C3562/windows-hardware-dashboard-submission-readme.docx

    d


    Best Regards, Mike

    • Marked as answer by Blake.Chen Monday, January 7, 2013 3:36 AM
    Sunday, January 6, 2013 6:29 AM