Hi. . .
Thank you for the offer of a donation as this forum survives on such gifts, but I just want to make it perfectly clear that I/we work just as hard on threads whether or not a donation is received.
I'm glad to hear of the successful BIOS update. BIOS updates can sometimes work magic.
To update your 3rd party USB drivers, go into Device Manager (devmgmt.msc from Search box)
Find the USB entry; 2x-click on it; click on "driver" tab and you'll see a list of drivers. The first one listed is usually the one we're after. Once you have the driver name, you can look it up in our Driver Reference Table (DRT) and obtain the driver update site.
DRT - Driver Reference Table (DRT)
There are well over 4,000 drivers listed in the DRT. If your driver is not found, post the name of the driver(s) and I'll find the update site for you.
RE: Minidumps - you should have one from the Driver Verifier BSOD that you just reported. Is there a \windows\minidump folder at all? I know that this may seem like no big deal, but if no minidumps are being produced and your system crash settings (located under SYSTEM in Control Panel) are correct, this means that another mysterious/unknown problem/issue exists with your system.
Since no minidump and the Driver Verifier BSOD was the last one that you encountered, the full kernel dump should be the VERIFIER_ENABLED dump. A VERIFIER_ENABLED dump often contains additional information that could be helpful to us - like the name of a 3rd party on the stack. I really need to see that VERIFIER_ENABLED dump, so please copy it out to Documents or Desktop, ZIP (no RAR, please) it up and upload it to Dropbox or another file hosting site. 1.2 GB may not seem like much to you to download, but for my Internet, it is. The last time that I downloaded a 4.3 GB Windows ISO from MSDN, it took nearly 23 hours and was corrupted. There is a ton of whitespace in a dump file, so zipping it will result in a zipped dump file that is 10-20% of the original *.dmp file size and therefore much faster (and hopefully less of a chance for the file to end up corrupted) for me do download.
My only choices for ISP here at the New Jersey Shore is Verizon DSL or Optimum Cable. I have the latter, but it runs at the speed of the former. No FIOS is available here.
The bugcheck on the sole minidump submitted:
[CODE]0: kd> [B][h32].bugcheck[/h32]
[/B]Bugcheck code [HI]000000E6[/HI]
Arguments [h31]00000000`00000026[/h31] [h33]ffff968c`43ceb060[/h33] [h41]00000000`00000000[/h41] [h43]00000000`00000006[/h43]
[/CODE]
[h31]Parameter 1 (P1)[/h31] - 0x26
[h33]Parameter 2 (P2)[/h33] - 0x968c`43ceb060
[h41]Parameter 3 (P3)[/h41] - 0x0
[h43]Parameter 4 (P4)[/h43] - 0x6
Good guess on the value of P2 (parameter 2 -- the second number inside the parenthesis delimitated by commas) in the bugcheck string, but I cannot find out anything in any Microsoft documentation about the values of P2, P3 or P4 for bugcheck 0xe6. Microsoft keeps many things related to Windbg secret for whatever reason (especially when it comes to bugcheck string parm values) - like it's a national defense secret! I constantly come across this and it gets really frustrating at times.
P4 value of 0x6 is a mystery, but it must mean something otherwise it would be 0x0.
Using !devobj with P2 on the minidump you posted/attached:
[CODE]0: [B]kd> [h34]!devobj ffff968c43ceb060[/h34][/B]
Device object (ffff968c43ceb060) is for:
Cannot read info offset from nt!ObpInfoMaskToOffset
\Driver\pci DriverObject ffff968c431174e0
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
Dacl ffffbf10700ae9e1 DevExt ffff968c43ceb1b0 DevObjExt ffff968c43ceb8e0 DevNode ffff968c43ceab70
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffff968c43127040 Name paged out
Device queue is not busy.
[/CODE]
P2 is definitely not a Driver Object (!drvobj) -
[CODE]0: kd> [h31]!drvobj ffff968c43ceb060[/h31]
fffff800118bc748: Unable to get value of ObpRootDirectoryObject
fffff800118bc748: Unable to get value of ObpRootDirectoryObject
Driver object (ffff968c43ceb060) is for:
ffff968c43ceb060: is not a driver object
[/CODE]
Last item for now -
I noticed an unloaded driver (drivers must be loaded into RAM before they can be used, then are typically unloaded to make room for another driver) - OCULUS119B.sys. It does not show up in the loaded drivers listing (if you run a Windbg command like lmnv) nor is Windbg able to provide any info with the driver info line item command lmvm OCULUS119B). No idea why, but this driver just caught my eye.
I checked and it is not found in our DRT, so I investigated a little.
OCULUS119B.sys is apparently a CMEDIA audio related driver. One description that I found listed it as "audio driver for the Rift's built in CMEDIA 119-something sound chip".
Please check in \windows\system32\drivers for the driver and please report back any info that you can find out about it.
The next thing that I found out about it is that it's either a product of or just supported by Oculus.
Oculus Support Center - Getting Started With Your Oculus Rift | Oculus Support Center
"Rift" is the first selection on the left side.
As I said - no idea why I looked into this - just one of those feelings after seeing it in the dump.
Regards. . .
jcgriff2
