Failed to bind to port 61234

[Andrew Neil]

So I'd been merrily using STM32CubeIDE all morning, doing the usual code-download-debug cycle with no problems at all.

Then, after some code updates & successful build, it suddenly can't reach the GDB server:

 

STMicroelectronics ST-LINK GDB server. Version 7.4.0
Copyright (c) 2023, STMicroelectronics. All rights reserved.
Starting server with the following options:
 Persistent Mode : Disabled
 Logging Level : 1
 Listen Port Number : 61234
 Status Refresh Delay : 15s
 Verbose Mode : Disabled
 SWD Debug : Enabled
 InitWhile : Enabled

Failed to bind to port 61234, error code -1: No error
Failure starting GDB server: TCP port 61234 not available.
Shutting down...
Exit.

 

Several people seem to have had this recently; eg,

https://community.st.com/t5/stm32cubeide-mcus/cubeide-1-18-cannot-detect-st-link-anymore/m-p/784313?search-action-id=49992011530&search-result-uid=784313

https://community.st.com/t5/stm32cubeide-mcus/st-link-error-failed-to-bind-to-port-61235-failure-starting-swv/m-p/784642?search-action-id=49992011530&search-result-uid=784642

 

So why should this change when nothing has been updated - I'm just working in the IDE as usual ?!

 

This is CubeIDE v1.13.0 - so old, yes - but surely no reason for it to just give up in the middle of a session?

On Windows-11 - no updates have happened.

 

[Andrew Neil]

Restarting the IDE made no difference.

Restarting the PC restored operation.

Would still like to know why the sudden failure to bind to the port ?

[Andrew Neil]

---

@Andrew Neil wrote:

Restarting the PC restored operation.

---

Also here:

https://community.st.com/t5/stm32cubeide-mcus/error-in-final-launch-sequence-failed-to-start-gdb-server-failed/m-p/811909/highlight/true#M36794

 

---

@Andrew Neil wrote:

Would still like to know why the sudden failure to bind to the port ?

---

Remains a mystery!

[Pavel A.]

This can be effect of some "endpoint protection" software such as some versions of manageengine.com.

Likely will be fixed soon or already fixed. This **** is managed remotely so it can change its behavior without user knowing it.

 

[Pavel A.]

The same old question: is any antivirus (or VPN, or corporate brain-***ing-ware) installed?

AFAIK these ports are not reserved in Windows in any way. So other apps or Windows components can steal them. 

 

Update: The helpful AI informs that user can define several ranges of ports to exclude from automatic allocation - but this won't prevent other apps to use these ports explicitly. The command is netsh int ipv4 add excludedportrange protocol=tcp startport=<port_number> numberofports=<N>

 

[Andrew Neil]

---

@Pavel A. wrote:

The same old question: is any antivirus (or VPN, or corporate brain-***ing-ware) installed?

---

Just the standard Windows Defender.

But why would it suddenly start blocking this port - and stop blocking it after a reset?

The firewall exceptions are already set up - otherwise it wouldn't have been working for all these years.

 

---

@Pavel A. wrote:

So other apps or Windows components can steal them. 

 

 Again, what would suddenly steal it - and stop after a reset?

Why has it not happened before?

 

What can be done to see if it's a problem with GDB itself, or with some thing(s) else "blocking" or "stealing" GDB's port?

[Pavel A.]

Have you tried to change the port - after checking the active busy and reserved ports, disable Windows firewall?

To check busy ports: netstat -ano

To check reserved ports: netsh int ipv4 show excludedportrange tcp active , netsh int ipv4 show excludedportrange udp active

 

[Andrew Neil]

---

@Pavel A. wrote:

Have you tried to change the port

---

Here?

 

---

@Pavel A. wrote:

after checking the active busy and reserved ports

---

Microsoft Windows [Version 10.0.26100.3476]
(c) Microsoft Corporation. All rights reserved.

>netstat -ano

Active Connections

 Proto Local Address Foreign Address State PID
 :
 TCP 0.0.0.0:61234 0.0.0.0:0 LISTENING 356
 TCP 0.0.0.0:61235 0.0.0.0:0 LISTENING 356
 :
 TCP 127.0.0.1:60275 127.0.0.1:61234 ESTABLISHED 12276
 TCP 127.0.0.1:60277 127.0.0.1:61234 ESTABLISHED 4548
 TCP 127.0.0.1:61234 127.0.0.1:60275 ESTABLISHED 356
 TCP 127.0.0.1:61234 127.0.0.1:60277 ESTABLISHED 356
 :

>netsh int ipv4 show excludedportrange tcp active

Protocol tcp Port Exclusion Ranges

Start Port End Port
---------- --------
 49692 49791
 49892 49991
 50000 50059 *
 50060 50159
 50160 50259
 50260 50359
 61893 61992
 63720 63819

* - Administered port exclusions.


>netsh int ipv4 show excludedportrange udp active

Protocol udp Port Exclusion Ranges

Start Port End Port
---------- --------
 50000 50059 *
 63654 63753
 63854 63953
 63954 64053
 64054 64153
 64154 64253
 64694 64793
 65015 65114

* - Administered port exclusions.

>

 

But, again, it's all back to working now - and had been for several years. Why would it just change?

I shall have to try to remember this thread if it happens again ...