Fusion hard-crashes every ~20-30 min; crashed again AFTER bridge restart repaired the legacy add-in copy (Adonis, follow-up to #75)

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed bug report

adonis · 2mo ago ·closed by John Lauer

Reported first-hand by Adonis (2026-09-03) — follow-up to #75, filed from his container with live diagnostics pulled off the laptop (LAPTOP-4C2CM5HK). #75 covers the add-in dialog storm; this issue is for the part its root-cause reply does NOT explain: Fusion keeps hard-crashing roughly every 20–30 minutes, and it crashed again AFTER the bridge was restarted and AFTER the legacy add-in copy was repaired.

Symptoms (in order)

Fusion's toolbar started responding extremely slowly to the mouse → Adonis force-quit Adom Bridge suspecting it.
Fusion then hard-crashed repeatedly, ~every 20–30 minutes.
Every Fusion launch showed the AdomBridge add-in dialog (traceback below) — the #75 dialog storm.
He restarted Adom Bridge (~15:47Z / 10:47 local) to stop the crashing. Fusion hard-crashed again ~20 minutes later (~16:08Z / 11:08 local), with the bridge running and the add-in copy already repaired.

Dialog (truncated by the modal; module name is the URL-encoded add-in package prefix):

Adom Bridge failed to start:
Traceback (most recent call last):
  File "C:/Users/adonis/AppData/Roaming/Autodesk/Autodesk Fusion 360/API/AddIns/AdomBridge/AdomBridge.py", line 78, in run
    from . import http_server
  File "...\AddIns\AdomBridge\http_server.py", line 31, in <module>
    from .commands.cloud_documents import get_walk_progress
  File "...\AddIns\AdomBridge\commands\__init__.py", line 29, in <module>
    from .activity_palette import handle_activity_banner
ModuleNotFoundError: No module named '__main__C%3A%2FUsers%2Fadonis%2FAppData%2FRoaming%2FAutodesk%2...

Live diagnostics (pulled ~16:35Z, 2026-09-03)

ab core 2.0.83, connected 2026-09-03T15:47:15Z (his restart).
fusion360 bridge 1.9.341, running — still the PRE-fix version. His restart happened ~23 min before 1.9.351 was promoted to public (~16:10Z), so the fixed build is not on the box. fusion_addin_status: add-in 1.0.16 (expected 1.0.16, addinStale:false), currently serving — busy:false, pyThreads:6.
Legacy copy IS repaired: %APPDATA%\Autodesk\Autodesk Fusion 360\API\AddIns\AdomBridge\commands\activity_palette.py exists (18,840 bytes), mtime 2026-09-03T15:49:43Z — the 1.9.341 start-sync rewrote it ~2.5 min after bridge start (Fusion is detected on this box, so the pre-1.9.351 sync condition was met).
Fusion CER (crash reporting) activity from %LOCALAPPDATA%\Autodesk\CER\upi.log (laptop local = UTC-5). Extractor bursts on Sept 3 local time: 09:40, 10:24, 10:32, 10:37, 10:46–10:47, 11:07–11:08 — i.e. the ~20-min cadence Adonis described, with the last burst after the bridge restart (10:47) and after the legacy-copy repair (10:49:43 local). ~55 CER report folders sit under %LOCALAPPDATA%\Autodesk\CER\ for a deeper look.
Minor: fusion_readiness returned error sending request for url (http://127.0.0.1:61023/command) while fusion_addin_status succeeded moments before over the same bridge — possibly just a 1.9.341-era verb gap, but the error shape is a connection failure, not unknown_verb.

Why this is not just #75

#75's root cause explains the startup dialog (and attributes the slow toolbar to the broken add-in copy). It does not explain recurring hard crashes at ~20-minute intervals that continued after the broken copy was repaired on disk and while add-in 1.0.16 was serving HTTP. Something else — plausibly the add-in itself under load (palette/http server/py threads), or a bridge↔add-in interaction — is taking Fusion down.

Asks

Pull one of today's CER dumps off the box (%LOCALAPPDATA%\Autodesk\CER\<hash>\) and identify the faulting module — is the crash inside the add-in's threads, the palette, or Fusion itself?
Say whether 1.9.351 / add-in 1.0.17 contains anything crash-relevant beyond the import guard + one-modal change, or whether this is a new bug that survives the update.
Until root-caused: a recommended way for Adonis to keep working in Fusion (e.g. temporarily disable the add-in?) if the crashes continue on 1.9.351.

Box state at filing: bridge 1.9.341 still running; Fusion running, add-in 1.0.16 serving. Happy to update the box to 1.9.351 (bridge restart + Fusion restart) and report back whether the cadence continues — say the word here.

3 Replies

John Lauer · 2mo ago

Answers to the three asks, from the bridge maintainer thread:

2. Is there anything crash-relevant in 1.9.351 / add-in 1.0.17? No. Beyond the import guard, the single actionable modal, the start-failure marker, the installer's verify-and-repair and the sync-when-undetected change, 1.0.17 is byte-identical to 1.0.16 in everything that runs after start. If the cadence continues on 1.9.351 it is a bug that survives the update. Please do update the box (bridge restart, then fusion_restart_for_addin {save:true}) and report whether the cadence continues: that answers ask 2 empirically.

3. How Adonis keeps working meanwhile, and a bisect that costs nothing. With the bridge quit AND the add-in gone, Fusion runs exactly as Autodesk ships it:

Quit Adom Bridge (otherwise it re-syncs the add-in on its next start).
Close Fusion. Delete every AdomBridge folder under %APPDATA%\Autodesk\ (FusionAddins\AdomBridge, Autodesk Fusion\API\AddIns\AdomBridge, Autodesk Fusion 360\API\AddIns\AdomBridge).
Start Fusion and work for an hour. If the 20-30 minute crashes stop, the add-in (or the bridge driving it) is the cause and the CER dump will say which thread. If they continue with no add-in on disk, it is Fusion itself (its own autosave / cloud sync / CER cadence) and we stop looking at the bridge. Either way, starting Adom Bridge again restores the add-in in one step.

1. The CER dump. Yes please: from the newest folder under %LOCALAPPDATA%\Autodesk\CER\, the *.xml report (it names the faulting module and offset; Fusion360.exe, a Qt/CEF module, or python3*.dll are the three answers that matter) and, if present, the *.dmp. Attach the XML's exception block here. pull_file works on both.

What I will look at on this side while you bisect: every place the add-in touches Fusion's API off the main thread, and every periodic job on the bridge that calls into the add-in (readiness probes, the activity palette, the keepalive). A Fusion API call from a background thread is the classic way an add-in takes Fusion down some minutes later rather than at the call.

John Lauer · 2mo ago

The audit I promised, done against the add-in shipped in 1.9.368 (add-in 1.0.17 plus today's view-module changes):

Off-main-thread Fusion API use: none in the request path. The HTTP thread does exactly one API call, fireCustomEvent, which is the documented thread-safe hop; every command handler runs inside the custom-event handler on Fusion's main thread. The palette (ui.palettes, sendInfoToHTML) is only ever touched from there too.
The one exception: the stale-lock watchdog thread (5 s cadence) calls the static adsk.core.Application.log when it frees a wedged lock. That is a log line, not a document or UI call, and it fires only after a command has been stuck, so it cannot explain a crash every 20 to 30 minutes on an idle box. I will move it onto the main-thread hop anyway in the next release so the add-in has zero background-thread API calls.
Periodic jobs from the bridge: readiness probes hit the add-in's /status (served by the HTTP thread, no API call); the activity palette repaints only while a verb runs; there is no keepalive that touches Fusion.

So from this side nothing in the add-in runs Fusion's API off the main thread, which leaves the bisect as the decider. Adonis, the two things that would settle it: the CER *.xml exception block from %LOCALAPPDATA%\Autodesk\CER\<newest>\, and whether the 20 to 30 minute cadence continues with the bridge quit and every AdomBridge folder removed from %APPDATA%\Autodesk\ (the recipe above). If the crashes continue with no add-in on disk, this is Fusion itself and I will close this; if they stop, the dump names the thread and I take it from there.

John Lauer · 2mo ago

Closing without the reporter's data (John, 2026-09-07: stop waiting on it).

What is established: the add-in's request path makes no Fusion API call off the main thread (only the documented thread-safe fireCustomEvent hop), and the one background-thread call that existed, the lock watchdog's Application.log line, is gone from source as of today and ships with the next release; the watchdog writes to ~/.adom/fusion-bridge/addin-watchdog.log instead. Nothing in the bridge polls Fusion's API on a timer. The box was on 1.9.341 when the crashes were logged, two releases before the import guard and single-modal fixes.

What is not established: whether the 20 to 30 minute cadence ever continued on 1.9.351 or later, or with no add-in on disk. If it does, reopen with the CER *.xml exception block from %LOCALAPPDATA%\Autodesk\CER<newest>\ and the bridge version at the time, and it gets picked up from there.

John Lauer closed this · 2mo ago