none
WHCK NDIS Miniport Adapter Test, Plug and Play Driver Test, TestSurpriseRemove operation timed out RRS feed

All replies

  • Based on what I see:

    PnpTriage dumped out the two threads in question - the first thread it dumped, fffffa8002558040, is currently waiting for the nt!PiEngineLock (0xfffff80002258c40) object.

    The output shows that thread fffffa8002557bb0 currently owns that lock, but that thread is currently waiting for something else - difficult to see what it might be waiting for because of how the symbols resolved ndis in your output, though. 

    The first argument is to KeWaitForSingleObject is fffffa60'017bc7a0 - it's an event allocated by the ndis call that is being waited on - presumably some other operation is supposed to signal it.  Whatever is supposed to signal that event did not, so once you find why that event was never signaled and get it to be signaled, you'll know why this is stuck.

    The IRP associated with that thread is also showing it's a Surprise_remove IRP, with fffffa8006c3d050 as the target.  That device belongs to driver \Driver\WDM1623 - which I believe is cp1623_miniport.sys, which Verifier shows as already loaded and unloaded (in the "!verifier 1" output)

    fffffa8002440f30 Loaded&Unloaded  00000000       00000000    cp1623_miniport.sys

    The issue may be that this driver unloaded itself before the surprise remove irp was properly handled.  That IRP is now stuck as a result.  Perhaps when ndis!ndisPnPRemoveDevice was called, it did not signal the event?  Or it's stuck because the ref count is not yet 0?

    Thursday, May 16, 2013 6:53 AM
  • Hello Michael

    thanks a lot for your quick response.

    It seems, that this is a bug of the NDIS Test.

    I found, that after initiating a BSD manually and rebooting the system the test result was green unexpectedly.

    After carefully reading of the result file I found, that the following filter was applied:

    Filter 1019:
    Expires: 12/01/2014 07:00:00
    Issue Description: Plug and Play Driver test and CHAOS test may hang or encounter a 9F bugcheck on pre-Windows 7 OS versions.
    NDIS.sys may block on surprise_removal of a networking Miniport or IM/MUX driver if there are user mode handles open.
    This goes against WDM behavior and has been fixed in Windows 7 and later operating system.
    Issue Resolution: The failure will be filtered until the issue is fixed.


    It looks like, as when the test is stuck with the
    "Result:   TestSurpriseRemove operation timed out.."
    and you simply reboot the system, then the test is failed.

    Greetings from Germany,

    Carsten

    Thursday, May 16, 2013 6:18 PM