0

The problem at hand is to have a "Container" app and a "Child" app communicate via a named pipe. The problem is the pipe sometimes fails to be created.

When things go smoothly, communication works pretty well.

The problem I'm seeing is that sometimes the Pipe server will fail to initialize. I can see why it happens in some instances, namely that the previous version of my app is still running in the background and did not exit properly for some reason so it's hanging on to the pipe. But, I have also seen it fail when I put in a new random name for the pipe that should not be used by any other processes, this is the part that worries me. Perhaps it is a limitation set by the OS on the same process name OR on visual studio debug mode?

To illustrate this, I have some code that tries to create a server steam (the pipe server):

NamedPipeServerStream server = new NamedPipeServerStream(pipeName, PipeDirection.InOut, 1);

The exception I often see is this:

Could not create server:System.IO.IOException: All pipe instances are busy.

I have tried a few variations of this with security options passed to the pipe + increasing the number of allowed servers from 1 to something higher but then the "Child"/Client might connect to what I assume is another process that is not properly closed out, and hence the wrong pipe server.

My ideas are:

  • figure out a way to "force" take over a pipe.
  • figure out a way to close out all dead instances of my own app somehow?
  • negotiate a new pipe to use writing some random pipe name to a file that both apps can read in first? This seems overkill and still not ideal if I'm having the odd behavior when I can't create a pipe even if the name is different.

Since this is hard to recreate, I am simulating the problem by doing:

var pipeName = "myApp22";
NamedPipeServerStream server = new NamedPipeServerStream(pipeName, PipeDirection.InOut, 1);

// Here I would want to catch the exception and then force close, then repeat this:
NamedPipeServerStream server = new NamedPipeServerStream(pipeName, PipeDirection.InOut, 1);

Any input would be appreciated. Thanks.

Vukašin Manojlović
  • 3,717
  • 3
  • 19
  • 31
JasonAddFour
  • 153
  • 1
  • 1
  • 10
  • Possible duplicate of [C# all pipe instances are busy](https://stackoverflow.com/questions/18438016/c-sharp-all-pipe-instances-are-busy) – TAHA SULTAN TEMURI Jul 27 '18 at 12:36
  • I think it's a similar problem but I am having a slight variation, where sometimes even renaming the pipe by hand in my code and starting a new process will give me the error right away (not after 7hrs, but right away). This is the part that worries me the most since then I can't be sure a pipe will be available even if I always close it out properly. I should look into initialize the pipe with the "using" approach, though it is created in a thread and the pointer to the pipe server is passed to another class after a client connects. I'll have to research that more. – JasonAddFour Jul 27 '18 at 12:43
  • Anti-malware treats named pipes as a basic hazard. Especially so when used by an executable file that seemingly appeared from no-where a few seconds before the pipe is opened. So disable it or make an exclusion and see if that makes a difference. If it is Avast then get rid of it asap. – Hans Passant Jul 27 '18 at 12:47
  • That is one interesting gotcha I hadn't considered. How would the anti-malware be able to monitor which named pipes have been created? And how would that application be able to take over the pipe if it didn't know I was just about to create it? – JasonAddFour Jul 27 '18 at 12:57
  • My comment is not directly related. In my case, I was trying to speed up a workflow by using named pipe. It work most times, but sometimes it fail for no reason. I have been searching for post discussing should be use named pipe in an workflow environment? – Kemin Zhou Mar 26 '20 at 21:31

0 Answers0