When nothing works: a step-by-step DMA checklist
Test a build that does nothing, layer by layer. Check in order: card powered, enumerated, driver bound, reader connected, DTB found, process found, features drawing, cursor moving, overlay visible.
Short answer
Test the nine links in order: card powered, card enumerated, driver bound, reader connected, DTB found, process found, features drawing, cursor moving, overlay visible. Stop at the first link that fails and work on that one, because every link after it fails regardless.
On this page8
Why testing in order beats guessing
A DMA build is a chain of nine dependencies, and a failure at link two produces symptoms at link seven. That is why changing settings at random feels like progress but is not: you are adjusting links that were never going to run. The method is boring, and it always works: test each link in order, stop at the first one that fails, and fix only that. Everything further down the chain is noise until that link passes.
The nine links, in order
Read this list once before you start, and keep to its order, because each link depends on the one above it being true.
- 1. Card powered
- The game PC is on and the card's own LEDs behave as the board maker documents
- 2. Card enumerated
- The second PC shows a new USB device when the card's data cable is plugged in
- 3. Driver bound
- That device is the FT601 bridge with no warning triangle in Device Manager
- 4. Reader connected
- The software gets past the device stage with no FT601 or PCIe ID error
- 5. DTB found
- Initialisation completes: no "Unable to locate valid DTB" line
- 6. Process found
- The game is running and the software resolves it and its base address
- 7. Features drawing
- The software's own preview or radar shows live data, on the second PC's screen
- 8. Cursor moving
- The box moves the cursor on the GAME PC, tested on the desktop first
- 9. Overlay visible
- The display path carries the picture and the overlay lands where it should
How to test each link
Make one pass from top to bottom and write down where it stops. That single sentence is worth more than everything else in a ticket.
- Cold-boot both machines properly, with a full power-off for ten seconds and the game PC first, so you are not testing a hung card
- Link 1: with the game PC at the desktop, look at the card's LEDs. If they are dark, the cause is the slot or the seating, not the software
- Link 2: unplug and replug the card's data cable at the second PC while watching Device Manager, where something must appear and disappear. If nothing does, the cause is the port, the cable, or the port you chose on the card
- Link 3: confirm the new device is the FTDI FT601 bridge with no warning triangle. A triangle or an unknown device means you need to install the D3XX driver and replug
- Link 4: start the software and read only the first error. A device or PCIe ID error stops you here, so do not read further down the log
- Link 5: if initialisation mentions DTB, stop and follow the DTB error guide in order: memory map, then BIOS virtualisation, then USB stability, then cold boot
- Link 6: start the game, reach the main menu and confirm the software resolves the process. A base-address failure at this link usually means a stale or missing memory map
- Link 7: check the software's own on-screen data on the SECOND PC before you involve any display hardware. If the data is live there, the card side is finished and every remaining problem is in the output
- Link 8: with the box's HID cable in the game PC, move the cursor on the game PC's desktop. Test outside a game first, because if it does not move there, it will not move in a game either
- Link 9: only now bring in the fuser or capture path. Rebuild the video chain one cable at a time, starting with the game PC connected directly to the monitor
Warning
Why only the first failing link matters
If the card never enumerates, no BIOS setting, memory map, driver reinstall or firmware reflash can change that. Every hour spent on them goes to a link the build never reaches. On the other hand, if live data is already drawing on the second PC, the card, the USB path, the DTB and the process are proven. The problem is then entirely in the output half of the build.
What to read next for each failing link
Take the link number where your pass stopped and start with the guide in the right-hand column.
| Stops at | What it means | Read next |
|---|---|---|
| 1 — card not powered | Slot, seating or the game PC itself | The card install and BIOS pages, then a different PCIe slot |
| 2 — never enumerates | Port, cable, or the wrong socket on the card | The FTDI driver page, then the dropout diagnosis page |
| 3 — driver not bound | Windows bound nothing or bound the wrong thing | The FTDI driver page: uninstall with the driver ticked, replug, reinstall |
| 4 — reader cannot connect | Layer 1 is incomplete, or a library file is missing | The error index, layer 1 rows |
| 5 — DTB | Memory map, virtualisation, or read stability | The dedicated DTB page, in that order |
| 6 — process or base address | Stale memory map, or the game was not fully started | The memory-map page, then regenerate the map |
| 7 — no live data | Initialisation passed but the feature layer is not configured or is out of date for the game build | The status page for your game, then a ticket with the exact string |
| 8 — cursor does not move | Input device wiring or port configuration | The error index, layer 3 rows |
| 9 — no overlay | Video chain, EDID or resolution mismatch | The error index, layer 4 rows |
If you cannot say which number you stopped at, you have not run the pass. That is the most common reason a ticket takes a week.
Have these ready before you start
- A known-good short USB 3 data cable, set aside as your reference cable
- Physical access to the game PC, so you can reseat the card without rushing
- The board maker's LED documentation, or a photo of the card's LEDs from when it last worked
- Both Windows build numbers, noted from winver
- Somewhere to write down which link failed and the exact error string
- One hour with nothing else running on either machine
Tip
Change one thing at a time
Five changes followed by one retest is not a test. Suppose you swap the cable, change the port, disable virtualisation and regenerate the map at the same time, and the build starts working. You have learned nothing, and you cannot reproduce the fix after the next Windows update. Make one change, retest once and write one note: it feels slower for the first twenty minutes but is faster by the end of the evening.
Common questions about the checklist
Everything passes but the game shows nothing. Where am I?
Link 7. The hardware half is proven, so the remaining causes are software configuration or a game build that the feature layer has not been updated for. Check the status page for your game before you open a ticket.
Can I skip to the link I think is broken?
You can, and that is how most people waste an evening. The whole value of the pass is that it finds the link that really fails first, rather than the one you suspect.
How long should the whole pass take?
Twenty minutes on a working build, or longer if you stop early. If you are past an hour and have not identified a link, note where you are and open a ticket with that information.
Do I need the game running for the first six links?
Only from link 6 onward. Links 1 to 5 can all be tested with the game closed, which is the cleaner way to test them.
Is a clean Windows install ever the right first step?
No. It changes every variable at once and fixes none of the common causes. It belongs at the end of the list, after the map, BIOS, cable and cold boot have all been tested.
Sources
This is the order in which the team works through a dead build, and the nine links come from tickets rather than from a published document.
Read next
Still stuck? Open a ticket on Discord
All guides