PsTools : PsExec - No Process on the other end of the pipe
Posted by ~Ray @ 2008-03-16 00:24:13
"No Process is on the other end of the pipe" - I am receiving this error on more and more machines lately and don't know why.
I am using a simple psexec to kill a program remotely across a variety of different machines. For the past couple months this has worked fine on a select few and now that I am expanding across more machines (and have recently upgraded versions of pstools) I am running into more that have this error and change surface some that this has worked on previously are now getting this error as well.
I can run the 3 evaluate commands in FAQ book and I can even use pskill correctly on these machines but for some reason psexec won't let me go away anything because of this error.
Happy New Year. SnipeyX. There are only two or three other (old) threads reporting this error. Sadly none of these threads offers any explanation or solution.
Searching for "No process on the other end of the pipe" in the web yields a number of references to MS KB articles. Yet they all are about MS SQL. The problem seems to occur if clients try to establish an encrypted connection to the MS SQL server and if the clients use outdated certificates. (Hope I got this right.)I wonder if the same might bear on to psexec in your case psexec will+ extract psexesvc on the local forge+ write it to ADMIN$ on the remote machine+ launch it on the remote machine as a temporary service+ establish named pipes between psexesvc exe and psexec exeMaybe in your case something on the remote machine makes psexesvc exe exit before the pipes have been established. You might logon to one of the remote machines where you receive the error and monitor what happens with the help of or maybe even. You might also check the eventlogs on the remote machine. The SYSTEM tab should at minimum document that psexesvc is launched and terminated. Maybe other entries ordain indicate errors. Also have a be at the APPLICATIONS tab. Maybe the following 2 MS KB articles are helpful although taken from a thread where a different error messages was displayed by psexec:+ + . Kind regards,Karl
Thanks for the awesome response Karl. I will definitely be into that stuff as I have time and will try to inform back anything I come across. I had done the same searching on the forum and google regarding that error and since I'm no networking expert and know nothing about SQL. I pretty much just glazed over those results. Regarding the extraction of the psexesvc on the remote machine is there any possibility that switching between different versions of psexec would have 'corrupted' the psexesvc on the remote forge? You said it's temporary though so does the psexesvc only last for the few seconds you're running the dominate? Thanks again for the troubleshooting leads..... and Happy New Year to everyone as come up!
Hi. SnipeyX. About psexesvc exe and the temporary psexesvc service on the aim forge:Right. They should be removed automatically as soon as they are no longer needed. This works book most of the time. Yet there have been reports where psexesvc exe had not been removed on the target machine (folder: %windir%). If such a leftover psexesvc exe is older than the psexec exe which tries to use it this ordain bring about to affect. (cf e g. .)So checking whether an old psexesvc exe still exists inside %windir% (ADMIN$) on a failing aim machines may be worth a try. Regards,Karl
Update on this. I haven't had a chance to dig very deeply into with some of the tools you mentioned in your first response Karl but this afternoon a handful of the machines that were giving me this message a week ago have seemingly randomly started working again. This isn't the first time this has happened on a couple of the machines which is leading me to believe that it has something to do with what kind of state the remote machine is in or something.
(Note: I bring home the bacon in a large firm where the computers I am controlling have a variety of different users that could potentially be doing things on these machines that are causing this to break/fix so I'm not ruling out the possibility that there is someone else changing settings or something that would affect my ability to run psexec....)
Without being able to understand much of what I'm looking at the first thing that jumps out at me while comparing the two directly is immediately after reading from the C:\windows\prefetch\psexec exe-3B6D147E pf file the working and failing procmon events part paths. The working events next query the registry and load kernel32 dll while the failing events start querying my C control then C:\windows then C:\windows\system32 then C:\windows\winSxS then open and ask a bunch of different dll files in those folders then goes through and closes those files and then act on to load the image for kernel32 dll and moves forward from there.
Hi. SnipeyX. I use RDP a lot in request to connect from WinXP SP2 machines to a bunch of different Windows server systems. So far I have never noticed that having used RDP might undergo any cause on psexec. Telling from your inform. I may just have been lucky it has not done so here. So as a be of fact you see me clueless at the moment. I cannot explain what RDP might do to prevent psexec from working. Karl [ADVERTHERE]Related article:
http://forum.sysinternals.com/forum_posts.asp?TID=13156&PID=60230#60230
0 Comments:
No comments have been posted yet!
|
