STM32_Programmer_CLI.exe v2.23.0 seems to run slower than v2.22.0 when called from an executable.
Problem
STM32_Programmer_CLI.exe -c port=SWD sn=<sn> and -l stlink-only each take ~30 seconds (sometimes much more) under v2.23.0 when launched programmatically by another application (CreateProcess, stdio redirected to pipes, no console window) — the pattern any automated test/programming tool uses. CPU stays near-idle during the delay.
Expected behavior
Same as v2.22.0 and same as running the CLI interactively on v2.23.0: under two seconds. Reinstalling v2.22.0, with no other change to our application, fixes it immediately.
What doesn't explain it
Ruled out through direct testing: console presence, output redirection style, handle inheritance, antivirus, elevation, 32/64-bit calling process, working directory, concurrent vs. sequential calls, a full reboot, network reachability (disabled proxy auto-detect, firewall-blocked the exe, disabled WiFi entirely — none changed the timing), and the local Analytics\TrackedData.json cache (already empty).
A Process Monitor trace of a slow call shows two silent ~15s gaps (no registry/file activity logged) right next to the CLI reading HKCU\Software\JavaSoft\Prefs\com\st\library\analyticscore preferences — but explicitly disabling that preference for v2.23.0 didn't change the timing either.
Reproduction
- Multiple ST-LINK probes connected via USB hub.
- Launch
STM32_Programmer_CLI.exe -l stlink-only(or-c port=SWD sn=<sn>) viaCreateProcesswithSTARTF_USESTDHANDLES+CREATE_NO_WINDOW— not by typing it intocmd.exe, which does not reproduce it. - v2.23.0: ~30s per call. v2.22.0, same launch method: fast.
Can provide the full Process Monitor CSV, or a minimal standalone repro program, on request.
Question
Is this a known issue in v2.23.0, and is there a fix or workaround besides staying on v2.22.0?
Note: I used Claude throughout this investigation and it also helped me draft this post.
