Apollo 8 Offline (No Host Light) via Jumpered Titan Ridge v2 on ASUS X99-A II - PCI Max Data Size reads All Zeros

Hello everyone,

I am attempting to run a legacy Universal Audio Apollo 8 (Rackmount Blackface with an official TB2 Option Card) on a Windows 10 x64 Pro workstation. I am hitting a brick wall where the hardware is fully detected by the OS, but the front-panel HOST light remains completely unlit, and the UAD Meter reports no devices found.

The Twist / Core System Issue:

The native THB_HEADER block on my ASUS X99-A II motherboard is physically dead. To bypass this, I purchased a Gigabyte GC-Titan Ridge 2.0 PCIe card and am running it via the enthusiast standalone header hack (Pins 3 and 5 jumpered) to force-power the Intel JHL7540 chipset.

My Exact Hardware & Cable Topography:

CPU: Intel Core i7 / Xeon (X99 Platform)

Motherboard: ASUS X99-A II (BIOS configured: VT-d Enabled, Intel Virtualization Enabled, Slot PCIEX16_4 manually forced to X8 Mode, ASMedia USB 3.1 Controllers Enabled)

Thunderbolt Card: Gigabyte GC-Titan Ridge v2.0 seated in the bottom PCIEX16_4 slot. Internal USB 2.0 header connected, dual 6+2 PCIe power cables firmly connected.

Cable Chain: Apollo 8 TB2 Option Card → Official Apple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter → Titan Ridge Port 2 (Type-C)

DAW: Cubase Pro 15

Current OS Behavior & Diagnostic Data:

Device Manager Recognition: The card is recognized perfectly under System Devices as Thunderbolt™ Controller - 15EB. It runs cleanly on the official manual driver injection v1.41.890. Furthermore, the Audio DSP Accelerator (UAD-2 System Driver) appears under its own branch with a healthy status and no warning triangles.

Intel Software Recognition: The modern Intel Thunderbolt Control Center DCH app cleanly discovers the peripheral. It explicitly identifies it as the “UAD TB2 Option Card” and marks it with an un-clickable status of “Connected” (bypassing manual approval via Windows Kernel DMA/Secure Connect).

The Shifting Port Behavior: When testing the physical ports, plugging the Apple adapter into the top Type-C port shifts the device tree dynamically to Port 1 in the Intel App. Plugging it into the bottom Type-C port shifts the device tree instantly to Port 2.

The Ultimate Smoking Gun: Digging into the Device Manager > Thunderbolt Controller > Details tab and evaluating the hardware registers reveals that the PCI Max Data Size / Max Payload Size is reading entirely as ALL ZEROS (00000000).

The Problem:

Despite the physical layer layout reporting total connection health across Port 1/2, the UAD framework is completely blind to it. The HOST light stays dark, and opening the UAD Meter or launching Cubase Pro 15 yields no available Universal Audio Thunderbolt ASIO or WDM drivers whatsoever.

I have already attempted deep software purges, clearing %appdata% Universal Audio preferences caches (UAD Meter.ini), executing precise hardware boot timing sequences (Apollo stabilized first for 15 seconds, then cold booting the PC), and running an absolute hardware EEPROM reset on the Apollo front panel (holding Meter + Monitor during power up - the LEDs flashed rapidly as expected, but yielded no change upon reboot).

Because the Max Data Size register is flagged as all zeros, it appears the ASUS X99 firmware is automatically quarantining the jumpered, un-headered card at boot and scaling the Transaction Layer Packet (TLP) width down to zero bytes to protect system RAM stability. This completely starves the real-time audio core streaming engine (UAMixerEngine.exe) of the Direct Memory Access (DMA) address space it needs to pass the initial handshake code to the Apollo’s internal firmware.

Before I officially give up on this Thunderbolt architecture and swap the Apollo 8 out for a native high-bandwidth USB 3.x interface (like a MOTU 828) to run on my working 10Gbps ASMedia rear ports, has anyone successfully forced a Windows Registry or BIOS override to inject a valid PCIe payload size (like 128 or 256 bytes) onto an un-headered, jumpered Titan Ridge card? Or is custom-flashing the card’s physical NVM EEPROM chip with modified firmware the only way to lift this X99-level DMA lock?

Any advice, microcode tweaks, or Registry hacks would be greatly appreciated!