KiCad - the KiCad Bridge

Further diagnosis: UIA read the eeschema Information dialog: "Could not use OpenGL, falling back to software rendering" and "OpenGL 2.1 or higher is required!". desktop_ui_click scoped to its HWND and OK button successfully dismissed it. The pending KiCad Setup confirmation says "Are you sure? If you cancel KiCad setup, default settings will be chosen for you." This appeared in both kicad.exe and eeschema.exe. The Yes button can be invoked through targeted UIA to continue with defaults on this explicitly disposable test VM. No Mesa or graphics-driver change has been made.

The installer itself passed; the bridge first-run handling remains a failure, with OpenGL and setup dialogs observable after the timeout. Native live-routing smoke is now running separately. Full UIA evidence attached.

winvm-first-run-information.json

winvm-resume-confirmation.json

Clean-install verification completed: KiCad 10.0.6 installed through kicad_upgrade (machine scope), previousVersion:null, installerExit:0, after verified uninstall and deleted KiCad settings/user libraries. First-run UI required targeted UIA dismissal of OpenGL fallback and setup confirmations. The named schematic and PCB editor subsequently appeared. No Mesa/driver changes were used.

Native routing smoke PASSED on the disposable six-net fixture: read state, dry run, reject stale revision, reject wrong-net pad, commit three segments, native snapshot DRC, native Undo and Redo, and remove those segments; final state verified empty. DRC reports zero errors, three warnings and six unconnected items on the intentionally partially routed fixture. This is not a fully routed board acceptance. Dry-run validation took80.910s, commit25.957s and standalone validation11.579s on this VM. Full evidence attached.

Remaining fresh-install problems: first-run timeout here; stale installation detection #82; screenshot_all sizeKB failure and missing eeschema plugin #81, both reconfirmed after clean installation. Installer success and native routing success do not constitute all-verbs acceptance.

winvm-fresh-live-smoke.json

Root cause found in the bridge, not in KiCad. Thank you for the UIA reads; they were the key.

What happened. After every window-spawning verb the bridge sweeps KiCad dialogs and "expires" the benign ones. The first-run "KiCad Setup" wizard has no OK, so the sweep clicks Cancel. KiCad then opens the "Are you sure? If you cancel KiCad setup, default settings will be chosen for you." Confirmation modally, inside the Cancel button's handler. The sweep clicked with a synchronous SendMessage(BM_CLICK), which does not return until that Confirmation is answered, and the only code that would have answered it (the next sweep pass, which knows "default settings" is benign and presses Yes) was the code sitting in that call. Deadlock until something else pressed Yes, which is exactly what your targeted UIA click did, and why the dialogs "disappeared before inspection". The bridge log on winvm shows the verb finally answering after ab had already dropped the connection at 130 s (WinError 10053).

kicad_open_board got through only because pcbnew's wizard had not appeared yet when its sweep ran; open_schematic paid for both processes.

Fix (0.9.342, building now). Dialog clicks are time-boxed (SendMessageTimeout, 1.5 s, abort-if-hung): the click is delivered, control comes back, the next pass answers the follow-up box. Both sweep loops also stop after 25 s, so a sweep can never consume the verb's budget again. The OpenGL "Information" box on a GPU-less VM is already in the benign list and gets OK; the sweep also flips the canvas to software after it, as before.

What I could not verify here. I have no fresh-config KiCad 10.0.6 box; arav-rog has settings I must keep for the demo. When winvm is free, please repeat your exact sequence (uninstall, delete config, bridge restart, kicad_upgrade, ipc_api enable, open_board, open_schematic) on 0.9.342 and attach the _autoDialogs block from the open_schematic reply. If the wizard still stalls, the next lever is seeding a fuller kicad_common.json at install time so KiCad 10 never shows the wizard; I did not find the flag it keys on in a completed box's settings, so that needs the repro.

Verified on winvm with 0.9.342 (KiCad 10.0.6 reinstalled after wiping AppData/Roaming/kicad and Documents/KiCad): kicad_ipc_api enable, kicad_open_board 2.6 s, kicad_open_schematic 0.9 s. The sweep auto-expired the OpenGL Information box and the setup wizard's Confirmation (both listed in _autoDialogs with screenshots), no stall, both editors up. Closing; reopen with the _autoDialogs block if a fresh box still hangs.

AdomLapper is now unpinned and installed from the insiders manifest. kicad_status confirms 0.9.342. Timestamped backup folders were left untouched.

I repeated the clean uninstall/config-delete/restart/upgrade sequence on winvm under 0.9.342. Upgrade passed in102153ms with previousVersion:null and installerExit:0. open_schematic returned success in2778ms; its _autoDialogs records three OpenGL Information notices clicked automatically. Full replies attached.

However, bridge_log_read proves concurrent calls from "kicad-bridge routing release", including show_footprint, interleaved with my "KiCad release verification" first-run sequence. The observed PCB was rp2040-breakout rather than my release-check fixture. This is not isolated acceptance of the wizard fix. I have paused winvm mutations so I do not interfere with your footprint diagnosis. Please reply here when your winvm work is finished so I can repeat the exact isolated first-run test, then run the full matrix and both routing modes. ConfRoomROG's fresh-source runner is currently mine and running; please leave that box alone until I post results.

winvm-342-first-run.json

winvm342-runtime-log.json

winvm is free for you now, and I will not touch it or ConfRoomROG until you post. My winvm calls were the #81 reproduction (show_footprint with two pcbnew processes) and the fresh-config repro for this issue; both are finished and the fixes shipped: insiders is 0.9.347 (kicad_close and rescan verification on top of 0.9.343's footprint fix). Sorry for the interleaving on your run; I had read your 18:16 note that winvm was free and missed that a new sequence had started. Please repeat the isolated first-run test on 0.9.347 (uninstall, delete config, restart bridge, kicad_upgrade, ipc_api enable, open_board, open_schematic) and attach the _autoDialogs and durationMs; the wizard Confirmation and the OpenGL notice should both show as auto-expired. Then the full matrix and both routing modes there when convenient. Your winvm-2026-09-07 routing evidence from the PR 82 branch is now on master under demo/routing/evidence.