[9492:ShellIpcClient] ipc_socket_win.cc:162:Connect CreateFile on pipe failed:

[Bob]

TCC 29.00.17 x64 Windows 10 [Version 10.0.19044.2604]
Copyright 2022 JP Software Inc. All Rights Reserved
Registered . . . . .

Shortly after starting the initial (usually) TakeCommand instance after logging into my Windows account the following error message often occurs.

> 2023-02-15T16:32:09.931ZE [9492:ShellIpcClient] ipc_socket_win.cc:162:Connect CreateFile on pipe failed:
2023-02-15T16:32:09.931ZE [9492:ShellIpcClient] ipc_socket_win.cc:163:Connect 231: All pipe instances are busy.

This message is output multiple times (commonly 4 or 5 - one after the other) when TakeCommand starts and (generally) before I have entered any commands at the prompt. After these error message(s) TakeCommand functions normally.

What do these error mesages mean? Are they a problem caused by my configuration or some other artifact of my ignorance?

 

[Bob]

Shortly after starting the initial (usually) TakeCommand instance after logging into my Windows account the following error message often occurs.



This message is output multiple times (commonly 4 or 5 - one after the other) when TakeCommand starts and (generally) before I have entered any commands at the prompt. After these error message(s) TakeCommand functions normally.

What do these error mesages mean? Are they a problem caused by my configuration or some other artifact of my ignorance?

FWIW my tcstart.btm follows:

:: tcstart.btm
@ECHO OFF

:: Set COMSPEC for Apps that use it to call command processor
:: without protecting for spaces in the path [e.g. lua 5.1.x]
set COMSPEC=%@sfn[%_cmdspec]

:: Exit if running in a pipe or transient process
if %_pipe != 0 .or. %_transient != 0 quit

:: alias /r "%ProgramFiles%\JPSoft\recalias"
set /r "%ProgramFiles%\JPSoft\recsets"

:: Load USER's command history and remove duplicates if it exists
iff exist "%LOCALAPPDATA%\JPSoft\HISTFILE" then
history /r "%LOCALAPPDATA%\JPSoft\HISTFILE"
history /n
endiff

:: Load USER's directory history and remove duplicates if it exists
iff exist "%LOCALAPPDATA%\JPSoft\DHISTFILE" then
dirhistory /r "%LOCALAPPDATA%\JPSoft\DHISTFILE"
dirhistory /n
endiff

set TREEEXCLUDE=d:\;e:\;f:\;g:\;h:\;I:\;J:\;K:\;L:\;M:\;N:\;O:\;P:\;Q:\;R:\;S:\;T:\;U:\;V:\;W:\;X:\;Y:\;Z:\;\\*\*

:: Update the Extended Directory Search database if not done today
iff %_admin == 1 .and. "%@filedate[%ProgramData%\JP^ Software\jpstree.idx]" != "%_date" then
start /min /low /c cdd /s
endiff

iff %_tctab == 1 then
CDD /T %USERPROFILE%\Documents
else
CDD %USERPROFILE%\Documents
endiff

::CLS /S

 

[vefatica]

Where is the message output? If it's in the TCC tab, it's coming from TCC. Does it happen when you start TCC.EXE without TCMD?

 

[rconn]

That message isn't coming from TCC (or Take Command). It's probably coming from a third-party dll that's being injected into TCC.EXE.

 

[Bob]

Where is the message output? If it's in the TCC tab, it's coming from TCC. Does it happen when you start TCC.EXE without TCMD?

Thanks I will try that.

 

[Bob]

That message isn't coming from TCC (or Take Command). It's probably coming from a third-party dll that's being injected into TCC.EXE.

Thanks! I will see if I can identify the culprit!

 

[Charles Dye]

Bob, do you by any chance have Google Drive installed?

 

[Bob]

Bob, do you by any chance have Google Drive installed?

Yes and it is one of my prime suspects. Just haven’t figured how to confirm that it’s the culprit.

 

[Charles Dye]

Yes and it is one of my prime suspects. Just haven’t figured how to confirm that it’s the culprit.

Same here. Rex, I suspect you could probably replicate this by installing Google Drive on a test system.

 

[Bob]

I had been trying Vince's suggestion to just run TCC without TakeCommand for several days and did not experience the error mesage.

Today after logging on I shut down Google Drive File System before starting TakeCommand. After executing a couple of commands a slew of error messages involving GoogleDriveFSPipe were spontaneously output. [A truncated copy of the event follows. The actual error output continues multiple times - I was too lazy to count .]

This appears to indicate some kind of interaction between TakeCommand and Google Drive File System [70.0.2.0 in this case]. Is this expected or is it the result of some configuration problem with my system?

[--]which sql
sql*ite is an alias : "%Public%\sqlite\sqlite3.exe"

[--]sql --version
3.40.0 2022-11-16 12:10:08 89c459e766ea7e9165d0beeb124708b955a4950d0f4792f457465d71b158d318

[--]2023-02-20T02:32:43.213ZE [13364:ShellIpcClient] shell_ipc_client.cc:132:Co
nnect Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T02:32:43.216ZE [13364:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T02:32:43.216ZE [13364:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T02:32:43.216ZE [11024:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T02:32:43.216ZE [13364:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T02:32:43.216ZE [11024:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T02:32:43.217ZE [11024:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T02:32:43.217ZE [18832:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T02:32:43.217ZE [11024:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

 

[Bob]

Whatever the cause of the ShellIpcClient error messages it appears to be repeatable since it happened again today when I shutdown Google Drive File System before starting TakeCommand and executing the same two commands as yesterday. [Again error message output truncated and number of occurrences not counted.]

[--]alias sql
"%Public%\sqlite\sqlite3.exe"

[--]sql --version
3.40.1 2022-12-28 14:03:47 df5c253c0b3dd24916e4ec7cf77d3db5294cc9fd45ae7b9c5e82ad8197f38a24

[--]2023-02-20T14:56:01.664ZE [21324:ShellIpcClient] shell_ipc_client.cc:132:Co
nnect Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T14:56:01.665ZE [21324:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T14:56:01.666ZE [7604:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T14:56:01.666ZE [7604:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T14:56:01.668ZE [13876:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T14:56:01.669ZE [13876:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T14:56:01.670ZE [21324:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T14:56:01.670ZE [21324:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T14:56:01.671ZE [7604:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T14:56:01.672ZE [7604:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-20T14:56:01.672ZE [13876:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-20T14:56:01.673ZE [13876:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

 

[Charles Dye]

I had been trying Vince's suggestion to just run TCC without TakeCommand for several days and did not experience the error mesage.

I've noticed a process called crashpad_handler which attaches to Take Command, not to TCC. Try tasklist /r tcmd and see if you spot it.

I honestly don't believe this has anything to do with any commands you might enter at the prompt. I often get it before typing anything. I think this gribble is just dumped by Google Drive during startup, to any console window it finds itself attached to. One workaround might be to simply wait until Google Drive completes its startup before you launch Take Command.

 

[Bob]

I honestly don't believe this has anything to do with any commands you might enter at the prompt. I often get it before typing anything.

I agree and I too have seen it occur without entering any commands at the prompt.

I think this gribble is just dumped by Google Drive during startup, to any console window it finds itself attached to. One workaround might be to simply wait until Google Drive completes its startup before you launch Take Command.

FWIW Both days after shutting down Google Drive File System I checked with Task Manager before starting TakeCommand and did not see any of the usual multiple (more than 4) Google Drive processes listed!

 

[Bob]

Now I've also unchecked File Explorer in the TakeCommand View menu drop down to see if it might be involved and have started TakeCommand with Google Drive File System running several times without errors. [The TakeCommand File Explorer is a nice feature but I rarely, if ever, use it because I am an old fossil CLI guy since way before 4DOS!]

I know it's way too early to draw any conclusions but it is interesting.

Edited: Shucks it was too early! It just happened with TakeCommand File Explorer unchecked! It may just be circumstance but there was only one occurrence of the error message this time.

 

[Bob]

This morning I disabled Google Drive File System from starting when I log in. I then logged out and relogged in. According to Task Manager the only Google processes running were Google Crash Handler and Google Crash Handler (32bit).

Then I started an instance (the first after logging in) of TakeCommand. Without entering any commands at the prompt, the error output occurred! [truncated for posting]

If it isn't TakeCommand looking for GoogleDriveFSPipe on start up then what third-party dll is being injected into TCC.EXE when TakeCommand starts?? OneDrive - Personal and Everything are starting automatically on login but it doesn't seem likely that one of them could be the culprit.

I do have Extended Directory Search Search Level set to 3 and the [4NT] section of TCMD.INI contains the line EverythingSearch=Yes. In addition tcstart.btm executes start /min /low /c cdd /s if the filedate of jpstree.idx is not equal to %_date.

[--]2023-02-21T14:35:50.582ZE [13488:ShellIpcClient] shell_ipc_client.cc:132:Co
nnect Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-21T14:35:50.583ZE [13488:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-21T14:35:50.583ZE [13488:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-21T14:35:50.583ZE [17808:ShellIpcClient] shell_ipc_client.cc:132:Connect Can't connect to socket
at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-21T14:35:50.583ZE [13488:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

2023-02-21T14:35:50.583ZE [17808:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133

 

[vefatica]

You can see what DLLs are attached to the TCC and TCMD processes with "ListDlls" or "Depends" from SysInternals. The first of those is a command line app. ListDLLs - Sysinternals

 

[Bob]

You can see what DLLs are attached to the TCC and TCMD processes with "ListDlls" or "Depends" from SysInternals. The first of those is a command line app. ListDLLs - Sysinternals

Thanks I'll give that a try later today.

 

[Bob]

ShellIpcClient struck again and the cdd /s in tcstart.btm seems to be eliminated as the cause because jpstree.idx was last modified at 8:36 AM and it's now 11:20 AM. FWIW Google Drive File System is still not enabled/running.

 

[vefatica]

You might also try disabling Google Crash Handler. It might be in TaskMgr\StartUp. And, though Google Drive File System is not running, it might have an installed/running driver. Perhaps you could see that in DeviceManager or with sc query type= driver.

 

[Bob]

You might also try disabling Google Crash Handler. It might be in TaskMgr\StartUp. And, though Google Drive File System is not running, it might have an installed/running driver. Perhaps you could see that in DeviceManager or with sc query type= driver.

OK I used Task Manager to end the GoogleCrashHandler and GoogleCrashHandler64 tasks and then executed tasklist as the first command after starting TakeCommand (for the first time) to see if there were any Googleish tasks running. As you can see there were none shown and the error dump was output before I could enter another command.

[--]tasklist | grep -i google

[--]2023-02-21T19:54:47.313ZE [20120:ShellIpcClient] shell_ipc_client.cc:132:Co
nnect Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
2023-02-21T19:54:47.313ZE [20120:ShellIpcClient] shell_ipc_client.cc:609:operator() Failed to connect to
the server: NOT_FOUND: Can't connect to socket at: \\.\Pipe\GoogleDriveFSPipe_bchapman_shell
=== Source Location Trace: ===
apps/drive/fs/ipc/shell_ipc_client.cc:133
. . . . . .
. . . . . .
. . . . . .
[--]listdlls tcmd | grep -i google
0x00000000b3660000 0x1560000 C:\Program Files\Google\Drive File Stream\70.0.2.0\drivefsext.dll

So C:\Program Files\Google\Drive File Stream\70.0.2.0\drivefsext.dll is loaded when TakeCommand starts (or is running) even though there (apparently?) are no Google tasks running.

I guess I didn't expect that. [However, many things that I don't expect happen daily! ]

 

[TEA-Time]

Yup, the "ext" part of drivefsext.dll means shell extension, and those are loaded by File Explorer no matter what.

Btw, SysInternals' GUI program Process Explorer is good for seeing what DLLs are attached to processes (and LOTS of other stuff), too.

 

[TEA-Time]

You can try unregistering that extension with "regsvr32 /u drivefsext.dll" from the folder it's in (or specify the whole path), but you may have to at least log out if not restart to make explorer.exe let go of it. Then "regsvr32 drivefsext.dll" to reregister it after you've experimented.

Even though it's a command line utility, regsvr32 by itself shows its usage.

 

[Bob]

You can try unregistering that extension with "regsvr32 /u drivefsext.dll" from the folder it's in (or specify the whole path), but you may have to at least log out if not restart to make explorer.exe let go of it. Then "regsvr32 drivefsext.dll" to reregister it after you've experimented.

Even though it's a command line utility, regsvr32 by itself shows its usage.

View attachment 3850

Thanks! I may try that when I get some more time -- and nerve!

 

[TEA-Time]

Yeah, that stuff can be a little scary , but I've never had anything bad happen (knock on wood!).

 

[Bob]

Today [02/23/23]

TCC 29.00.17 x64 Windows 10 [Version 10.0.19044.2604]
Copyright 2022 JP Software Inc. All Rights Reserved
Registered to . . . .

[--]2023-02-23T15:27:33.764ZE [17104:ShellIpcClient] ipc_socket_win.cc:162:Connect CreateFile on pipe failed:
2023-02-23T15:27:33.765ZE [17104:ShellIpcClient] ipc_socket_win.cc:163:Connect 231: All pipe instances are busy.

Well at least it's repeatable! Steps to repeat: Start TakeCommand [Sooner or later it will happen.]

Yesterday I thought it might be the line CDD /T %USERPROFILE%\Documents [if %_tctab == 1] at the end of my tcstart.btm but the error still occured without that line!

For now I've run out of ideas and I need to step away for a while and return to priority personal work.

Perhaps the next version of Google Drive File System [or TakeCommand] or some other system configuration change will fix [or hide] the problem. Meantime, I guess my options are:

• Switch to TCC solely. I'm not too old to learn new habits but I would miss many TakeCommand features.
• Keep using TakeCommand and live with the occurance of the error from time to time.