Super User

Solved

Failed to bind to port 61234

15 replies
2448 views

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.

STM32CubeIDE

Andrew NeilBest answer

Super User

@Andrew Neil wrote:
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 ?

Maybe this explains it:

In another thread, @STackPointer64 wrote:
Restarting the computer will also resolve the issue, as it terminates the hanging process during shutdown. However, simply restarting the IDE won’t help because the GDB server runs as a separate process.
While the IDE normally starts and stops this process, it sometimes fails to terminate it when it hangs.

(my emphasis)

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Andrew NeilAuthor

Super User

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 ?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Andrew NeilAuthor

Super User

@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!

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

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 NeilAuthor

Super User

@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?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

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 NeilAuthor

Super User

@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 ...

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Andrew NeilAuthor

Super User

Seems that VSCode is similarly affected:

https://community.st.com/t5/stm32cubeide-for-visual-studio/nothing-changed-but-stlink-debugger-cannot-use-now/m-p/899969/highlight/true#M2432

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

M

Marc_LM

Senior

@Andrew Neil , I mitigated the issue from Windows by using ports that are not reused by the OS.

Right now, I am using something in the 29xxx (x4 ports) range for GDB and RTOSproxy.
I never figured out which service would reclaim the 61xxx port.

Sign up

Click below to sign in

Login to the community

Click below to sign in