daynix / UsbDk

Usb Drivers Development Kit for Windows
Apache License 2.0
554 stars 142 forks source link

BSoD When a huawei phone plugged in. #59

Closed xuyongjian closed 6 years ago

xuyongjian commented 6 years ago

A BSoD occurred when I plugged in a huawei phone. It's about an 80 percent probability that happened. Log attached below. UsbDkTrace.zip I traced the code and it seemed that phone was recognized as a hub due to an error when requesting the phone's Device descriptor. Any help will be greatly appreciated!

sameehj commented 6 years ago

Hi @xuyongjian ,

Thanks for reporting this issue, can you please provide me with the UsbDk version used so I can pasre the logs that are attached?

Thanks!

xuyongjian commented 6 years ago

1.0.19

sameehj commented 6 years ago

I have just noticed that the device that you are trying to redirect is actually composite device. UsbDk currently doesn't support composite devices and there are no plans to support composite devices for the near future. However the BSOD shouldn't occur, so let's try to understand why is it happening. Can you please send me the dump file that was generated by Windows, it usually resides under c:\windows\memory.dmp

Here are the parsed logs from UsbDkTrace_bluescreen.etl:

[1]0004.0038::05/04/2018-05:29:50.281 [UsbDk]::operator() Starting relations array processing:

[1]0004.0038::05/04/2018-05:29:50.281 [UsbDk]CDeviceRelations::Dump Array size: 1 (ptr: 882EAFD8) [1]0004.0038::05/04/2018-05:29:50.281 [UsbDk]::operator() #0: 8859D7A8 [0]0004.0038::05/04/2018-05:29:50.282 [UsbDk]CUsbDkHubFilterStrategy::RegisterNewChild Registering new child (PDO: 8859D7A8): [0]0004.0038::05/04/2018-05:29:50.282 [UsbDk]CRegText::Dump ID: USB\VID_12D1&PID_107E [0]0004.0038::05/04/2018-05:29:50.282 [UsbDk]CRegText::Dump ID: FFKGK17720000107 [0]0004.0038::05/04/2018-05:29:50.284 [UsbDk]CUsbDkHubFilterStrategy::ApplyRedirectionPolicy Not attaching to device stack for 0x8859D7A8 [0]0004.0038::05/04/2018-05:29:50.284 [UsbDk]::operator() Finished relations array processing [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]UsbDkEvtDeviceAdd Entry [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]CUsbDkFilterDevice::Create Entry [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]CWdfDevice::CacheDeviceName Newly created device name is \Device\UsbDkFilter6 [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]CRegText::Dump ID: USB\VID_12D1&PID_107E [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]CUsbDkFilterDevice::CStrategist::SelectStrategy Do not redirect or already redirected device, no strategy assigned [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]CUsbDkFilterDevice::DefineStrategy Not attached [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]UsbDkEvtDeviceAdd Exit 0xc00000bb(STATUS_NOT_SUPPORTED) [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]CUsbDkFilterDevice::ContextCleanup Entry [0]0004.0038::05/04/2018-05:29:50.287 [UsbDk]CWdfDevice::~CWdfDevice Deleting device \Device\UsbDkFilter6 [3]0004.0038::05/04/2018-05:29:50.339 [UsbDk]UsbDkEvtDeviceAdd Entry [3]0004.0038::05/04/2018-05:29:50.339 [UsbDk]CUsbDkFilterDevice::Create Entry [3]0004.0038::05/04/2018-05:29:50.339 [UsbDk]CWdfDevice::CacheDeviceName Newly created device name is \Device\UsbDkFilter7 [3]0004.0038::05/04/2018-05:29:50.339 [UsbDk]CRegText::Dump ID: USB\VID_12D1&PID_107E&MI_01 [3]0004.0038::05/04/2018-05:29:50.339 [UsbDk]CUsbDkFilterDevice::CStrategist::SelectStrategy No cached device descriptor, assigning hub strategy [3]0004.0038::05/04/2018-05:29:50.339 [UsbDk]CUsbDkFilterDevice::AttachToStack Attached [3]0004.0038::05/04/2018-05:29:50.339 [UsbDk]UsbDkEvtDeviceAdd Exit STATUS_SUCCESS [2]0004.0038::05/04/2018-05:29:50.405 [UsbDk]::operator() Starting relations array processing: [2]0004.0038::05/04/2018-05:29:50.405 [UsbDk]CDeviceRelations::Dump Array size: 1 (ptr: 871A59D0) [2]0004.0038::05/04/2018-05:29:50.405 [UsbDk]::operator() #0: 8865DCA8 [2]0004.0038::05/04/2018-05:29:50.405 [UsbDk]UsbDkSendUrbSynchronously Send URB IRP Error 0xc00000bb(STATUS_NOT_SUPPORTED) [2]0004.0038::05/04/2018-05:29:50.405 [UsbDk]CUsbDkHubFilterStrategy::RegisterNewChild Cannot query device descriptor [2]0004.0038::05/04/2018-05:29:50.405 [UsbDk]::operator() Finished relations array processing [3]0004.0038::05/04/2018-05:29:50.417 [UsbDk]::operator() Starting relations array processing: [3]0004.0038::05/04/2018-05:29:50.417 [UsbDk]CDeviceRelations::Dump Array size: 1 (ptr: 88548C38) [3]0004.0038::05/04/2018-05:29:50.417 [UsbDk]::operator() #0: 8865DCA8 [3]0004.0038::05/04/2018-05:29:50.417 [UsbDk]UsbDkSendUrbSynchronously Send URB IRP Error 0xc00000bb(STATUS_NOT_SUPPORTED) [3]0004.0038::05/04/2018-05:29:50.417 [UsbDk]CUsbDkHubFilterStrategy::RegisterNewChild Cannot query device descriptor

ybendito commented 6 years ago

Hi, xuyongjian Can you please try providing the kernel dump file (configure the system to keep kernel dumps and collect %windir%\memory.dmp file after the crash. Thanks

xuyongjian commented 6 years ago

The memory.dmp file is too large and could not be uploaded. The following is the minidump file. minidump.zip

ybendito commented 6 years ago

Minidump is not enough to locate the root cause. Is it possible to share zipped dump over dropbox?

sameehj commented 6 years ago

@xuyongjian Thanks for the minidump, in general it is better to share the kernel dump. You can do so easily using any hosting service such as google drive, Microsoft one or any other file sharing website.

we'll take a look at the minidump and get back to you soon

ybendito commented 6 years ago

I suggest to enable logging, reproduce the problem, collect kernel dump, zip it and share via one of file hosting services. Last part of log will be inside the dump and I hope we will be able to understand better the root cause of the problem. Currently the crash points on file system drivers, which does not help us.

xuyongjian commented 6 years ago

kernel dump attached https://1drv.ms/f/s!AqQtNrW8d-CwaxK1VRtNjQcpqzQ

ybendito commented 6 years ago

I've reviewed the dump files. I see the crash actually happens in system driver 'mountmgr', probably when it tries to mount some "linux cd". Usbdk at this time also work with attached USB devices but does not show any sign of the problem. I see the crash in both dumps happens on virtual machine so USB device(s) are redirected to it from somewhere (where from?). Can you please describe exactly what you do to reproduce the problem, what is your setup and how you use the usbdk on virtual machine. I see also some set of additional kernel drivers "rj' and "qq" in the stack. So, the questions:

  1. Does the same problem happen on clean machine with/without usbdk? (usbdk can be easily uninstalled/reinstalled just by 'usbdkcontroller -u' or '-i'.
  2. Does the problem happen on bare metal platform (non-VM)?

Thanks

ybendito commented 6 years ago

@xuyongjian You may want to try current master branch (if you're able to build the driver). I hope it will solve the problem

ybendito commented 6 years ago

https://github.com/daynix/UsbDk/commit/960f44ed2c697178235caa088a04ac38bd8e675c