Hello :-)
This is a bit of an odd request. I am on a bit of a detective case right now, and the problem I am trying to figure out isn't with TCC itself, but the evidence suggests that TCC, or something TCC is doing, plays a key role. Let me explain. :-)
I am a software developer and one of my projects involves a local Named Pipe server to which multiple clients can connect. Recently, I discovered a bizarre problem, where if many clients started in quick succession, some of them wouldn't be able to connect to the server at all (Windows behaves as if the server doesn't exist). Naturally, being a TCC user, the way I launched by barrage of clients was:
for /L %i in (1,1,50) do start Client.exe
When this is run, 50 windows pop up, but some very significant subset of them (10+ typically) at random get an error from the OS saying that no such named pipe server exists, even when the processes immediately before and after might succeed in connecting.
This immediately made me wonder if my pipe server isn't implemented properly, but after a good deal of piece-by-piece deconstruction and consultation with documentation and reference implementations, I can find nothing wrong with my server. Microsoft's documentation also specifically states that a client attempting to connect to a pipe will wait for the pipe server to come into existence if necessary. So, I set about creating a minimal reproduction. As part of this reproduction, I created a project to launch Client.exe in a controlled manner (and a manner repeatable by people who are not blessed to know the wonder of TCC :-). My project launches Client.exe in the most straightforward manner possible. I'm using .NET, so the OS API is thinly wrapped, but I am in essence doing nothing other than a straightforward CreateProcessEx (Process.Create). I could not reproduce the problem. Even if my driver application launches many hundreds of client instances as fast as it can, every single one gets its own connection to the server. I gradually reintroduced pieces so that my "minimal" reproduction became closer and closer to the real server, but nothing would reproduce the problem. Finally, tearing my hair out trying to figure out how it was different, I happened to use a for loop in TCC to start my minimal reproduction's Client.exe using the START built-in. Immediately, the problem recurred. I pared my test app back down, and the problem continues to occur but only if I am using TCC's START to launch the client processes.
Therefore I am wondering whether anyone from JP Software might be able to shed some light into what exactly TCC's START is doing beyond just calling CreateProcessEx to launch a child process. It seems that it must be doing something and whatever it is is causing some bizarre interference with Windows' named pipe infrastructure. Could it be related to jobs? I'm trying to figure this out, to see whether there's anything I need to change in my server to improve its reliability. I currently only know how to reproduce this problem using TCC to START the client processes, but without knowing why it is happening, I can't help but worry that whatever the underlying cause is, it could end up being accidentally triggered some other way and cause issues for our software down the road.
If necessary, I can probably share my minimal reproduction project (three .NET console applications, Server, Client and ClientRunner) if there's some chance that it'll help isolate the cause.
Hoping you can help me :-)
Thanks very much,
Jonathan Gilbert
This is a bit of an odd request. I am on a bit of a detective case right now, and the problem I am trying to figure out isn't with TCC itself, but the evidence suggests that TCC, or something TCC is doing, plays a key role. Let me explain. :-)
I am a software developer and one of my projects involves a local Named Pipe server to which multiple clients can connect. Recently, I discovered a bizarre problem, where if many clients started in quick succession, some of them wouldn't be able to connect to the server at all (Windows behaves as if the server doesn't exist). Naturally, being a TCC user, the way I launched by barrage of clients was:
for /L %i in (1,1,50) do start Client.exe
When this is run, 50 windows pop up, but some very significant subset of them (10+ typically) at random get an error from the OS saying that no such named pipe server exists, even when the processes immediately before and after might succeed in connecting.
This immediately made me wonder if my pipe server isn't implemented properly, but after a good deal of piece-by-piece deconstruction and consultation with documentation and reference implementations, I can find nothing wrong with my server. Microsoft's documentation also specifically states that a client attempting to connect to a pipe will wait for the pipe server to come into existence if necessary. So, I set about creating a minimal reproduction. As part of this reproduction, I created a project to launch Client.exe in a controlled manner (and a manner repeatable by people who are not blessed to know the wonder of TCC :-). My project launches Client.exe in the most straightforward manner possible. I'm using .NET, so the OS API is thinly wrapped, but I am in essence doing nothing other than a straightforward CreateProcessEx (Process.Create). I could not reproduce the problem. Even if my driver application launches many hundreds of client instances as fast as it can, every single one gets its own connection to the server. I gradually reintroduced pieces so that my "minimal" reproduction became closer and closer to the real server, but nothing would reproduce the problem. Finally, tearing my hair out trying to figure out how it was different, I happened to use a for loop in TCC to start my minimal reproduction's Client.exe using the START built-in. Immediately, the problem recurred. I pared my test app back down, and the problem continues to occur but only if I am using TCC's START to launch the client processes.
Therefore I am wondering whether anyone from JP Software might be able to shed some light into what exactly TCC's START is doing beyond just calling CreateProcessEx to launch a child process. It seems that it must be doing something and whatever it is is causing some bizarre interference with Windows' named pipe infrastructure. Could it be related to jobs? I'm trying to figure this out, to see whether there's anything I need to change in my server to improve its reliability. I currently only know how to reproduce this problem using TCC to START the client processes, but without knowing why it is happening, I can't help but worry that whatever the underlying cause is, it could end up being accidentally triggered some other way and cause issues for our software down the road.
If necessary, I can probably share my minimal reproduction project (three .NET console applications, Server, Client and ClientRunner) if there's some chance that it'll help isolate the cause.
Hoping you can help me :-)
Thanks very much,
Jonathan Gilbert