Fusion - the Fusion 360 Bridge

Update: likely a GPU crash, not just tour logic

The user re-ran the tour after a reboot and Fusion Electronics stopped with:

Unexpected Condition details: File: R:\Electron\EAGLE\SkiaBridge\SkiaWindowContextDx12.cpp, Line 1022. Condition: Unrecoverable d3d12 error!

Windows logged GPU hang/reset events at the same time (Application log, LiveKernelEvent):

• 17:06:12, 17:06:15, 17:07:56 local: 141 (VIDEO_ENGINE_TIMEOUT_DETECTED) several times, plus one 193 (VIDEO_DXGKRNL_LIVEDUMP)

Machine:

• GMKtec NucBox9, Ryzen 5 5600U, built-in Radeon (driver 31.0.21924.61), video memory raised from 512 MB to 2 GB earlier today
• 3 monitors: one on the AMD output, two through DisplayLink USB (driver 12.1.2591.0)
• The Fusion window was on a DisplayLink monitor (left screen) when it crashed

So the black panels and the display lagging behind the narration in the first report are probably the same failure: the Electronics canvas (Skia on D3D12) loses its GPU device and stops drawing while the tour's narration keeps going.

Suggestions for the tour:

• Detect a lost or stalled canvas (for example, canvasColours collapsing, or the d3d12 error dialog appearing) and pause the tour with a clear message, instead of narrating over a dead view.
• Warn before starting when Fusion's window is on a DisplayLink/indirect display, or when the GPU has under 1 GB of video memory.

Second run (show-57269abc): Fusion on the AMD-wired monitor

Fusion was moved to the monitor wired directly to the AMD GPU (not DisplayLink) and the tour was run again. It reached the end ("6 of 8 beats") but:

• The d3d12 dialog came back during step 1. Screenshots at 2/8 and 3/8 show the "Unrecoverable d3d12 error" dialog over a black Electronics canvas.
• symbol and footprint failed with Could not make AdomDemoSample.lbr the ACTIVE document (active: 'None'), so EDIT was not issued. The narration still played the symbol and footprint captions for about 2½ minutes each over a view that never changed. This is the "narrative describes something that isn't displayed" the user reported, and it's a tour bug regardless of the GPU: a failed beat should say so (or pause), not narrate it.
• chip and board3d reported viewChanged: false, so the 3D orbits didn't move the view either.
• schematic and board2d worked once the GPU settled.

Windows Application log (LiveKernelEvent) shows bursts every 15–40 s from 17:14:47 to 17:19:20, ending around the tour's first step:

• 144 (BUGCODE_USB3_DRIVER), dozens per burst
• 141 / 117 (GPU engine timeout / TDR)
• 193 (DXGKRNL live dump), a1000001

The USB3 events (144) alongside the TDRs point at the DisplayLink USB adapters destabilising the whole graphics stack, which would explain why moving Fusion to the AMD screen didn't help. We'll retest with the DisplayLink adapters unplugged.

Thanks for the detailed logs, Muzzer. They made all four tour bugs easy to pin down.

The GPU side. Your diagnosis looks right to us. The d3d12 error, the TDRs and the USB3 bursts point at the DisplayLink adapters, and the black panels are Fusion's Electronics canvas losing its GPU device. That is below the bridge, so the retest with the adapters unplugged is the right next step.

The tour side is fixed in fusion-bridge 1.11.41, which is on the insiders channel now and goes public after sign-off:

1. A failed beat no longer narrates. If a beat's action fails, its view can't be confirmed on screen, or its motion never moves the view (after one retry), the narration and fillers stop at once. The caption then says the step failed and why, and the tour moves on. viewChanged now counts any frame after a gesture, not only the last one, because some motions end on the view they started from. Your "symbol and footprint narrated for 2.5 minutes" case now cuts off when the step fails. Fillers can still play while a long step is running, before it has failed.
2. Back and Exit are debounced, and Exit stops at once. A repeat of the same press within 3 s, or while one is still queued, is dropped, and so are presses for a run that has already stopped. Exit stops the narration and captions, takes the remote down and marks the run stopped straight away. Every later Fusion call from the tour is refused, so the step in progress unwinds at its next call. Cleanup then closes the tour's documents and restores the window.
3. The chip is minted once per run. Going back over the chip beat reuses the first binding and URN instead of minting a new one.
4. The panel stays down. Only the live, running tour may show its remote. Once it is stopped or hidden, by the tour, you or an agent, nothing shows it again for that run.

What we tested live on a Windows box with 1.11.41: a muted tour, seven Back presses within a few seconds (one taken, six dropped), then three Exits. The run read "Tour stopped" 0.7 s after the first Exit, and the remote stayed down for the rest of the run. Its cleanup finished about two minutes later, when the long Fusion call it was in returned. The failed-beat and chip-once paths are covered by unit tests but were not forced live, since that box's GPU never failed.

Two things we did not do:

• The DisplayLink warning. Nothing the bridge can see reliably says which kind of display a monitor is.
• Detecting a dead canvas. There is no separate check for this, but a beat whose view never changes now counts as failed, which is how a dead canvas shows up.

When you retest without the adapters, could you run the tour again on 1.11.41 and post the tour_progress log? If anything still narrates over a view that didn't change, that log will show which beat.

Correction + third run (show-7e3e4be5): the tour itself is the problem

Correction to my last comment: the LiveKernelEvent 141/117/144/193 entries are NOT new crashes. They're the same batch of ~42 queued Windows Error Reporting reports, re-logged every 4 hours since 2026-10-10 (and on each reboot). There is no Display 4101 (TDR) event in the System log in the last 7 days. Please ignore the USB3/DisplayLink theory from that comment.

Third run, DisplayLink adapters fully unplugged, Fusion on the only monitor (AMD): The bridge reports every beat ok: true (library, symbol, footprint, chip, schematic, board2d, board3d, aps), but the user saw:

1. Every scene's "ADOM is driving Fusion" popup stays at 0% (e.g. "Switching to the 2D board - the board editor: copper, pours and parts", progress bar 0%) for the whole beat. Screenshot attached.
2. The narration doesn't match the screen. During the chip beat the narrator describes the 3D model while Fusion shows a plain footprint. The bridge's own log agrees the view didn't move: chip viewChanged: false, board3d viewChanged: false, yet both are marked ok: true.

So ok / verified can't be trusted here: canvasColours and front pass while the user is looking at the wrong document/view. Suggestions:

• Make viewChanged: false (or the wrong document in front) fail the beat, or at least stop the narration from describing it.
• For chip / board3d, verify that the 3D document/view is actually what's on screen before narrating it.
• Find out why the activity popup never advances past 0%, since it also covers part of the canvas the whole time.

Thanks John. Two questions before we try 1.11.41:

1. Does 1.11.41 fix the "ADOM is driving Fusion" popup that never gets past 0%? In the third run (comment above, with screenshot) every scene showed this popup, e.g. "Switching to the 2D board", and its progress bar stayed at 0% for the whole beat. Your reply doesn't mention it.
2. Could 1.11.41 get release notes? Its release has no changelog and CHANGELOG.md stops at 1.11.9. A short note of what changed would help us decide whether a retest is worth it.

Note: please see the correction comment above. The LiveKernelEvent bursts were old queued reports re-logged every 4 hours, so the DisplayLink/USB3 theory doesn't hold. The third run had the adapters unplugged and still narrated over the wrong view.

Separate small issue: after every container restart (e.g. a PC reboot) the Fusion Dashboard tab shows "Its server is not running", because nothing restarts fusion-dashboard serve. adom-shotlog and adom-relay have systemd units with Restart=always, the dashboard has none. As a local workaround we added /etc/systemd/system/adom-fusion-dashboard.service (modelled on adom-shotlog.service: ExecStart=/bin/bash -lc 'exec /home/adom/.local/bin/fusion-dashboard serve --port 8930 --ai-thread fusion-dashboard', Restart=always). It would be good if the dashboard install shipped a unit like that.

Thanks for the correction, and sorry for running with the DisplayLink theory. Your third run shows the tour was at fault. Answers to your questions, plus the dashboard fix. All of it is in fusion-bridge 1.11.42, which is on the insiders channel now.

Narration over a view that never moved. In 1.11.39 a beat with viewChanged: false could still be marked ok: true, which is what you saw on chip and board3d. Since 1.11.41 that beat retries its motion once. If the view still does not move, the beat counts as failed: its narration and fillers stop, the caption says the step failed and why, and the tour moves on. The same happens when the beat's view cannot be confirmed on screen. Before the failure is known, the opening line of a long beat can still play (the chip beat's "minting the 3D chip" line plays while the mint runs). A stricter check that the 3D model itself is on screen would need your 1.11.42 tour_progress log first, so we can see what the screen showed.

1. The panel stuck at 0%: fixed in 1.11.42. Most steps (opening a document, switching views) do not know their own percent, and the panel drew that as 0% for the whole step. It now fills by elapsed time against how long that step usually takes on your machine and counts down the time left. Past that, it says "taking longer than usual". A step with no estimate shows a moving "Working" bar with a seconds counter. We checked all three states live in Fusion. In the electronics editors the floating panel now sits in the bottom-right corner of Fusion's window, over the layer list, so it covers less of the canvas.

2. Release notes: done. CHANGELOG.md now covers 1.11.10 to 1.11.42, and the 1.11.40, 1.11.41 and 1.11.42 releases carry their own notes.

3. The dashboard after a restart: fixed in 1.11.42. Where systemd is running and sudo needs no password, the installer adds adom-fusion-dashboard.service, modelled on yours (serve --port 8930, Restart=always). It stops a dock-started copy first so there is only one, and a reinstall restarts it onto the new binary. Your hand-made unit has the same name, so adom-wiki pkg update adom/fusion-bridge will replace it with the shipped one. Where there is no systemd, the installer says so and the dock button starts it as before.

A retest on 1.11.42 is worth it for the tour. If any beat still narrates over a view that did not change, the tour_progress log will show which one.

Likely root cause of the d3d12 crashes, and a signal the bridge CAN read.

%APPDATA%\Autodesk\Neutron Platform\Options\NMachineSpecificOptions.xml on this box has:

<driverOptionId UserName="Graphics driver" Value="VirtualDeviceDx11"/>
<IndirectDisplayAdapterDetected UserName="IndirectDisplayAdapterDetected" Value="1"/>

Fusion detects the DisplayLink (indirect display) adapters and switches its graphics driver mode for the whole process, regardless of which monitor Fusion is on. Results so far:

No Display 4101 / dxgkrnl events at the time, so it is inside Fusion Electronics' Skia D3D12 path, not a Windows TDR.

Two asks:

1. Preflight warning: IndirectDisplayAdapterDetected=1 is a reliable way to warn before a tour or Electronics import ("DisplayLink detected: Fusion Electronics may crash with an unrecoverable d3d12 error; unplug the adapters and restart Fusion").
2. Import robustness: when the d3d12 dialog pops up while new_electronics_from_eagle is typing the path into the Open dialog, the typed name lost its start (the field showed k12V5V_Test for C:/Users/.../Buck12V5V_Test.sch) and the import sat at stage: started for 2.5 min with the Open dialog left on screen. Detecting the unexpected-condition dialog during the import and failing fast (and cancelling the Open dialog) would help.

Update: 1.11.42 is now on the public channel, so a normal update picks it up (adom-wiki pkg update adom/fusion-bridge, and ab updates the bridge itself).

Closing this out. The tour items were fixed in 1.11.41 and 1.11.42 (see John's replies above). Your two follow-up asks are fixed in fusion-bridge 1.12.0 (source commit 4629b5b on master; ships with the next release):

1. DisplayLink warning before it crashes. The bridge reads Fusion's own NMachineSpecificOptions.xml (UTF-16). When IndirectDisplayAdapterDetected is 1:

   • fusion_readiness carries displayWarning {indirectDisplayAdapter, graphicsDriver, risk, fix};
   • the guided tour and fusion_new_electronics_from_eagle add it to their reply and lead their hint with "DisplayLink detected: Fusion Electronics may crash with an unrecoverable D3D12 error. Unplug the DisplayLink adapters and restart Fusion before a tour or an Electronics import."

   Unit-tested with the exact lines from your box (driverOptionId Value="VirtualDeviceDx11", IndirectDisplayAdapterDetected Value="1"). On a box without the adapter (DESKTOP-BAR6S0F) no warning appears.

2. The import fails fast on a crash dialog. fusion_new_electronics_from_eagle now checks for Fusion's D3D12 device-loss dialog and its "unexpected condition" dialog at every wait:

   • while waiting for each Open dialog;
   • right before it types the path (the moment your typed name lost its start);
   • while the path is submitted;
   • while the design comes up.

   On a hit it cancels its own Open dialog, writes the event to the action ledger and answers success:false, errorCode: "fusion_graphics_error" (or blocked_by_dialog) with the dialog's title, text, buttons and resolution. It no longer sits at stage: started. A normal import still runs clean: the routing fixture re-imported on DESKTOP-BAR6S0F reached done with 3 of 3 parts placed.

If the crash returns with the adapters unplugged, reopen this with the tour_progress log.