Intermittent error: ConnectNamedPipe failed: Windows error 232

[octachrome]

I use winpty in a Node application with https://github.com/daviwil/node-pty-prebuilt. A customer is reporting intermittent errors:

[56365.101 node.exe,p19464,t5808]: libwinpty error: code=5 msg='ConnectNamedPipe failed: Windows error 232'

Any ideas what could cause this or how I can find out why it is happening? I have not seen it in any of our test environments and no other customer has reported this. The customer says that the problem is intermittent, and retrying the operation usually works. He is using Windows 10 Enterprise.

I am using node-pty-prebuild v0.7.3, which uses winpty 0.4.3. Logs from winpty-debugserver.exe are attached: winpty2.log.

[rprichard]

I don't know why that would happen.

[octachrome]

I have had another report of this problem from a different customer. I believe that it is caused by McAfee Endpoint Security interfering with the startup of the winpty agent. Both clients have this antivirus software installed, and disabling McAfee resolves the issue.

I have reproduced the same error with Avast antivirus. When libwinpty launches the agent, Avast scans winpty-agent.exe for threats (see screenshot). It then appears to kill the agent and relauch it (with a different pid). This is all hidden from libwinpty - CreateProcessW returns the pid of the second agent once the scan has finished. The problem is that the first agent already connected to and disconnected from the control pipe, so when libwinpty calls ConnectNamedPipe it returns ERROR_NO_DATA, which is the documented behaviour when the client has already disconnected from the pipe.

It seems like Avast and McAfee have similar approaches to threat detection, and both involve running the agent twice, probably in some kind of sandbox for the first run. One way to handle this could be for libwinpty to accept multiple client connections and loop until one of them is proven to be OK, similar to this: https://docs.microsoft.com/en-us/windows/desktop/ipc/multithreaded-pipe-server. libwinpty would also have to call ConnectNamedPipe before spawning the agent, rather than afterwards as it does today.

Do you think this is a reasonable change to make? Or do you have any other ideas about how libwinpty could be modified to handle this situation? I am happy to implement any suggestions and submit a pull request.

There are several other reports of this error, so I think it is worth fixing. These antivirus tools are only going to get more common and more intrusive.

• https://github.com/JunoLab/atom-julia-client/issues/443
• https://github.com/zeit/hyper/issues/2832

[rprichard]

Thanks for debugging this.

In winpty2.log, when the first pipe connection fails (to winpty-control-19464-4-...), I don't see a previous connection attempt to the pipe. Maybe when the agent runs inside the antivirus sandbox, it's not able to report trace() messages?

... One way to handle this could be for libwinpty to accept multiple client connections and loop until one of them is proven to be OK, similar to this: https://docs.microsoft.com/en-us/windows/desktop/ipc/multithreaded-pipe-server. libwinpty would also have to call ConnectNamedPipe before spawning the agent, rather than afterwards as it does today.

Do you think this is a reasonable change to make?

I suppose something like that has to be done?

Would libwinpty need a worker thread to service connection attempts? The pipe is using overlapped I/O already, so with one control-pipe instance, it's fairly easy to start the ConnectPipe operation before spawning the agent, then finish the attempt after CreateProcess returns, but if I understand correctly, something in libwinpty would need to start another ConnectPipe operation between the antivirus killing the first agent instance and starting the second instance.

Would it be sufficient if libwinpty created 2 or more instances of the control pipe up front, then used the first good instance after the CreateProcess call? As long as there's an instance ready, I think(?) the agent would be able to successfully connect.

I suspect the antivirus software would allow whitelisting the winpty-agent.exe process, but users either don't know they need to do that or lack admin privileges.

[octachrome]

I don't see a previous connection attempt to the pipe. Maybe when the agent runs inside the antivirus sandbox, it's not able to report trace() messages?

Yeah, I am assuming that McAfee blocks the trace messages somehow. I hope to verify this on the customer's machine soon. When running with Avast you can see both connections. See the attached winpty-avast.log.

Would it be sufficient if libwinpty created 2 or more instances of the control pipe up front, then used the first good instance after the CreateProcess call?

No idea. Presumably creating a multi-client pipe server is a normal thing to do so there must be a way of doing it such that the server doesn't miss any connections. I will look into it and see if I can get something working, using a worker thread if necessary.

[rprichard]

I can reproduce the issue with Avast, and I have a change that works around it: https://github.com/rprichard/winpty/tree/antivirus.

Are you able to reproduce the problem with McAfee, and can you check whether my antivirus branch fixes it?

[octachrome]

That's great, thanks so much for implementing this. I will ask our customer if they can test the patch with McAfee.

[octachrome]

@rprichard Sorry for the delay, the customer took a while to respond, but they have confirmed that your change resolves the problem. Will you incorporate it into a winpty release at some point?

[rprichard]

Yeah, at some point I'll merge the fix and put out a new release.

[octachrome]

Any update on a new release? Thx

[cybertk]

Any update on a new release? Thx

[Rockin4Life33]

I recently started getting a the same error Error creating winpty: ConnectNamedPipe failed: Windows error 232 when I run node in a Windows 10 in BaSH, node v12.13.0. I do not use — nor have I ever — McAfee, I use Malwarebytes. I've used it for years and haven't had issues nor is there anything in Malwarebytes' logs that indicate any interference with winpty nor node. Ideas?

[louking]

I'm seeing this in PyCharm intermittently while using Windows Security. I've tried excluding these files from the scan (per instructions from PyCharm, not sure what versions these are), but that didn't help. Note turning off real-time scanning didn't fix the problem, so maybe it's something else.

• C:\Program Files\JetBrains\PyCharm 2019.1.3\lib\pty4j-native\win\x86_64\winpty-agent.exe
• C:\Program Files\JetBrains\PyCharm 2019.1.3\lib\pty4j-native\win\x86_64\winpty.dll

I'm not sure how to try the workaround in winpty mentioned above. Would I need to build that branch, or is there a version of this built I can drop in to try?

UPDATE: I re-read the comment above, and added these files to malwarebytes exclusions (I use both windows security and malwarebytes), and that resolved the problem. Leaving this here for others who may find this and see this workaround.