What's new

[SOLVED] BSOD DRIVER_VERIFIER_DMA_VIOLATION (0xe6)

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
I have been getting this error (BSOD DRIVER_VERIFIER_DMA_VIOLATION (e6)) while playing video games. The thing that I find strange is that I don't even have the Driver Verifier turned on. I have done the "verifier /reset" command which was one of the first things I tried to do to fix it after Googling the error. I have also used the verifier command as outlined in the sticky on these forums with no luck. I have tried a number of things to try and fix this. A non-exhaustive list includes:

Reinstalled GPU drivers and sound drivers using DDU
chkdsk
sfc /scannow
Drivers up to date
Flash BIOS
Ran Memtest86 (8 passes)
Ran Prime95 (12 hours)
Clean install of Windows

etc, etc

Hoping someone might be able to read the tea leaves as it were. Also, someone's gotta tell me what a "26" in Parameter 1 is for the particular BSOD code (0xE6) because according to Microsoft's description of that BSOD, 26 shouldn't even be a possible value for P1. I am stumped.

DropBox link to the memory dump (~1.2GB) Dropbox - MEMORY.DMP

Specs:
Operating System
Windows 10 Home 64-bit
CPU
Intel Core i7 7820HK @ 2.90GHz 89 °C
Kaby Lake 14nm Technology
RAM
16.0GB Dual-Channel Unknown @ 1202MHz (17-17-17-39)
Motherboard
GIGABYTE X5X7 (U3E1)
Graphics
U28H75x (3840x2160@30Hz)
Generic PnP Monitor (3840x2160@60Hz)
4095MB NVIDIA GeForce GTX 1070 (Gigabyte) 55 °C
Storage
931GB PRO-X-1TB-G2 (Unknown (SSD))
931GB PRO-X-1TB-G2 (Unknown (SSD))
931GB Hitachi HGST HTS721010A9E630 (SATA ) 33 °C
7GB USB 2.0 USB Flash Drive USB Device (USB )
Optical Drives
No optical disk drives detected
Audio
Realtek High Definition Audio


Here's the nitty gritty from the actual BSOD -
Code:
Version=1
EventType=BlueScreen
EventTime=131895735192548890
ReportType=4
Consent=1
ReportStatus=2049
ReportIdentifier=c47b1165-2a21-46e4-8fd5-45ed233ae7c7
IntegratorReportIdentifier=6f161568-bc45-4495-afdc-ac0d5112c904
Wow64Host=34404
NsAppName=BlueScreen
OriginalFilename=WerFault.exe
AppSessionGuid=00000000-0000-0000-0000-000000000000
BootId=6
IsFatal=4294967295
EtwNonCollectReason=1
Response.type=4
Sig[0].Name=Code
Sig[0].Value=e6
Sig[1].Name=Parameter 1
Sig[1].Value=26
Sig[2].Name=Parameter 2
Sig[2].Value=ffffa7882155f570
Sig[3].Name=Parameter 3
Sig[3].Value=0
Sig[4].Name=Parameter 4
Sig[4].Value=6
Sig[5].Name=OS version
Sig[5].Value=10_0_17763
Sig[6].Name=Service Pack
Sig[6].Value=0_0
Sig[7].Name=Product
Sig[7].Value=768_1
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=10.0.17763.2.0.0.768.101
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
OsInfo[0].Key=vermaj
OsInfo[0].Value=10
OsInfo[1].Key=vermin
OsInfo[1].Value=0
OsInfo[2].Key=verbld
OsInfo[2].Value=17763
OsInfo[3].Key=ubr
OsInfo[3].Value=194
OsInfo[4].Key=versp
OsInfo[4].Value=0
OsInfo[5].Key=arch
OsInfo[5].Value=9
OsInfo[6].Key=lcid
OsInfo[6].Value=1033
OsInfo[7].Key=geoid
OsInfo[7].Value=244
OsInfo[8].Key=sku
OsInfo[8].Value=101
OsInfo[9].Key=domain
OsInfo[9].Value=0
OsInfo[10].Key=prodsuite
OsInfo[10].Value=768
OsInfo[11].Key=ntprodtype
OsInfo[11].Value=1
OsInfo[12].Key=platid
OsInfo[12].Value=10
OsInfo[13].Key=sr
OsInfo[13].Value=0
OsInfo[14].Key=tmsi
OsInfo[14].Value=2395
OsInfo[15].Key=osinsty
OsInfo[15].Value=1
OsInfo[16].Key=iever
OsInfo[16].Value=11.194.17763.0-11.0.100
OsInfo[17].Key=portos
OsInfo[17].Value=0
OsInfo[18].Key=ram
OsInfo[18].Value=16333
OsInfo[19].Key=svolsz
OsInfo[19].Value=931
OsInfo[20].Key=wimbt
OsInfo[20].Value=0
OsInfo[21].Key=blddt
OsInfo[21].Value=180914
OsInfo[22].Key=bldtm
OsInfo[22].Value=1434
OsInfo[23].Key=bldbrch
OsInfo[23].Value=rs5_release
OsInfo[24].Key=bldchk
OsInfo[24].Value=0
OsInfo[25].Key=wpvermaj
OsInfo[25].Value=0
OsInfo[26].Key=wpvermin
OsInfo[26].Value=0
OsInfo[27].Key=wpbuildmaj
OsInfo[27].Value=0
OsInfo[28].Key=wpbuildmin
OsInfo[28].Value=0
OsInfo[29].Key=osver
OsInfo[29].Value=10.0.17763.194.amd64fre.rs5_release.180914-1434
OsInfo[30].Key=buildflightid
OsInfo[31].Key=edition
OsInfo[31].Value=Core
OsInfo[32].Key=ring
OsInfo[32].Value=Retail
OsInfo[33].Key=expid
OsInfo[34].Key=containerid
OsInfo[35].Key=containertype
OsInfo[36].Key=edu
OsInfo[36].Value=0
File[0].CabName=121718-16359-01.dmp
File[0].Path=121718-16359-01.dmp
File[0].Flags=851970
File[0].Type=2
File[0].Original.Path=\\?\C:\Windows\Minidump\121718-16359-01.dmp
File[1].CabName=sysdata.xml
File[1].Path=WER-19078-0.sysdata.xml
File[1].Flags=851970
File[1].Type=5
File[1].Original.Path=\\?\C:\Windows\TEMP\WER-19078-0.sysdata.xml
File[2].CabName=WERInternalMetadata.xml
File[2].Path=WER564D.tmp.WERInternalMetadata.xml
File[2].Flags=851970
File[2].Type=5
File[2].Original.Path=\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER564D.tmp.WERInternalMetadata.xml
File[3].CabName=WERInternalRequest.xml
File[3].Path=WER565E.tmp.xml
File[3].Flags=851970
File[3].Type=5
File[3].Original.Path=\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER565E.tmp.xml
File[4].CabName=memory.csv
File[4].Path=WER566D.tmp.csv
File[4].Flags=589826
File[4].Type=5
File[4].Original.Path=\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER566D.tmp.csv
File[5].CabName=sysinfo.txt
File[5].Path=WER567D.tmp.txt
File[5].Flags=589826
File[5].Type=5
File[5].Original.Path=\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER567D.tmp.txt
File[6].CabName=Report.zip
File[6].Path=Report.zip
File[6].Flags=65536
File[6].Type=11
File[6].Original.Path=\\?\C:\Windows\system32\Report.zip
Ns[0].Name=stopcode
Ns[0].Value=000000E6
Ns[1].Name=p1
Ns[1].Value=0000000000000026
Ns[2].Name=p2
Ns[2].Value=FFFFA7882155F570
Ns[3].Name=p3
Ns[3].Value=0000000000000000
Ns[4].Name=p4
Ns[4].Value=0000000000000006
FriendlyEventName=Shut down unexpectedly
ConsentKey=BlueScreen
AppName=Windows
AppPath=C:\Windows\System32\WerFault.exe
NsPartner=windows
NsGroup=windows8
ApplicationIdentity=00000000000000000000000000000000
MetadataHash=-1945300102

Info out of the debugger today. Tracked the device object down from Argument 2 in the BSOD code:

kd> !devobj ffffac8feaf64060
Device object (ffffac8feaf64060) is for:
NTPNP_PCI0025 \Driver\pci DriverObject ffffac8fea4e1960
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
SecurityDescriptor ffffc28826aa4620 DevExt ffffac8feaf641b0 DevObjExt ffffac8feaf648e0 DevNode ffffac8feaf64bb0
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffac8feaf649d0 \Driver\ACPI

Doing a search on the "AttachedDevice(Upper)" returns the following:

kd> !devobj ffffac8feaf649d0
Device object (ffffac8feaf649d0) is for:
\Driver\ACPI DriverObject ffffac8fea4e54e0
Current Irp 00000000 RefCount 0 Type 00000032 Flags 00000000
SecurityDescriptor ffffc28826aa4620 DevExt ffffac8feae37bb0 DevObjExt ffffac8feaf64b20
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffac8fefa05060 \Driver\USBXHCI
AttachedTo (Lower) ffffac8feaf64060 \Driver\pci
Any ideas?

EDIT: One other thing of possible interest is looking at the device manager this links back to the
USB xHCI Compliant Host Controller (3.1 and 3.0). Driver date says 9/14/2018. That is around the time I started having problems....
 

Attachments

Last edited by a moderator:

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
Where are the minidumps?

They're not in the attached zip file.

The more dumps we have, the better.

Is the dropbox link at 1.2GB a full kernel dump? Is it zipped?

It would take me hours to download that dump as it is now.

Regards. . .

jcgriff2

p.s. Nice Windbg skills, but why did you use !devobj?
 
Last edited:

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
You have a thread at Bleeping Computer with no responses: BSOD DRIVER_VERIFIER_DMA_VIOLATION (e6) - Windows Crashes and Blue Screen of Death (BSOD) Help and Support

I thought that I recognized this thread.

We can work on it here, but I need the minidumps.

You also have a 4 page, 36 post thread at TF - BSOD DRIVER_VERIFIER_DMA_VIOLATION (e6) - Windows 10 Forums

I did not read the whole thread as .. well, I'm not a big fan of theirs.

And you posted at several other forums too. Did you post at every forum you could find? :)

Google Search

I don't blame you. This must be frustrating as hell.

Regards. . .

jcgriff2
 
Last edited:

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
Hi. . .

Your SYSTEM Event Log shows four (4) 0xe6 bugcheck BSODs - one on 17 December; two on 18 December; one on 19 December 2018.

From SYSTEM EVTX Log -- Bottom-Up () is in chronological order (most recent BSOD appears first):
Code:
Event[351]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Date: 2018-12-19T00:47:32.214
  Event ID: 1001
  Level: Error
  Description: 
The computer has rebooted from a bugcheck.  The bugcheck was: 
0x000000e6 (0x0000000000000026, 0xffffb28939c672b0, 0x0000000000000000, 0x0000000000000006). 
A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 669135ad-39ef-4cfc-8d7a-bdf39ebf506a.

Event[604]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Date: 2018-12-18T22:56:52.160
  Event ID: 1001
  Level: Error
  Description: 
The computer has rebooted from a bugcheck.  The bugcheck was: 
0x000000e6 (0x0000000000000026, 0xffffce8fd02ec060, 0x0000000000000000, 0x0000000000000006). 
A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 1c0714e9-7069-4a17-8fe2-efa93cb5eeaf.

Event[681]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Date: 2018-12-18T22:34:22.211
  Event ID: 1001
  Level: Error
  Description: 
The computer has rebooted from a bugcheck.  The bugcheck was: 
0x000000e6 (0x0000000000000026, 0xffffb88f7cec6060, 0x0000000000000000, 0x0000000000000006). 
A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: ae63919d-d2a2-43a1-aed1-d99fd27c5643.

Event[1203]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Date: 2018-12-17T21:25:16.244
  Event ID: 1001
  Level: Error
  Description: 
The computer has rebooted from a bugcheck.  The bugcheck was: 
0x000000e6 (0x0000000000000026, 0xffffa7882155f570, 0x0000000000000000, 0x0000000000000006). 
A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 6f161568-bc45-4495-afdc-ac0d5112c904.
Windows was installed the day before the first crash:
Code:
Original Install Date:     12/16/2018, 5:29:40 AM
These are the last two SYSTEM EVTX (System Event Log) entries for 16 December. The first BSOD was on 17 Dec - 21:25:16 hours, meaning that your system ran without incident for about 40 hours - then the first BSOD hit -
Code:
Event[1378]:
  Log Name: System
  Source: Microsoft-Windows-Kernel-Power
  Date: 2018-12-16T14:59:08.868  
Event ID: 107
  Description: 
The system has resumed from sleep.
Event[1379]:
  Log Name: System
  Source: Microsoft-Windows-Kernel-Power
  Date: 2018-12-16T14:59:07.843
  Event ID: 42
  Description: 
The system is entering sleep.

Sleep Reason: Application API
According to those entries, the system slept for just over 1 second, which seems ridiculous.

Do you recall what you installed within those 40 hours?

One of the system reports indicates that 5 Windows Updates were installed.

This is the first entry for 17 Dec 2018 -
Code:
Event[1377]:
  Log Name: System
  Source: EventLog
  Date: 2018-12-17T12:39:18.461
  Event ID: 6013
  Description: 
The system uptime is 85330 seconds.
If my math is correct, 85330 seconds = 23.7 hours. The first BSOD then hits ~9 hours later at 21:25:16.

From debugger.chm file (in the Windbg directory) - Info for a 0xe6 bugcheck BSOD -

debugger.chm said:
The DRIVER_VERIFIER_DMA_VIOLATION bug check has a value of 0x000000E6.

This is the bug check code for all Driver Verifier DMA Verification violations.
Then it goes on to mention parm 1 (the first number inside the parenthesis) - yours is 0x26 - on all 4 dumps -
debugger.chm said:
Parameter 1 is the only parameter of interest.

This parameter identifies the exact violation.
The problem is that there is no error 0x26 listed:

Read More:



I agree with you that it's strange that you encountered 0xe6 BSODs while Driver Verifier was off.

I would suggest that you try running Driver Verifier and see what Driver Verifier flags, if anything.

Follow this for D/V - Driver Verifier - BSOD related - Windows 10, 8.1, 8, 7 + Vista

Also, if there really are no minidumps on your system (c:\windows\minidump), change SYSTEM crash settings to produce them. I think the selection in W10 is "normal mode" (not sure - currently on W8.1 here). I also believe that if you set it to "full kernel dump" it will also produce a minidump. There also may be a "minidump" setting.

Regards. . .

jcgriff2

p.s. I see that the dump at Dropbox is NOT zipped. If zipped, it would probably end up around 10-20% of its current 1.2 GB size.

Copy it from \windows to Documents or Desktop

RIGHT-click on it; select "Send to compressed file"

The zip file will be in the same directory that you copied the file to.

You cannot zip it while it resides in \windows. Permission setting issues.
 
Last edited:

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
Thanks for the quick response!

Where are the minidumps?

They're not in the attached zip file.

The more dumps we have, the better.
It looks like they were deleted automatically. I'll attach a more recent one on my next crash but here's one from last week. Same error and everything so it should reflect the current situation.

Is the dropbox link at 1.2GB a full kernel dump? Is it zipped?

It would take me hours to download that dump as it is now.
Yeah it's the full kernel dump. At another tech support forum they requested it and didn't seem to do diddly with it anyway.

p.s. Nice Windbg skills, but why did you use !devobj?
Should I have used a different command? !devstack maybe?

EDIT: I hit reply on an unrefreshed forum page and just saw you did some digging :grin1:

I'll go thru that now and see if we can figure this out.

One other place I am trying to get help is a forum where an Aorus/Gigabyte rep is very active: Aorus Owner's Lounge | Page 100 | Overclockers UK Forums

If you go back a few pages in that thread you will see that it appears I'm not alone with having this same exact BSOD on the same exact machine (Aorus X5v7). I suspect something is FUBAR with the USBHXCI drivers. Mine are dated 9/14/18 and that appears to be when a lot of us X5v7 users started having issues. Could just be coincidence but I doubt it. And if you read my latest comment in that thread you will see that the USB drivers on the manufacturers website for my machine appear to not be compatible with what is in my machine.... Very strange. The only modifying I have done with this laptop was install new NVMe SSDs the day I received it and it ran fine for months after that, so I don't think that is my issue.
 

Attachments

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
See if you can recover the minidumps.

Use your favorite undelete program or use Altap - Download - Altap Salamander File Manager

Assuming you use drive c: for OS - select another drive (if you have one) in either the right or left pane, then create a directory called "rest1" (or whatever name you want), [if no other drive, just use c:]; Click on "Plugins" at top, click "Undelete", select drive c: -- progress bar will start for restoring deleted files; upon completion, select {All Deleted Files}; copy all to c:\rest1

Then look for minidumps. You can use Altap to search - CTRL+F; enter *.dmp at top

If found, click on dump file in search window, then click on "Focus" (left-side; middle) - scroll to right - it will tell you the condition of the recovered file.

However many are there, zip them up and attach to your next post.

Run Driver Verifier per my prior post in the interim.

I'll be back tomorrow (Thursday - I am GMT-5) to check and answer your other questions.

Hope all the above makes sense!

Regards. . .

jcgriff2
 

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
See if you can recover the minidumps.

Use your favorite undelete program or use Altap - Download - Altap Salamander File Manager

Assuming you use drive c: for OS - select another drive (if you have one) in either the right or left pane, then create a directory called "rest1" (or whatever name you want), [if no other drive, just use c:]; Click on "Plugins" at top, click "Undelete", select drive c: -- progress bar will start for restoring deleted files; upon completion, select {All Deleted Files}; copy all to c:\rest1

Then look for minidumps. You can use Altap to search - CTRL+F; enter *.dmp at top

If found, click on dump file in search window, then click on "Focus" (left-side; middle) - scroll to right - it will tell you the condition of the recovered file.

However many are there, zip them up and attach to your next post.

Run Driver Verifier per my prior post in the interim.

I'll be back tomorrow (Thursday - I am GMT-5) to check and answer your other questions.

Hope all the above makes sense!

Regards. . .

jcgriff2
I get a "Error Opening Volume. Access Denied." when I try and run the Undelete plugin.
 

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
For some reason I can't edit the previous message, sorry for posting consecutively.

Last night I ran a VR game that seemed to crash more than any other program I have so I used it as a benchmark and ran it for 8 hours straight, even leaving it on while I wasn't gaming (a situation where it would often crash as well) with no problems. The only things I did yesterday was run the Intel Chipset Update utility and also unchecked a setting in the Device Manager for my USB 3.0 eXtensible Host Controller -

usbhxci settings.png

I read a thread yesterday where this setting has been known to cause issues on laptops.

Also: The Gigabyte/Aorus rep got back with me this morning (They're in the UK) and it appears there was in fact a newer BIOS than was listed on their website. I flashed that. When I get home from work this afternoon I'll run the VR program again and see how we do. Hoping one of these things solves it. Narrowing the drivers/device down in the kernel dump to the USBXHCI gives me a bit more confidence. If I can run that VR program tonight and tomorrow without issues I'll put this one down as solved.

Thanks, jcgriff!
 

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
Hi. . .

Sorry that Altap did not work.

Did you ever run Driver Verifier?

Please zip up the minidumps from your multiple crashes described in your last post and attach to your next post. If none - change system settings.

Also, zip up the full kernel (\windows\memory.dmp) and upload it to Dropbox. Really no one will want to take the time to download your 1.2 GB dump from post #1. And there are a few proficient in Windbg (much more than I) that may see this thread and run through the full kernel, but doubtful if they have to download 1.2 GB. Use the most recent version of the full kernel dump.

RE: Windbg commands - I was just curious why you used !devobj because it returns info on a device object from a memory address that you provide. I did not know if you were going somewhere with it or not.

RE: USBHXCI - these are your USB 3.0 drivers, I assume? USBHXCI.sys is a Microsoft driver and is therefore sacrosanct and I highly doubt is involved in these crashes. You could try updating your 3rd party USB 3.0 drivers. Look in Device Manager for their names.

I checked the onlune reference for bugcheck 0xe6 and they don't list an error code 0x26 either - Bug Check 0xE6 DRIVER_VERIFIER_DMA_VIOLATION - Windows drivers | Microsoft Docs

"DMA" I assume to be "Direct Memory Access", which would indicate that a driver violated DMA rules, but no driver is listed on the stack - just HAL and of course NT (Windows Kernel) -
Code:
0: kd> kn
 # Child-SP          RetAddr           Call Site
00 fffff800`13a6feb8 fffff800`11447707 nt!KeBugCheckEx
01 fffff800`13a6fec0 fffff800`11442f9c hal!IvtHandleInterrupt+0x1b7
02 fffff800`13a6ff10 fffff800`115c5315 hal!HalpIommuInterruptRoutine+0x4c
03 fffff800`13a6ff40 fffff800`116549fc nt!KiCallInterruptServiceRoutine+0xa5
04 fffff800`13a6ff90 fffff800`11654df7 nt!KiInterruptSubDispatchNoLock+0x11c
05 ffff8407`65577a00 00000000`00000000 nt!KiInterruptDispatchNoLock+0x37
Have you tested RAM just to be sure?

Test RAM with memtest.org MemTest86+

Regards. . .

jcgriff2
 

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
Hi. . .

Sorry that Altap did not work.

Did you ever run Driver Verifier?
Yes I did. I followed the walkthrough on this forum in the sticky. System ran same as usual at the time. Play a video game for 30 minutes-hour and same BSOD.

Please zip up the minidumps from your multiple crashes described in your last post and attach to your next post. If none - change system settings.
I have no minidumps other than the one I attached to a post earlier in the thread using the Betalogs program that the folks at tenforums use. It contains a proper minidump. All of my currrent ones were either wiped when I reformatted and did a Clean Windows Install. Haven't BSOD'd since Monday night and those minidumps appear to have been automatically cleaned after a reboot or something. I'm not sure.

As I said earlier, I plan on doing a stress test again with my VR system tonight. Ran it for 8 hours yesterday with no crashes or BSODs which is promising.

Also, zip up the full kernel (\windows\memory.dmp) and upload it to Dropbox. Really no one will want to take the time to download your 1.2 GB dump from post #1. And there are a few proficient in Windbg (much more than I) that may see this thread and run through the full kernel, but doubtful if they have to download 1.2 GB. Use the most recent version of the full kernel dump.
*shrug* I can download 1.2 GB from most servers in a matter of about 2-3 minutes, but I understand. If everyone shoved out a 1.2 GB file for analysis that would definitely eat into bandwidth if you're a dedicated troubleshooter.[/quote]

RE: Windbg commands - I was just curious why you used !devobj because it returns info on a device object from a memory address that you provide. I did not know if you were going somewhere with it or not.

RE: USBHXCI - these are your USB 3.0 drivers, I assume? USBHXCI.sys is a Microsoft driver and is therefore sacrosanct and I highly doubt is involved in these crashes. You could try updating your 3rd party USB 3.0 drivers. Look in Device Manager for their names.
Yes. The interesting thing about the USB eXtensible drivers are that they were originally supported by Intel and not Microsoft. Intel handed the responsibility for driver support for those over to Microsoft somewhat recently. At least for my machine. In fact Intel is still providing driver support for Windows 7 and earlier until January 1st, 2019. I ran the Intel Chipset driver update yesterday... No idea if anything was out of date or wonky but the install process was notably having an effect on devices as it disabled and installed a variety of drivers.

Some of this could be coincidence as correlation does not mean causality, but the stability of my machine last night gives me hope I might have turned a corner. We'll see the next two days. I'm gonna make this laptop wish it was never assembled :grin1:


I checked the onlune reference for bugcheck 0xe6 and they don't list an error code 0x26 either - Bug Check 0xE6 DRIVER_VERIFIER_DMA_VIOLATION - Windows drivers | Microsoft Docs
Weird, right? I noticed that the day I had the error and thought it funny. Then I thought maybe the value 26 was in Dec and changed it to Hex for the code listing (1A) and I kid you not the values for P1 SKIP 1A.... So in effect there isn't even a 26th value if we're assuming a sequential order.... :banghead:

"DMA" I assume to be "Direct Memory Access", which would indicate that a driver violated DMA rules, but no driver is listed on the stack - just HAL and of course NT (Windows Kernel) -
Code:
0: kd> kn
 # Child-SP          RetAddr           Call Site
00 fffff800`13a6feb8 fffff800`11447707 nt!KeBugCheckEx
01 fffff800`13a6fec0 fffff800`11442f9c hal!IvtHandleInterrupt+0x1b7
02 fffff800`13a6ff10 fffff800`115c5315 hal!HalpIommuInterruptRoutine+0x4c
03 fffff800`13a6ff40 fffff800`116549fc nt!KiCallInterruptServiceRoutine+0xa5
04 fffff800`13a6ff90 fffff800`11654df7 nt!KiInterruptSubDispatchNoLock+0x11c
05 ffff8407`65577a00 00000000`00000000 nt!KiInterruptDispatchNoLock+0x37
Yeah. I have no idea how that would even be useful from a troubleshooting standpoint other than at the end of the line it comes down to bad hardware, and that's why I decided to follow the trail from the P2 value. P2 is the device address reporting the error if I'm not mistaken?

Have you tested RAM just to be sure?

Test RAM with memtest.org MemTest86+

Regards. . .

jcgriff2
Absolutely. Ran 2 separate 8 pass tests to be sure with flying colors. Same with Prime 95 for the CPU. Ran all Prime 95 tests on the CPU for 16 hours without a single error. The last couple of weeks dealing with this have been really frustrating to the point where I was HOPING one of those stress tests would fail so I'd have some kind of answer on what was wrong, because I was sure the filesystem was good too after a complete reformat and reinstall of different versions of the Windows 10 iso.

Finding out there was a much more recent BIOS update than what was listed on the manufacturer's website might be promising too.

Time and lots cycles the next couple days will tell.

Thanks again for your support. I'll be sure to drop a few bucks in the donation bucket for your effort as well :thumbsup2:
 

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
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> .bugcheck
Bugcheck code 000000E6
Arguments 00000000`00000026 ffff968c`43ceb060 00000000`00000000 00000000`00000006
Parameter 1 (P1) - 0x26
Parameter 2 (P2) - 0x968c`43ceb060
Parameter 3 (P3) - 0x0
Parameter 4 (P4) - 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: kd> !devobj ffff968c43ceb060
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.
P2 is definitely not a Driver Object (!drvobj) -
Code:
0: kd> !drvobj ffff968c43ceb060
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
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
 

Patrick

Moderator, BSOD Kernel Dump Expert
Staff member
Joined
Jun 7, 2012
Messages
4,578
I'll be taking a look into this one today. Expect a reply for me sometime today if I get a moment or tomorrow as I have work.
 

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
I get symbol errors for NT from the minidump.

Sorry to ask, but this is a genuine Windows installation, right?

Did Windows come installed on the system (OEM version) or did you purchase W10 (full retail)?

jcgriff2
 

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
I get symbol errors for NT from the minidump.

Sorry to ask, but this is a genuine Windows installation, right?

Did Windows come installed on the system (OEM version) or did you purchase W10 (full retail)?

jcgriff2
Came installed with it. I've done a few wipes and clean reinstalled Windows though. Twice since the problem began. Could it have something to do with making a c:\symbols directory and using that with the debugger? Maybe I didn't set something up correctly.
 

Patrick

Moderator, BSOD Kernel Dump Expert
Staff member
Joined
Jun 7, 2012
Messages
4,578
I really hate to go this route, but this looks like a buggy activator/non-gen OS at work.

Code:
0: kd> .bugcheck
Bugcheck code 000000E6
Arguments 00000000`00000026 ffffac8f`eaf64060 00000000`00000000 00000000`00000006
0xE6 bug check implies you have DV enabled, but what's most interesting is...

Code:
Verify Flags Level 0x00000000

  STANDARD FLAGS:
    [ ] (0x00000000) Automatic Checks
    [ ] (0x00000001) Special pool
    [ ] (0x00000002) Force IRQL checking
    [ ] (0x00000008) Pool tracking
    [ ] (0x00000010) I/O verification
    [ ] (0x00000020) Deadlock detection
    [ ] (0x00000080) DMA checking
    [ ] (0x00000100) Security checks
    [ ] (0x00000800) Miscellaneous checks
    [ ] (0x00020000) DDI compliance checking

  ADDITIONAL FLAGS:
    [ ] (0x00000004) Randomized low resources simulation
    [ ] (0x00000200) Force pending I/O requests
    [ ] (0x00000400) IRP logging
    [ ] (0x00002000) Invariant MDL checking for stack
    [ ] (0x00004000) Invariant MDL checking for driver
    [ ] (0x00008000) Power framework delay fuzzing
    [ ] (0x00010000) Port/miniport interface checking
    [ ] (0x00040000) Systematic low resources simulation
    [ ] (0x00080000) DDI compliance checking (additional)
    [ ] (0x00200000) NDIS/WIFI verification
    [ ] (0x00800000) Kernel synchronization delay fuzzing
    [ ] (0x01000000) VM switch verification
    [ ] (0x02000000) Code integrity checks
...you don't. Common bug when using modified OS'.

You also have an OEM key:

Code:
00325-96219-48237-AAOEM
On a non-OEM build:

Code:
GIGABYTE X5X7
There's also no existing Gigabyte model for boards or prebuilds with that product name.

Some other bits:

Code:
SystemVersion = Default string
BaseBoardVersion = Default string
Code:
[Length 27 - Handle 0001h]
Version                       Default string
Serial Number                 ghg9pdc11a0028
Code:
OSBUILD_TIMESTAMP:  unknown_date
 

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
I really hate to go this route, but this looks like a buggy activator/non-gen OS at work.

Code:
0: kd> .bugcheck
Bugcheck code 000000E6
Arguments 00000000`00000026 ffffac8f`eaf64060 00000000`00000000 00000000`00000006
0xE6 bug check implies you have DV enabled, but what's most interesting is...

Code:
Verify Flags Level 0x00000000

  STANDARD FLAGS:
    [ ] (0x00000000) Automatic Checks
    [ ] (0x00000001) Special pool
    [ ] (0x00000002) Force IRQL checking
    [ ] (0x00000008) Pool tracking
    [ ] (0x00000010) I/O verification
    [ ] (0x00000020) Deadlock detection
    [ ] (0x00000080) DMA checking
    [ ] (0x00000100) Security checks
    [ ] (0x00000800) Miscellaneous checks
    [ ] (0x00020000) DDI compliance checking

  ADDITIONAL FLAGS:
    [ ] (0x00000004) Randomized low resources simulation
    [ ] (0x00000200) Force pending I/O requests
    [ ] (0x00000400) IRP logging
    [ ] (0x00002000) Invariant MDL checking for stack
    [ ] (0x00004000) Invariant MDL checking for driver
    [ ] (0x00008000) Power framework delay fuzzing
    [ ] (0x00010000) Port/miniport interface checking
    [ ] (0x00040000) Systematic low resources simulation
    [ ] (0x00080000) DDI compliance checking (additional)
    [ ] (0x00200000) NDIS/WIFI verification
    [ ] (0x00800000) Kernel synchronization delay fuzzing
    [ ] (0x01000000) VM switch verification
    [ ] (0x02000000) Code integrity checks
...you don't. Common bug when using modified OS'.

You also have an OEM key:

Code:
00325-96219-48237-AAOEM
On a non-OEM build:

Code:
GIGABYTE X5X7
There's also no existing Gigabyte model for boards or prebuilds with that product name.

Some other bits:

Code:
SystemVersion = Default string
BaseBoardVersion = Default string
Code:
[Length 27 - Handle 0001h]
Version                       Default string
Serial Number                 ghg9pdc11a0028
Code:
OSBUILD_TIMESTAMP:  unknown_date
It's an Aorus X5v7 laptop. The guts are Gigabyte. While the model of the laptop is X5V7 the motherboard is a X5X7. Kind of confusing.

The only thing I can think on the OS side of things is something wasn't configured correctly when I reinstalled Windows but I was having these BSODs long before i did any reinstallation of Windows.

The guy that was initially trying to help me over at tenforums.com noticed from my kernal dumps that there were issues with corrupted modules and I had some page file issues as well that were keeping the dumps from even being recorded initially.

I bought the computer in June this year off Newegg.com as an "unboxed" unit I guess meaning it was lightly used or was a demo model. I never had any problems with it until early October however. Everything about the machine should be above board to my knowledge though.
 

PhelanKA7

Contributor
Joined
Dec 19, 2018
Messages
25
Also, for the record I used the Windows Media Creation Tool for the Windows installations.
 

jcgriff2

Site Administrator, Forum General Manager, BSOD Kernel Dump Expert
Staff member
Joined
Feb 19, 2012
Messages
17,516
Location
New Jersey Shore
Sorry, but this is entire BS -
The guy that was initially trying to help me over at tenforums.com noticed from my kernal dumps that there were issues with corrupted modules and I had some page file issues as well that were keeping the dumps from even being recorded initially.
sfc /scannow would tell you if you had corrupted modules, not the dumps. "page file issues" - how would he know that?

But as Patrick said - your OS is likely non-genuine.
 
Top