D
DrJosh9000
Hello all,
I'm trying to figure out why recent Windows 10 (OS builds 19041.508 and 19041.572, i.e. September and October updates) bugcheck with Stop code DRIVER_VERIFIER_DMA_VIOLATION whenever I connect this portable NVMe SSD (LaCie Rugged Pro) via Thunderbolt 3. (The SSD internal to the drive is a Seagate Firecuda.)
Yes, I have done sfc/scannow, dism, and even a full Reset. Only rolling back the updates or reinstalling from scratch worked. Connecting the device does not cause a bugcheck on earlier updates (tested OS builds 19041.264, 19041.329, 19041.388, and 19041.450), and it definitely does work perfectly fine as a storage device on these versions, so for now I'm stuck on the August update.
Looking at the modified files list from the September update relative to the August update, there seem to be a bunch more files. Nothing seems relevant to me from the list except maybe stornvme.sys...
The bugcheck occurs midway during startup if the drive is connected before power-on. If connected after startup, it bugchecks right as the third "device connected" sound plays. (When it works, it plays the sound 3 times.)
I don't have any other TB3 NVMe drives to try, but I do have a TB3-attached eGPU which is working fairly well (on all OS builds). As much as I don't trust Thunderbolt, my hunch is that it is not the issue here.
In all these tests, Driver Verifier was disabled, so despite the stop code, it's not actually Driver Verifier. Turning it on seemed to have no effect (though I haven't tried every combination yet).
The Stop error screen does not blame a particular driver, simply "DRIVER_VERIFIER_DMA_VIOLATION".
Poking at the memory dump in WinDbg (as far as I feel comfortable, for now), !analyze -v doesn't blame any particular driver. For the bugcheck itself, Arg1 is 0x26 (IOMMU detected DMA violation), Arg2 (nt!_DEVICE_OBJECT) has DriverObject "\Driver\pci", AttachedDevice's Driver is "\Driver\stornvme", which I think confirms this is triggered by attaching the NVMe device, and is maybe evidence that there's a new bug in stornvme.sys (but what would I know).
Any more hints of things to try or look at? (Do I have to upload the memory dump?)
Microsoft (R) Windows Debugger Version 10.0.20153.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\MEMORY.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff800`2f000000 PsLoadedModuleList = 0xfffff800`2fc2a310
Debug session time: Sat Oct 17 17:51:25.813 2020 (UTC + 11:00)
System Uptime: 0 days 0:00:06.480
Loading Kernel Symbols
...............................................................
...............Page 841516 not present in the dump file. Type ".hh dbgerr004" for details
.................................................
.....................................
Loading User Symbols
Loading unloaded module list
......
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff800`2f3f3ea0 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffff800`32a7beb0=00000000000000e6
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_VERIFIER_DMA_VIOLATION (e6)
An illegal DMA operation was attempted by a driver being verified.
Arguments:
Arg1: 0000000000000026, IOMMU detected DMA violation.
Arg2: ffffe00193f74670, Device Object of faulting device.
Arg3: 0000000000000001, Faulting information (usually faulting physical address).
Arg4: 0000000000000005, Fault type (hardware specific).
Debugging Details:
------------------
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2015
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on JOSH-MBP-W
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 2001
Key : Analysis.Memory.CommitPeak.Mb
Value: 88
Key : Analysis.System
Value: CreateObject
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
BUGCHECK_CODE: e6
BUGCHECK_P1: 26
BUGCHECK_P2: ffffe00193f74670
BUGCHECK_P3: 1
BUGCHECK_P4: 5
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
PROCESS_NAME: System
STACK_TEXT:
fffff800`32a7bea8 fffff800`2f4da6e7 : 00000000`000000e6 00000000`00000026 ffffe001`93f74670 00000000`00000001 : nt!KeBugCheckEx
fffff800`32a7beb0 fffff800`2f4c660b : 00000000`00000000 00000000`00000000 fffff800`2fc49c30 fffff800`2fc49c30 : nt!IvtHandleInterrupt+0x1a7
fffff800`32a7bf10 fffff800`2f280795 : fffff800`2fcf3a80 fffff800`32a6ca50 fffff800`2fcf3b30 fffff800`32a7bfc0 : nt!HalpIommuInterruptRoutine+0x4b
fffff800`32a7bf40 fffff800`2f3f581c : fffff800`32a6ca50 fffff800`2fcf3a80 00000000`00000382 fffff800`2f3fab90 : nt!KiCallInterruptServiceRoutine+0xa5
fffff800`32a7bf90 fffff800`2f3f5c27 : fffff800`32a6caf0 00000000`00000001 00000000`00040046 fffff800`2f307018 : nt!KiInterruptSubDispatchNoLock+0x11c
fffff800`32a6c9d0 fffff800`2f3f79ca : 00000000`00000000 fffff800`2fd26600 ffffe001`81e9c100 00000000`00000382 : nt!KiInterruptDispatchNoLock+0x37
fffff800`32a6cb60 00000000`00000000 : fffff800`32a6d000 fffff800`32a66000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a
SYMBOL_NAME: nt!IvtHandleInterrupt+1a7
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
IMAGE_VERSION: 10.0.19041.508
STACK_COMMAND: .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET: 1a7
FAILURE_BUCKET_ID: 0xE6_nt!IvtHandleInterrupt
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {2cafa897-b47c-7b20-cee6-b1b68f30ec38}
Followup: MachineOwner
---------
0: kd> dt (nt!_DEVICE_OBJECT)(0xffffe00193f74670)
+0x000 Type : 0n3
+0x002 Size : 0x878
+0x004 ReferenceCount : 0n0
+0x008 DriverObject : 0xffffe001`81d06da0 _DRIVER_OBJECT
+0x010 NextDevice : 0xffffe001`93ebb6c0 _DEVICE_OBJECT
+0x018 AttachedDevice : 0xffffe001`94003050 _DEVICE_OBJECT
+0x020 CurrentIrp : (null)
+0x028 Timer : (null)
+0x030 Flags : 0x1040
+0x034 Characteristics : 0x100
+0x038 Vpb : (null)
+0x040 DeviceExtension : 0xffffe001`93f747c0 Void
+0x048 DeviceType : 4
+0x04c StackSize : 1 ''
+0x050 Queue : <anonymous-tag>
+0x098 AlignmentRequirement : 0
+0x0a0 DeviceQueue : _KDEVICE_QUEUE
+0x0c8 Dpc : _KDPC
+0x108 ActiveThreadCount : 0
+0x110 SecurityDescriptor : 0xffffce01`23a51f60 Void
+0x118 DeviceLock : _KEVENT
+0x130 SectorSize : 0
+0x132 Spare1 : 1
+0x138 DeviceObjectExtension : 0xffffe001`93f74ee8 _DEVOBJ_EXTENSION
+0x140 Reserved : (null)
0: kd> dx -id 0,0,ffffe001802bc240 -r1 ((ntkrnlmp!_DRIVER_OBJECT *)0xffffe00181d06da0)
((ntkrnlmp!_DRIVER_OBJECT *)0xffffe00181d06da0) : 0xffffe00181d06da0 : Driver "\Driver\pci" [Type: _DRIVER_OBJECT *]
[<Raw View>] [Type: _DRIVER_OBJECT]
HardwareDatabase : 0xfffff8002fd2c988 : "\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM" [Type: _UNICODE_STRING *]
DeviceObject : 0xffffe00193f7c670 : Device for "\Driver\pci" [Type: _DEVICE_OBJECT *]
Flags : 0x412
Devices
0: kd> dx -id 0,0,ffffe001802bc240 -r1 ((ntkrnlmp!_DEVICE_OBJECT *)0xffffe00194003050)
((ntkrnlmp!_DEVICE_OBJECT *)0xffffe00194003050) : 0xffffe00194003050 : Device for "\Driver\stornvme" [Type: _DEVICE_OBJECT *]
[<Raw View>] [Type: _DEVICE_OBJECT]
Flags : 0x50
UpperDevices : None
LowerDevices : Immediately below is Device for "\Driver\pci" [at 0xffffe00193f74670]
Driver : 0xffffe00181d66270 : Driver "\Driver\stornvme" [Type: _DRIVER_OBJECT *]
Continue reading...
I'm trying to figure out why recent Windows 10 (OS builds 19041.508 and 19041.572, i.e. September and October updates) bugcheck with Stop code DRIVER_VERIFIER_DMA_VIOLATION whenever I connect this portable NVMe SSD (LaCie Rugged Pro) via Thunderbolt 3. (The SSD internal to the drive is a Seagate Firecuda.)
Yes, I have done sfc/scannow, dism, and even a full Reset. Only rolling back the updates or reinstalling from scratch worked. Connecting the device does not cause a bugcheck on earlier updates (tested OS builds 19041.264, 19041.329, 19041.388, and 19041.450), and it definitely does work perfectly fine as a storage device on these versions, so for now I'm stuck on the August update.
Looking at the modified files list from the September update relative to the August update, there seem to be a bunch more files. Nothing seems relevant to me from the list except maybe stornvme.sys...
The bugcheck occurs midway during startup if the drive is connected before power-on. If connected after startup, it bugchecks right as the third "device connected" sound plays. (When it works, it plays the sound 3 times.)
I don't have any other TB3 NVMe drives to try, but I do have a TB3-attached eGPU which is working fairly well (on all OS builds). As much as I don't trust Thunderbolt, my hunch is that it is not the issue here.
In all these tests, Driver Verifier was disabled, so despite the stop code, it's not actually Driver Verifier. Turning it on seemed to have no effect (though I haven't tried every combination yet).
The Stop error screen does not blame a particular driver, simply "DRIVER_VERIFIER_DMA_VIOLATION".
Poking at the memory dump in WinDbg (as far as I feel comfortable, for now), !analyze -v doesn't blame any particular driver. For the bugcheck itself, Arg1 is 0x26 (IOMMU detected DMA violation), Arg2 (nt!_DEVICE_OBJECT) has DriverObject "\Driver\pci", AttachedDevice's Driver is "\Driver\stornvme", which I think confirms this is triggered by attaching the NVMe device, and is maybe evidence that there's a new bug in stornvme.sys (but what would I know).
Any more hints of things to try or look at? (Do I have to upload the memory dump?)
Microsoft (R) Windows Debugger Version 10.0.20153.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\MEMORY.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff800`2f000000 PsLoadedModuleList = 0xfffff800`2fc2a310
Debug session time: Sat Oct 17 17:51:25.813 2020 (UTC + 11:00)
System Uptime: 0 days 0:00:06.480
Loading Kernel Symbols
...............................................................
...............Page 841516 not present in the dump file. Type ".hh dbgerr004" for details
.................................................
.....................................
Loading User Symbols
Loading unloaded module list
......
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff800`2f3f3ea0 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffff800`32a7beb0=00000000000000e6
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_VERIFIER_DMA_VIOLATION (e6)
An illegal DMA operation was attempted by a driver being verified.
Arguments:
Arg1: 0000000000000026, IOMMU detected DMA violation.
Arg2: ffffe00193f74670, Device Object of faulting device.
Arg3: 0000000000000001, Faulting information (usually faulting physical address).
Arg4: 0000000000000005, Fault type (hardware specific).
Debugging Details:
------------------
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2015
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on JOSH-MBP-W
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 2001
Key : Analysis.Memory.CommitPeak.Mb
Value: 88
Key : Analysis.System
Value: CreateObject
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
BUGCHECK_CODE: e6
BUGCHECK_P1: 26
BUGCHECK_P2: ffffe00193f74670
BUGCHECK_P3: 1
BUGCHECK_P4: 5
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
PROCESS_NAME: System
STACK_TEXT:
fffff800`32a7bea8 fffff800`2f4da6e7 : 00000000`000000e6 00000000`00000026 ffffe001`93f74670 00000000`00000001 : nt!KeBugCheckEx
fffff800`32a7beb0 fffff800`2f4c660b : 00000000`00000000 00000000`00000000 fffff800`2fc49c30 fffff800`2fc49c30 : nt!IvtHandleInterrupt+0x1a7
fffff800`32a7bf10 fffff800`2f280795 : fffff800`2fcf3a80 fffff800`32a6ca50 fffff800`2fcf3b30 fffff800`32a7bfc0 : nt!HalpIommuInterruptRoutine+0x4b
fffff800`32a7bf40 fffff800`2f3f581c : fffff800`32a6ca50 fffff800`2fcf3a80 00000000`00000382 fffff800`2f3fab90 : nt!KiCallInterruptServiceRoutine+0xa5
fffff800`32a7bf90 fffff800`2f3f5c27 : fffff800`32a6caf0 00000000`00000001 00000000`00040046 fffff800`2f307018 : nt!KiInterruptSubDispatchNoLock+0x11c
fffff800`32a6c9d0 fffff800`2f3f79ca : 00000000`00000000 fffff800`2fd26600 ffffe001`81e9c100 00000000`00000382 : nt!KiInterruptDispatchNoLock+0x37
fffff800`32a6cb60 00000000`00000000 : fffff800`32a6d000 fffff800`32a66000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a
SYMBOL_NAME: nt!IvtHandleInterrupt+1a7
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
IMAGE_VERSION: 10.0.19041.508
STACK_COMMAND: .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET: 1a7
FAILURE_BUCKET_ID: 0xE6_nt!IvtHandleInterrupt
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {2cafa897-b47c-7b20-cee6-b1b68f30ec38}
Followup: MachineOwner
---------
0: kd> dt (nt!_DEVICE_OBJECT)(0xffffe00193f74670)
+0x000 Type : 0n3
+0x002 Size : 0x878
+0x004 ReferenceCount : 0n0
+0x008 DriverObject : 0xffffe001`81d06da0 _DRIVER_OBJECT
+0x010 NextDevice : 0xffffe001`93ebb6c0 _DEVICE_OBJECT
+0x018 AttachedDevice : 0xffffe001`94003050 _DEVICE_OBJECT
+0x020 CurrentIrp : (null)
+0x028 Timer : (null)
+0x030 Flags : 0x1040
+0x034 Characteristics : 0x100
+0x038 Vpb : (null)
+0x040 DeviceExtension : 0xffffe001`93f747c0 Void
+0x048 DeviceType : 4
+0x04c StackSize : 1 ''
+0x050 Queue : <anonymous-tag>
+0x098 AlignmentRequirement : 0
+0x0a0 DeviceQueue : _KDEVICE_QUEUE
+0x0c8 Dpc : _KDPC
+0x108 ActiveThreadCount : 0
+0x110 SecurityDescriptor : 0xffffce01`23a51f60 Void
+0x118 DeviceLock : _KEVENT
+0x130 SectorSize : 0
+0x132 Spare1 : 1
+0x138 DeviceObjectExtension : 0xffffe001`93f74ee8 _DEVOBJ_EXTENSION
+0x140 Reserved : (null)
0: kd> dx -id 0,0,ffffe001802bc240 -r1 ((ntkrnlmp!_DRIVER_OBJECT *)0xffffe00181d06da0)
((ntkrnlmp!_DRIVER_OBJECT *)0xffffe00181d06da0) : 0xffffe00181d06da0 : Driver "\Driver\pci" [Type: _DRIVER_OBJECT *]
[<Raw View>] [Type: _DRIVER_OBJECT]
HardwareDatabase : 0xfffff8002fd2c988 : "\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM" [Type: _UNICODE_STRING *]
DeviceObject : 0xffffe00193f7c670 : Device for "\Driver\pci" [Type: _DEVICE_OBJECT *]
Flags : 0x412
Devices
0: kd> dx -id 0,0,ffffe001802bc240 -r1 ((ntkrnlmp!_DEVICE_OBJECT *)0xffffe00194003050)
((ntkrnlmp!_DEVICE_OBJECT *)0xffffe00194003050) : 0xffffe00194003050 : Device for "\Driver\stornvme" [Type: _DEVICE_OBJECT *]
[<Raw View>] [Type: _DEVICE_OBJECT]
Flags : 0x50
UpperDevices : None
LowerDevices : Immediately below is Device for "\Driver\pci" [at 0xffffe00193f74670]
Driver : 0xffffe00181d66270 : Driver "\Driver\stornvme" [Type: _DRIVER_OBJECT *]
Continue reading...