Stuck at 'Initializing' after connecting; radio auto-powered-on then no connection [BUG]

[mm5agm]

Describe the bug

Reported by email from Arlen Levin, WA6AUF (first-time install). YWC does not complete initialization — stuck at "Initializing" — and never connects to the radio.

Reporter's original report

I just installed this program for the first time. Issue I have is that it is having an issue connecting to the com port properly. I know I have the right com port, since wsjt-x works without having the web control program open. When I open the web control program and try to start wsjt-x, get the com port in use error. Problem is the program does not connect to the radio. Stuck at initializing. The interesting thing I found was that if the radio was off and I started the web control program, the radio turned on and it displayed the correct info. After that, no connection to the radio.

Notes

• The "COM port in use" error when starting WSJT-X while YWC already holds the port is expected behaviour (single COM-port owner) — not part of this bug. Reporter pointed at YWC's rigctld bridge (port 4532) as the fix for running both together.
• The actual bug is that YWC's own connection sequence doesn't complete — the radio powering on but then failing to connect suggests the init sequence gets partway through and stalls.
• Radio model not yet known.

Diagnostics

Pending — reporter asked to send radio model, YWC Diagnostics page output, and a fresh (pre-cleared) log file from %APPDATA%\MM5AGM\Yaesu Web Control\logs.

Anything else?

Placeholder issue opened to track an email-reported bug (not filed directly by the reporter on GitHub).

[wa6auf11]

Yes, I know about the com port sharing. Was just trying to see if both were trying to access the same port for troubleshooting.
Where do I find the diagnostic page output?
I erased the log file, started YWC with radio off. Radio turned on and then is stuck in initializing. Also noticed that if closing YWC from the system tray, it still shows up in task manager
Attached is the log file
Radio is FTDX101D

ywc-20260713.log

[mm5agm]

Thanks for the detail and the log file — confirmed radio model is FTdx101D.

Diagnostics page: it's not currently linked from the main menu (I'll get that fixed) — for now just go directly to http://localhost:8080/Diagnostics in your browser while YWC is running.

On the "stuck at Initializing" issue: the log you sent actually shows a clean, successful connection — the radio auto-powered-on, CAT handshake completed in under 2 seconds with no errors, and it read your frequency/mode correctly (14.074 MHz, USB) and stayed connected for the rest of the session. So whatever you saw happen the first time didn't show up in that capture — it only proves the radio-side connection worked, not what your browser was doing.

If it happens again, could you try this instead? It's a different kind of log that should catch it:

1. Open http://localhost:8080/Diagnostics in a browser tab and click the green Start button (top right of the "SignalR Event Log" box).
2. In your normal tab, restart/reload YWC and reproduce the stuck screen.
3. Once you see it stuck, switch back to the Diagnostics tab and click Save… — it'll download a small .txt file. Attach that here (or email it) along with roughly what time you saw it stick.

That capture will show me whether your browser is receiving any updates from YWC at all while it looks stuck, which will tell us whether this is a backend problem or just the page not refreshing.

On the tray-exit issue: when you close YWC from the tray and still see it in Task Manager — does it eventually disappear on its own after a few seconds, or does it stay there indefinitely (say, for a minute or more) until you end it manually? That distinction matters a lot for tracking this down, so any detail you can give on timing would help.

Thanks again for taking the time to send the log — it's very useful even though it didn't catch the stuck state this time.

[wa6auf11]

Attached is a new log file and 2 screen shots. One screen shot is showing it just trying to initialize. The other is what comes up when trying to close from task tray. It continues to stay open in task manager. Trying to start the Diagnostics web page does not work. Based on the task tray error when stopping, but not knowing much how the interaction of YWC and WSJT-x JTAlert, log4om. Wondering if that is my problem, YWC is trying to do something with those programs? I do not use JTAlert or log4om. JTAlert is installed.

ywc-20260713.log

[mm5agm]

Found and fixed it, Arlen — thank you for the log and screenshots, they nailed it down quickly.

The overlay was getting stuck because the poll responsible for hiding it gave up permanently after a single failed HTTP request instead of retrying — so a one-off network hiccup during startup could strand the "Initialising…" spinner forever, even though the app underneath it (meters, frequency tracking) was fully live, which matches exactly what your screenshots showed. Fixed in v2.4.2-pre2, just released — I've tested it here and it's working well.

Separately — I went through your log around the tray-exit-and-restart and it looks like a false alarm: there's a clean ~8 second gap between shutdown and the next launch, not a hang. The WSJT-X/Log4OM/JTAlert/GridTracker/Fldigi mentions in the exit dialog are just static text describing what could be running, not a sign anything was actually stuck. If you're not using some of those, you can turn their buttons off from the Application Setup page — untick "Show" for the ones you don't need and they'll stop appearing, which should make the exit dialog and main screen a bit less cluttered.

Could you give v2.4.2-pre2 a try when you get a chance? No need to uninstall first — just run the new installer over the top, your settings carry over. Thanks again for your patience running down the log and screenshots for this one.

[wa6auf11]

Still have same issue. Started YWC with radio power off. Exactly same results. YWC turned radio on, then just initializing. Rebooted PC, left radio on.
Here is screen shot and new log file

ywc-20260713.log

[mm5agm]

Maybe found it 🙂. Going back through your log, I think my pre2 fix for #74 accidentally introduced a new bug: it added a second thread writing into the same CAT message buffer, and that buffer wasn't thread-safe. That kind of corruption would explain the slow-motion behaviour you saw — everything (CAT round-trips, even unrelated file reads) dragging out to seconds each, with the app eventually limping to "initialised" over a minute later.

I want to be upfront, though: pre2 looked right to me too, and it wasn't, so I'm treating this as an unconfirmed theory rather than a fix until you've had a chance to try it. v2.4.2-pre3 has the buffer locked now — would you be willing to test it and let me know either way? Download: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre3

[wa6auf11]

Sorry, same issue. Screen shot and new log file attached.

ywc-20260713.log

[mm5agm]

Thanks for the new log and the retest — that was really useful, because it showed pre3's fix didn't actually address what's happening on your machine.

Going back through the log line by line: during startup your CAT responses were arriving at roughly one per second instead of near-instantly, and that's a pretty specific fingerprint — it points at the .NET thread pool running out of threads, not at anything wrong with the CAT/serial code itself. What I think is happening: YWC's file logger was writing every log line synchronously (with a file lock on top), and during startup there's a burst of dozens of log lines in quick succession (CAT responses, meter polling, etc.). Under the right conditions — antivirus scanning the log file, a slower disk, fewer CPU cores — that's enough to block most of the thread pool at once, and the whole app slows to about one operation per second, including the startup command sequence that was leaving you stuck at "Initialising…". That would also explain why this hasn't shown up for other users yet: it's a threshold effect that depends on your specific machine, not something everyone hits.

v2.4.2-pre4 changes the logging so it runs on a background thread instead of blocking, cuts out a lot of the noisiest logging during startup, and raises the thread pool's minimum size so there's more headroom. It also adds some new diagnostic lines that will show directly whether the thread pool is starving, so if this doesn't fully fix it, the next log should point straight at what's still wrong. Download: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre4

I'll be upfront the same way I was with pre2 and pre3: I can't reproduce this on my own setup, so I can't confirm this fixes it — only that it fixes the specific mechanism the log pointed to. Would you be willing to give it a try and let me know how it goes either way?

[wa6auf11]

Looks like that might have fixed it. Finished initializing and was able to change bands and freq.
But, went into settings and tried to uncheck the optional filters. When clicking save, seemed to crash the server. Did it twice. On the third try, it said it saved, but check boxes were still checked. Fourth try, crashed again. Not sure if new issue or part of the same one. Attached is my system info for PC. Log file from, I think, multiple crashes.

ywc-20260713.log