1

Topic: HDSPe causes BSOD Driver Verifier DMA Violation with Thunderbolt 3

Update: fixed in driver version 4.36 (HDSPe) and 2.16 (HDSPe FX), 12/09/2020, for TB3 expansion chassis - registry mod no longer necessary. For systems with TB3 to TB2 conversion read on.

This is information from this thread:

https://forum.rme-audio.de/viewtopic.ph … 30#p150430

Using a newer computer with a second or later generation Thunderbolt 3 implementation, a TB3 to TB2 adapter (Startech or Apple) and a Sonnet Echo TB2 to ExpressCard adapter, or any TB2 to PCIe chassis, Windows throws a Blue Screen Of Death with Driver Verifier DMA Violation warning.

This issue seems not present on first generation Thunderbolt 3 implementations (the Thunderbolt Control Center is also different, and the Apple adapter won't work with that hardware).

Remedy (special thanks to forum user glittle):
It seems the BSOD caused by some strange interaction (because this issue has nothing to do with DMA) of the DMA Verifier process can be disabled via a registry entry.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\pci\Parameters\DmaRemappingCompatible

is set to 0x00000002(2) by default. This has to be changed to 0x00000000(0).

There is advice to change a second entry as well:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\USBXHCI\Parameters\DmaRemappingCompatible

which might not be necessary (at least it wasn't on our test systems), but as it could only improve reliability there is no reason not to change it as well.

Be careful with registry modifications as these can destroy your Windows installation easily! If you feel unsure let someone do it who knows this stuff!

Regards
Matthias Carstens
RME

2

Re: HDSPe causes BSOD Driver Verifier DMA Violation with Thunderbolt 3

This is current and additional information to post 1. As mentioned driver version 4.36 (HDSPe) and 2.16 (HDSPe FX) include a fix that prevents a Bluescreen crash BSOD Driver Verifier DMA Violation when booting or wakeup from sleep with later TB3 equipped computers and connected TB3 expansion chassis having one of our PCIe cards in it. The first generation of TB3 equipped computers did not show such a behaviour.

Unfortunately this is not a final fix for any possible setup, because that BSOD can also happen outside of (means without any) RME driver. It then happens within the active Thunderbolt or PCIe driver, from Intel or Microsoft. An easily to reproduce scenario:

- use a newer TB3 equipped computer
- connect a TB3 to TB2 adapter, Startech or Apple
- connect the old Sonnet Echo Pro, TB2 to ExpressCard (or any other TB2 equipped PCIe chassis)
- insert the HDSPe ExpressCard (for Multiface etc) or the MADI ExpressCard (MADIface), or an ExpressCard for the PCIe connector of the MADIface XT: immediate crash, although no RME driver has ever been installed, and thus no DMA transfer ever happened.

The HDSPe ExpressCards can be used by updating to a true TB3 system, like using the Sonnet SE1 or a Netstor chassis etc, and an adapter card PCIe to ExpressCard (if you are lucky to still find one).

But the most easy solution ist still changing the value 2 into 0 for the PCI registry entry, as described in post 1, which works also with the Echo Pro adapter.  Just note that removing the ExpressCard without first deactivating it in the Device Manager might give you 100% CPU load on all cores, until you plug it back in again.

As summary we have to state that currently on Intel Windows machines TB3 is no longer fully compatible to TB2, unless you apply the above registry tweak.

Regards
Matthias Carstens
RME