Okay, I found and tried a second HDSPe expresscard, this time with a serial number that is not on the recall list.  However, it does the same thing:

+ when computer already booted:  StarTech (already plugged in to Sonnet with expresscard) crashes the computer a few seconds after being plugged in.

+ when booting with the whole chain already plugged in:  errors during boot, multiple boot tries, eventually just get a "repair" screen.  I never get a full boot into win10.

If I do the exact same thing with the hdsp cardbus in a cardbus/expresscard adapter (then through the same Sonnet and StarTech into thunderbolt2 on laptop) then there is no crash, and the interface works (not fully functional, but it does pass some audio and midi fine... it just crackles a ton when enabling more than a handful of I/O).  No windows crashes, and the interface largely acts like an interface, I can change buffer size parameters, Totalmix appears to act normally, etc.

Mattias, does this ring any bells?  I'm trying to decide if I have a case for returning the laptop to Dell as having a not-fully-functional thunderbolt port, but I can't tell if that's actually true.  I'm very confused that the cardbus in the expresscard adapter works... would that not indicate that the thunderbolt port is okay?  Yet, two different HDSP expresscards do the exact same blue-screen thing.

I'm confused, and not sure which item to consider non-workable and just thinking in circles now.  Return the laptop if possible?  It's a beast, other than this.  Or give up on the expresscard and assume the TB subsystem is probably fine for non-edge-case uses?

Thanks in advance for any thoughts or insights.

I am not from RME. But the cardbus and expresscard should both perform the same and 100% good. The fact that the cardbus has issues too points to a problem. But it can be the laptop and all adapters. Except when some worked in another system, then you know those  are 99.9% certain, ok.
Any chance to do a clean install of windows or even windows 7? That would at least exclude the OS as the source of the problem. Oh and do check the bios first! There might be TB related settings there that might help.

Regarding the crash errors:

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
DRIVER_VERIFIER_DMA_VIOLATION

I got a message from Dell suggesting a registry entry or two to check and possibly modify.  Will have at that when next home.

Ugh... in that case is there anything to do other than wait for Dell/Intel to fix (or not)?  Unfortunately, the registry edits the Dell tech suggested were either not there for me to edit, or the one edit I did make didn't change the bluescreen behavior.

Just FYI, they suggested I try turning off DmaRemappingCompatible for asmtxhci and usbxhci.  I do not have any such settings available for asmtxhci under ControlSet001\Services, but the USBXHCI\Paramaters copy of DmaRemappingCompatible was set to 2, so I set it to 0.  After reboot, expresscard still bluescreens when plugged in.

Also, I tried taking "OFFLINE" out of the paths below (since I don't even have that) to see if I could find the asmtxhci settings, but it wasn't there either.  These two Dell suggested I change value to 0:

[HKEY_LOCAL_MACHINE\OFFLINE\ControlSet001\Services\asmtxhci\Parameters]  "DmaRemappingCompatible"
[HKEY_LOCAL_MACHINE\OFFLINE\ControlSet001\Services\USBXHCI\Parameters]  "DmaRemappingCompatible"

This is the location where I did change DmaRemappingCompatible:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\USBXHCI\Parameters

I'm definitely interested in the results of your investigation.

-glenn

Is your feeling that the problem is likely to be the Dell, or the expresscard/drivers, or the adapter chain?  I know there's no way to state categorically, but I'm nearing a point where I need to decide if I want to try to argue with Dell that the Precision 7740 is in fact not suitable (as in, the TB3 subsystem is not compliant in some way that it should be).  The alternative is to just give in and go with the chain I have:

7740 TB3 -> StarTech -> Sonnet Echo -> cardbus/expresscard adapter -> HDSP-cardbus card.

This surprisingly works, even at 32-sample buffers, with a couple of caveats (big one being that at 5 audio outs activated it works, but at 6 it fails nearly completely).

I am still also dealing with occasional DPC latency glitches (I assume that's the cause), I think because small buffers are more sensitive.  But turning off C-States along with a number of other tweaks make those less frequent, and at this point they are 85% limited to CPU0, so I can turn off CPU0 affinity for Cubase and stay mostly away from audio glitches.

I have also managed to try a BabyFace Pro, and it has similar behavior with the occasional (every 1 to 3 minutes) audio glitches, and is similarly calmed by forcing Cubase cpu affinity.

The question I'm working with now is whether or not I am "trying too hard" with the 7740, and if I do indeed return that, how hard would it be to find something else that works.  Same issues I dealt with 11 years ago when I bought the last laptop... my how things don't change. :-)

Ha!  Right.  Well, here is some interesting new information. I need further testing to confirm, but at this point a couple of things appear to actually make a difference.

1) Expresscard-over-Thunderbolt crashes computer: It turns out that if I edit two values in the registry, setting them both to 0, then the HDSP Express seems to work fine. The two values:

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

That's it.  I don't know what the possible other ramifications of this are (less secure machine?  will future software, drivers, or updates fail to work?), but changing those two from "2" to "0" makes the expresscard-over-TB work, and work better than the cardbus-over-TB.

2) Infrequent but not non-existent audio glitches: As many others, I tried all kinds of BIOS and System and Power settings to get rid of the DPC latencies.  What finally seems to have eliminated nearly all of the medium-to-long ones off was to actually physically disconnect and remove the battery.

Since I tried many other things as well (C-States disabled, disabled onboard graphics, lots of Device Manager settings), I'd like to try resetting some of those back to default and see how much of the problems really have been just due to the battery.

What that means, I don't know.  Bad battery?  Or drivers that aren't getting (or ignoring) the message to stop paying attention to the battery when plugged in to mains power?

More extensive testing to confirm these results as soon as I have time.

As for whether I like either one of these as a long-term solution, I don't yet know.  I consider both to be hacky and probably not without their own risks or downsides.  But it's interesting anyway.

And another follow-up: some updates over the last months, most probably BIOS updates, have worsened the low latency performance of the Dell XPS15 7590 to an unacceptable level. The infamous ACPI.sys stops the system for around 2 ms every few minutes, sometimes even higher. Dropout-free operation thus requires 1048 samples in single speed, 2048 samples in double speed. And yes, that's quite ridiculous!

Similar to glittle I tried a lot of BIOS settings changes and known tricks, to no avail. I did not disconnect the battery so far, though. But I disabled the two power supply/battery related entries in the Device Manager, a workaround that was helpful years ago with similar problems. Unfortunately it didn't change anything.

ACPI.sys is NOT a Windows (or Microsoft) problem, it is a BIOS problem! Thanks Dell, once again...

The 7590 seems to have a battery control problem as well. This is my test: start Latency Monitor, unplug the power supply. ACPI.sys DPC will peak between 5 ms and 14 (!) ms. Same when resetting LM and plugging in the power supply.

When I do this test with my former XPS15 9550 NOTHING happens at all!

Disabling the ACPI battery control or the power supply (both in Device Manager under Batteries) and S3 states off doesn't change anything. At this time the XPS15 7590 is clearly screwed up.

I just recently had to fully re-install windows, and thank you Dell and Windows (sarcasm): recent updates to win10 broke what was working great in win10 1909 and older.  I previously reported above that it was effective to disable the battery and disable CSTATES in order to control the DPC latency spikes.  Unfortunately, this stopped working.

I am testing a possible workaround and will report back here on that shortly.

In the mean time, as part of the reinstall, I finally updated my RME hdspe drivers to v4.36.  My connection chain is:

Dell Precision7740 TB3 -> StarTech -> Sonnet Echo -> cardbus/expresscard adapter -> HDSP-cardbus card

I can confirm that now, *without* the registry edits mentioned earlier in this thread, I can boot the machine with the multiface connected, and it comes up okay.

What I still cannot do (without the registry edits) is to disconnect the working Multiface via the thunderbolt connect and then reconnect, all while win10 is up and running.  When I try this, I get the same DMA bluescreen.

With the registry edit(s) though, I can disconnect and reconnect at will.

I'm going to do some LatencyMon tests and see what can be done to get the machine back and workable as an audio workstation and report back here.