So I have been doing this dance for about a month now. A friend is loaning me his Wi-Fi dongle and it worked great. But sadly my joy ended when the disconnected again. Viola after that it acted though it was going to really work this time. At this point I knew I would have to do the dreaded cold boot. Then it would stop but this time there was a yellow construction symbol. Then I got tired of rebooting every time it disconnected.so I started going to Device Mange, disabling the Ralink, then enabling it and it would work.for a while. When it first start happening I would just reboot the computer and it would work.for a while. In the system tray it shows the Wi-fi icon and it works for say 10 hours then it disconnects. I have been dealing with this problem for a few months. That IRP is now stuck as a result.Tonight I finally have confirmation that my Ralink RT5390 802.11 b/g/n Wi-Fi Adapter is not bad. The issue may be that this driver unloaded itself before the surprise remove irp was properly handled. That device belongs to driver \Driver\WDM1623 - which I believe is cp1623_miniport.sys, which Verifier shows as already loaded andįffffa8002440f30 Loaded&Unloaded 00000000 00000000 cp1623_miniport.sys The IRP associated with that thread is also showing it's a Surprise_remove IRP, with fffffa8006c3d050 as the target. Once you find why that event was never signaled and get it to be signaled, you'll know why this is stuck. Whatever is supposed to signal that event did not, so 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. 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. PnpTriage dumped out the two threads in question - the first thread it dumped, fffffa8002558040, is currently waiting for the nt!PiEngineLock (0xfffff80002258c40) object. Memory dump file: MEMORY.zip (I created a manually initiated BSD after the PNP test hangs) WinDBG output with analysis: PNP_Driver_Test_WinDBG_Output.txt Output from the test: PNP_Driver_Test_DOS_Box_Output.txt WDTF_PNP:Result: TestSurpriseRemove operation timed out. The tests hangs with following output in the DOS box window: The Plug and Play Driver Test with our Adapter is passed under Windows 7 and fails under Windows Vista. Part of the required tests is the Plug and Play Driver Test. We are testing our NDIS 6.0 Miniport PCIx-Adapter (called CP1623) with WHCK.
0 kommentar(er)
