Could not start PIO Home server: Error: connect EACCES 127.0.0.1:8010

[TriCri]

Temporary solution

1. Open VSCode settings https://docs.platformio.org/en/latest/integration/ide/vscode.html#settings
2. Search for pio home port
3. Set platformio-ide.pioHomeServerHttpPort to 9013
4. Restart VSCode.

---

%23 Description of problem
ALready tried to re-install VS Code, delete folder 'platformio.platformio-ide-2.3.3' in extensions folder an re-install the platformIO extension.

BEFORE SUBMITTING, PLEASE SEARCH FOR DUPLICATES IN

• https://github.com/platformio/platformio-vscode-ide/issues%3Fq=is%3Aissue

%23 Configuration

VSCode: 1.59.0
PIO IDE: v2.3.3
System: Windows_NT, 10.0.19043, x64

%23 Exception

Error: Could not start PIO Home server: Error: connect EACCES 127.0.0.1:8010
  at c:\Users\chris\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\platformio-node-helpers\dist\index.js:1:5946
  at processTicksAndRejections (internal/process/task_queues.js:93:5)

[longforus]

i have the same issue,

stack trace: RequestError: connect ECONNREFUSED 127.0.0.1:8027	at ClientRequest.<anonymous> (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\got\dist\source\core\index.js:956:111)	at Object.onceWrapper (events.js:422:26)	at ClientRequest.emit (events.js:327:22)	at ClientRequest.EventEmitter.emit (domain.js:467:12)	at ClientRequest.origin.emit (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\@szmarczak\http-timer\dist\source\index.js:39:20)	at Socket.socketErrorListener (_http_client.js:469:9)	at Socket.emit (events.js:315:20)	at Socket.EventEmitter.emit (domain.js:467:12)	at emitErrorNT (internal/streams/destroy.js:106:8)	at emitErrorCloseNT (internal/streams/destroy.js:74:3)	at processTicksAndRejections (internal/process/task_queues.js:80:21)	at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
S @ workbench.desktop.main.js:sourcemap:62
workbench.desktop.main.js:sourcemap:2038 [[object Object]]connect ECONNREFUSED 127.0.0.1:8027
$onExtensionRuntimeError @ workbench.desktop.main.js:sourcemap:2038
workbench.desktop.main.js:sourcemap:2038 RequestError: connect ECONNREFUSED 127.0.0.1:8027
	at ClientRequest.<anonymous> (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\got\dist\source\core\index.js:956:111)
	at Object.onceWrapper (events.js:422:26)
	at ClientRequest.emit (events.js:327:22)
	at ClientRequest.EventEmitter.emit (domain.js:467:12)
	at ClientRequest.origin.emit (c:\Users\void\.vscode\extensions\platformio.platformio-ide-2.3.3\node_modules\@szmarczak\http-timer\dist\source\index.js:39:20)
	at Socket.socketErrorListener (_http_client.js:469:9)
	at Socket.emit (events.js:315:20)
	at Socket.EventEmitter.emit (domain.js:467:12)
	at emitErrorNT (internal/streams/destroy.js:106:8)
	at emitErrorCloseNT (internal/streams/destroy.js:74:3)
	at processTicksAndRejections (internal/process/task_queues.js:80:21)
	at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
$onExtensionRuntimeError @ workbench.desktop.main.js:sourcemap:2038

[henrygab]

SOLUTION!

This appears to be root-caused to the same underlying issue reported in docker/for-win#3171 (comment) (... but it's NOT a docker specific issue!)

Really short summary of how combination of issues may cause this....

If 3171 turns out to be the same cause, then this issue is caused by a combination of Hyper-V (specifically Hyper-V Networking Service aka HNS) reserving a LOT of dynamic ports, coupled with something that sets the starting port number for dynamic TCP allocations to 1024. (unclear who culprit is ... docker? windows update? many? other?)

First, it's perfectly valid for HNS to reserve a bunch of dynamic ports. The problem is, when they could include values that are used by other programs that expect a fixed port. Thus, because HNS might reserve a different subset of TCP ports at each and every boot, it will cause random-looking failures. Debugging is very hard because most utilities won't show that anything is actually using those ports, but attempting to bind to them will still fail.

If you have Hyper-V enabled, then this can make the problem more obvious, but only because Hyper-V has a service that uses a lot of dynamic ports. Any program that uses dynamically bound TCP ports can cause sporadic failures.

---

How to know if you are affected by this issue?

Simply review the output of the following three commands ... neither of which requires administrative privileges:

netsh int ipv4 show dynamicport udp
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show excludedportrange tcp

You're likely affected if the following are true:

• The first command (dynamicport UDP) shows a start port of 49152
• The second command (dynamicport TCP) shows a start port of 1024
• The third command (excludedportrange TCP) shows a long list of excluded ports

---

My example output, showing I'm affected

Here's the output from the relevant commands on my machine:

C:\Q>netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 1024
Number of Ports : 64511

C:\Q\>netsh int ipv4 show dynamicport udp

Protocol udp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

As is clear, the starting port # for dynamically allocated TCP ports was set to start at 1024. It appears that Windows updated the UDP settings to a reasonable range, but failed to update the TCP settings.

---

Minimal fix

Running the following (from an administrator/elevated cmd.exe) to update the starting port number for dynamically allocated TCP ports:

netsh int ipv4 set dynamic tcp start=49152 num=16384

Reboot the machine. Breathe a sigh of relief as all your random network failures resolve?

---

If you hit this problem, please confirm the above can fix the issue for you also?

[longforus]

@henrygab After a few days, he's all right now. 😄

[henrygab]

SOLVED

See comment below:
#2667 (comment)

Old post

I'm still hitting this. I understand this can be difficult to diagnose remotely. I'd love hints on how to do so.

From black-box testing:

1. cmd-line invocation of pio home loads the web page, which reports ERR_CONNECTION_REFUSED
   a. after reboot, pio home appears to start the server...
   b. after running once (either cmd-line or failing to open page in VSCode), reports PlatformIO Home server is already started in another process
2. However, access to https://127.0.0.1:8008 (the configured PIO Home port) returns ECONNREFUSED
3. Attempts to access https://127.0.0.1:31524 (random port with nothing) gets the same ECONNREFUSED

Based on the above, I can't tell if the PIO Home server is actually non-responsive, or if something if interfering with the connection, which would be my first step at diagnosis.

Is there a way to cause the PIO Home server to be periodically logging a "keepalive" type message to a log somewhere, just to verify it's alive and well?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Please provide more details or it will be closed if no further activity occurs. Thank you for your contributions.

[henrygab]

SOLVED

See comment below:
#2667 (comment)

Old post

It appears that PIO folks don't review questions asking how to get data to enable tracing the root cause of issues. That makes me sad, while I simultaneously understand the problem of high-volume feedback.

For me, this eventually resolved itself after many weeks. I have no idea why. I really don't like not knowing the root cause, because that means when it occurs again, I will again be stuck with no way forward.

PIO folk ... if you have any data that you want collected (or would be helpful to collect) when this occurs, PLEASE post here. I'm not the only one this happens to, and it prevents use of PIO entirely when it does happen. Else, I won't update again next time this goes stale.

[ivankravets]

Could someone provide us with a remote session to debug this issue? Please email to me@ikravets.com for details.

[henrygab]

After a time of not occurring, it is happening again. I've reached out to Ivan Kravets to see how to enable further debugging.

[henrygab]

Some (potentially) useful information:

I'm on Windows 10. The TCP port that PIO Home was attempting to run on was port 8080.

However, Windows may have reserved that port for some other program? (not entirely sure about this part...)

See output of the following command (from a cmd.exe terminal):

netsh int ipv4 show excludedportrange tcp

I my case, ports 7981 8080 were listed. I was able to workaround the issue (at least temporarily) by manually setting the port used by PIO Home to a number that was not listed in the ranges from the above command. In my case, I used port 11011.

Still seeing if there is anything more I can do to help root-cause more deeply, hopefully with the goal of preventing this silent, non-actionable error from affecting other users....

[henrygab]

SUCCESS!

This appears to be root-caused to the same underlying issue reported in docker/for-win#3171 (comment) (... but it's NOT a docker specific issue!)

Really short summary of how combination of issues may cause this....

If 3171 turns out to be the same cause, then this issue is caused by a combination of Hyper-V (specifically Hyper-V Networking Service aka HNS) reserving a LOT of dynamic ports, coupled with something that sets the starting port number for dynamic TCP allocations to 1024. (unclear who culprit is ... docker? windows update? many? other?)

First, it's perfectly valid for HNS to reserve a bunch of dynamic ports. The problem is, when they could include values that are used by other programs that expect a fixed port. Thus, because HNS might reserve a different subset of TCP ports at each and every boot, it will cause random-looking failures. Debugging is very hard because most utilities won't show that anything is actually using those ports, but attempting to bind to them will still fail.

If you have Hyper-V enabled, then this can make the problem more obvious, but only because Hyper-V has a service that uses a lot of dynamic ports. Any program that uses dynamically bound TCP ports can cause sporadic failures.

---

How to know if you are affected by this issue?

Simply review the output of the following three commands ... neither of which requires administrative privileges:

netsh int ipv4 show dynamicport udp
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show excludedportrange tcp

You're likely affected if the following are true:

• The first command (dynamicport UDP) shows a start port of 49152
• The second command (dynamicport TCP) shows a start port of 1024
• The third command (excludedportrange TCP) shows a long list of excluded ports

---

My example output, showing I'm affected

Here's the output from the relevant commands on my machine:

C:\Q>netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 1024
Number of Ports : 64511

C:\Q\>netsh int ipv4 show dynamicport udp

Protocol udp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

As is clear, the starting port # for dynamically allocated TCP ports was set to start at 1024. It appears that Windows updated the UDP settings to a reasonable range, but failed to update the TCP settings.

---

Minimal fix

Running the following (from an administrator/elevated cmd.exe) to update the starting port number for dynamically allocated TCP ports:

netsh int ipv4 set dynamic tcp start=49152 num=16384

Reboot the machine. Breathe a sigh of relief as all your random network failures resolve?

---

If you hit this problem, please confirm the above can fix the issue for you also?