The five tickets we get every week

Support volume in this field is not evenly spread. Five patterns account for most of what arrives, in almost identical wording every week, and all five have a fix shorter than the ticket describing them. Publishing them costs us nothing and can save you an evening. So here they are with the diagnosis attached, because the remedy alone is what makes people try all five in random order.

Roughly in the order they arrive. The first three are all the USB path, which is where most first builds die.

1. The cable is in the flashing port

Almost every current board has two USB-C sockets, and they are not interchangeable. One drives the flashing bridge, which is used to write firmware and read the DNA ID, and the other drives the data bridge that the second PC reads memory through. Plug into the flashing socket and a completely healthy card shows lights and nothing on the second PC, which first-timers read as a dead board. Where the sockets are unlabelled, the data port is generally the one further from the PCIe fingers, but the board maker's own marking wins whenever there is one.

2. The cable cannot carry data

The second most common cause is the cheapest part of the build. A USB-C cable sold for charging may have no usable data pairs, and a thin one that does have them will not hold a USB 3 link under sustained reads. The failure is not always a clean absence either. A marginal cable produces a device that enumerates, works for ten minutes and then disappears mid-read, which sends people hunting for a software cause. Before diagnosing anything else, go direct to a rear motherboard port with a short data-rated cable. Take hubs, docks and extensions out of the path for the first test.

3. The FTDI driver is missing

The data bridge on these boards is an FTDI part, so the second PC needs the FTDI D3XX driver to talk to it. Without it, reader software reports that it cannot connect to USB or to the FT601, which reads like a hardware failure and is not one. Install the version issued with your order rather than the newest one you can find. A newer driver against an older reader build is a known source of failures that are hard to reproduce and harder to describe in a ticket. If Windows bound a generic driver first, uninstall the device with the delete-driver option ticked. Then unplug, reboot, install and replug.

4. There is no memory map

A memory map records how the game PC translates physical memory, so the reader finds what it needs instead of scanning for it. Without one, a build with a healthy read rate still feels slow, and DTB or base-address errors appear as soon as anything moves. The map belongs to that Windows install, that RAM layout and that BIOS, so it is not portable between machines and it goes stale. Regenerate it after a Windows update, a BIOS update or a CMOS reset. Do the same after RAM has been added or reseated, and whenever a working overlay stops after a system change. Generate it at the desktop with the game and its anti-cheat closed, and put the file where your loader expects it, under exactly the expected filename.

5. Virtualisation is still on in the game PC

The last pattern is the one to handle most carefully. Memory-reading hardware interacts with a machine's virtualisation and IOMMU settings, so a build can be entirely correct and still read nothing because of a BIOS toggle. The wrong response is to work through a checklist from a forum post. Several of those settings are enforced by the titles themselves, and at least one major title now requires some of them for tournament play. Changing them blind breaks Windows or the game rather than fixing the build. Use the settings named in your order's instructions, change one thing at a time, and write down what you changed.