OSVR-Core
OSVR-Core copied to clipboard
OSVR
Windows BSOD on Shutdown When HDK is Plugged In
I'm getting a blue screen of death whenever I shut down my computer with the HDK power supply plugged in. If I unplug the power supply but leave everything else plugged in, there is no issue.
Here is the data from the Reliability Monitor. I can upload the crash dump file too if necessary.
Problem signature
Problem Event Name: BlueScreen
Code: 10d
Parameter 1: d
Parameter 2: ffffe001a2700ca0
Parameter 3: ffffe001a9cff010
Parameter 4: ffffe001a2731180
OS version: 10_0_10586
Service Pack: 0_0
Product: 768_1
OS Version: 10.0.10586.2.0.0.768.101
Locale ID: 1033
Extra information about the problem
Bucket ID: 0x10D_d_Wdf01000!FxVerifierBugCheckWorker
Is this that WdfViolation I sometimes hear people complain about? (and which I actually see too on the rare occasion that I reboot) The ironic thing is, there are no HDK drivers in a sense: there are only .inf files telling Windows things about its existing drivers, so it's not a bug in our drivers: if anything it's a bug in Microsoft's. (I will note I see similar things with other HMDs as well - when I remember, I try not to shut down or start up with an HMD plugged in over usb or hdmi)
That's not a lot of info on the issue - not very helpful in troubleshooting it. But, if that's the same thing I saw, I've presumably got my own copy of the bugcheck crash dump.
What processor are you using? Does it happen if you disconnect USB instead of power?
Intel 4th gen Core i7 - don't think it happens if USB isn't plugged in, which I thought was less information than the fact that pulling power also was sufficient to prevent it.
OK, here's what I get when looking into the minidump, following instructions at http://social.technet.microsoft.com/wiki/contents/articles/6302.windows-bugcheck-analysis.aspx
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 10D, {d, ffffe000fe7e2070, ffffe00101d575e0, ffffe000f33459a0}
Probably caused by : Wdf01000.sys ( Wdf01000!FxVerifierBugCheckWorker+1e )
Followup: MachineOwner
---------
5: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 000000000000000d, A power irp was received for the device but the irp was not
requested by the device (the power policy owner). Possibly there
are multiple power policy owners. Only one driver in the stack can
be the power policy owner. A KMDF driver can change power policy
ownership by calling the DDI WdfDeviceInitSetPowerPolicyOwnership.
Arg2: ffffe000fe7e2070, Device object pointer.
Arg3: ffffe00101d575e0, Power Irp.
Arg4: ffffe000f33459a0, Reserved.
Debugging Details:
------------------
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING: 10586.420.amd64fre.th2_release_sec.160527-1834
SYSTEM_MANUFACTURER: Dell Inc.
SYSTEM_PRODUCT_NAME: XPS 8700
SYSTEM_SKU: 0x05B7
BIOS_VENDOR: Dell Inc.
BIOS_VERSION: A11
BIOS_DATE: 07/09/2015
BASEBOARD_MANUFACTURER: Dell Inc.
BASEBOARD_PRODUCT: 0KWVT8
BASEBOARD_VERSION: A00
DUMP_TYPE: 2
BUGCHECK_P1: d
BUGCHECK_P2: ffffe000fe7e2070
BUGCHECK_P3: ffffe00101d575e0
BUGCHECK_P4: ffffe000f33459a0
BUGCHECK_STR: 0x10D_d
CPU_COUNT: 8
CPU_MHZ: d40
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3c
CPU_STEPPING: 3
CPU_MICROCODE: 6,3c,3,0 (F,M,S,R) SIG: 1E'00000000 (cache) 1E'00000000 (init)
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
ANALYSIS_SESSION_HOST: RYAN-SENSICS
ANALYSIS_SESSION_TIME: 08-01-2016 09:43:23.0298
ANALYSIS_VERSION: 10.0.10586.567 amd64fre
LAST_CONTROL_TRANSFER: from fffff801663de01a to fffff800763527a0
STACK_TEXT:
ffffd000`275bea08 fffff801`663de01a : 00000000`0000010d 00000000`0000000d ffffe000`fe7e2070 ffffe001`01d575e0 : nt!KeBugCheckEx
ffffd000`275bea10 fffff801`663afb93 : ffffe001`02488020 ffffd000`275bebf0 00000000`00000000 ffffd000`275beb10 : Wdf01000!FxVerifierBugCheckWorker+0x1e [d:\th\minkernel\wdf\framework\shared\object\fxverifierbugcheck.cpp @ 72]
ffffd000`275bea50 fffff801`6637dff2 : ffffe001`02488020 00000000`00000000 00000000`00000002 ffffd000`275bec10 : Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x2693b [d:\th\minkernel\wdf\framework\shared\irphandlers\pnp\fdopower.cpp @ 323]
ffffd000`275beaa0 fffff801`663711b1 : ffffe001`01d575e0 ffffe000`fa95bb60 fffff800`764ea100 fffff800`764eabe0 : Wdf01000!FxPkgPnp::Dispatch+0xb2 [d:\th\minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgpnp.cpp @ 654]
ffffd000`275beb10 fffff800`7632094a : ffffd000`275bebf0 fffff800`00000000 fffff800`764ea100 fffff800`764ea160 : Wdf01000!FxDevice::DispatchWithLock+0x111 [d:\th\minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1402]
ffffd000`275beb70 fffff800`762fdb75 : ffffffff`fa0a1f00 fffff800`76320754 ffffe000`f308e940 00000000`000000a0 : nt!PopIrpWorker+0x1f6
ffffd000`275bec10 fffff800`76357946 : ffffd000`3e980180 ffffe000`fad4e840 fffff800`762fdb34 00000000`00000000 : nt!PspSystemThreadStartup+0x41
ffffd000`275bec60 00000000`00000000 : ffffd000`275bf000 ffffd000`275b9000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: d7a71c212710c4f3f0feeb1b265012083e94e2d5
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 8b8f6f805004af36dccf91c6105e9ada0610b9a8
THREAD_SHA1_HASH_MOD: 354957ea384aefacae291aa67c1411e11a285072
FOLLOWUP_IP:
Wdf01000!FxVerifierBugCheckWorker+1e [d:\th\minkernel\wdf\framework\shared\object\fxverifierbugcheck.cpp @ 72]
fffff801`663de01a cc int 3
FAULT_INSTR_CODE: 8948cccc
FAULTING_SOURCE_LINE: d:\th\minkernel\wdf\framework\shared\object\fxverifierbugcheck.cpp
FAULTING_SOURCE_FILE: d:\th\minkernel\wdf\framework\shared\object\fxverifierbugcheck.cpp
FAULTING_SOURCE_LINE_NUMBER: 72
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: Wdf01000!FxVerifierBugCheckWorker+1e
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Wdf01000
IMAGE_NAME: Wdf01000.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5632d4db
IMAGE_VERSION: 1.17.10586.0
BUCKET_ID_FUNC_OFFSET: 1e
FAILURE_BUCKET_ID: 0x10D_d_Wdf01000!FxVerifierBugCheckWorker
BUCKET_ID: 0x10D_d_Wdf01000!FxVerifierBugCheckWorker
PRIMARY_PROBLEM_CLASS: 0x10D_d_Wdf01000!FxVerifierBugCheckWorker
TARGET_TIME: 2016-07-18T20:59:00.000Z
OSBUILD: 10586
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 784
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS Personal
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2016-05-27 22:59:07
BUILDDATESTAMP_STR: 160527-1834
BUILDLAB_STR: th2_release_sec
BUILDOSVER_STR: 10.0.10586.420.amd64fre.th2_release_sec.160527-1834
ANALYSIS_SESSION_ELAPSED_TIME: 40b
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x10d_d_wdf01000!fxverifierbugcheckworker
FAILURE_ID_HASH: {7424b165-3992-5a5a-5841-549c300de07e}
Followup: MachineOwner
---------
Does seem reasonable that it's power-related, given that it happens at shutdown... I haven't tried to see if it happens if only the beltbox is connected, to determine if it's in the HMD itself (or the combination), or in the devices/firmware in the beltbox (USB audio, etc).
(and I haven't soldered a usb jack onto the mobo of either of my HDKs so I can't bypass the beltbox)
Hi, I'm having a similar problem. In my case, if I leave the HDK2 connected and sleep the system it would power off instead. It would not happen if the usb, hmd or power is disconnected.
I'm on a Win10 Anniversary x64 system.
Hi, I forgot to mention what I discovered after that. The problem seems to be caused by the COM interface/driver. I actually have it disabled in device manager to avoid that problem.
@atmuc I have seen this with my machine and the HDK as well as other HMDs, and it's hard to tell if it gets stuck before or after UEFI turns into Windows.
@Sp4iK that's actually a very interesting finding/bit of feedback - thanks a ton! The crash log shows that it crashes in Microsoft's driver, this would suggest that it's crashing specifically in the USB Serial driver (if you can leave the HID interface for tracking and the "composite device" enabled). That brings it from being a general compatibility issue to something specific to the way the MS USB CDC (usb serial) driver is interacting with the USB-related bits of the MCU firmware.
We're using the Atmel ASF (pretty standard firmware framework for Atmel chips) on an XMEGA256A3BU in this particular case, and though it's presenting both a HID interface and a USB serial, it's not really doing anything too exotic with either of them, frankly. (And, I've combed Atmel's published changelogs, as well as their diffs between revisions, and I've verified we aren't making any unnecessary deviations from "standard usage" or the latest upstream). I'm pretty sure I've tested in the past using just the sample USB-Serial-only example projects without error, but making a composite device adds another level that potentially is the source of the trouble. It should be possible to start with just "template"/example projects in Atmel Studio with ASF and see if we can get up to the config the firmware uses (a composite device with both Generic HID and CDC), basically bisecting the error source.
Anybody have any good contacts at Microsoft to approach this from the other end? 😄 Never hurts to ask... even if the firmware is doing something invalid, it shouldn't be able to cause their driver to crash (and by now they should have a cluster of error reports - presumably small due to relative userbase size, but every one that I've seen has been effectively identical, so it should be a tidy cluster)
So you are suggesting this is a problem in the Microsofts Generic HID? Sorry but this all sounds pretty abstract to me. Anyway if you need error reports or whatever to test, I'll be glad to help.
No, it's an error in the MS generic USB CDC (which is basically the standard way of doing an emulated serial port over USB) driver - if disabling the com port fixes it, then the HID driver is fine.
I think we've got all the logs we need (and can repro) - so unless you want to play around with firmware development or have contacts at MS, you've probably helped about as much as possible at this point. I do really appreciate the discovery that the com port is the specific issue - I hadn't thought of disabling individual drivers because I thought it was failing at a lower/higher level than that.
Hi, an update on this. I have recently upgraded to Win10 Creator Update and since that I have not had any crash. Could MS have fixed this problem?