1

We have several Windows 2003 servers that we run utilities on using psexec. Recently, it stopped working on one of them. For those unfamiliar with it, here's how the process normally works:

Psexec:

  1. copies PSEXESVC.exe to \\target\admin$ (Typically C:\WINDOWS)
  2. installs it as a service and starts it
  3. communicates with the service to have the service start the requested program
  4. has the service wait for the exit status of the process
  5. displays the exit status to the user
  6. stops and deletes the service
  7. removes PSEXESVC.exe

On the affected server, I have verified everything happens except something in step 3. No matter what program I ask psexec to run (cmd, ping, ipconfig, etc.), it gives the message "command exited on target with error code 128."

This has been seen a few times on the sysinternals forums:

Some claim that the error is returned by the called command, but I think this is just an artifact of the way it's trying to get the exit code. net helpmsg 128 gives "There are no child processes to wait for.", so this makes me think it's failing to wait for the child because there isn't one.

I've verified that the service is in fact starting correctly, that the permissions to the requested program are identical between the working servers and the non-working server, and that psexec works if running from the affected server as local (e.g. with psexec cmd instead of psexec \\target cmd).

The only confirmed solution I've seen to this is rebooting the machine. While this is a production server, rebooting during the day is an option since its primary workload is batch style processing at night. However, I am hesitant to reboot, since I would really like to determine the cause of the psexec trouble, and right now the psexec process is being used for development purposes, so there's no production impact to holding off on the reboot.

laindir
  • 111
  • 1
  • 4
  • 1
    Not a fix, per se, but a workaround possibility... can you [enable WinRM for these servers](http://serverfault.com/q/429426/118258) and execute your cmd shell(s) that way? – HopelessN00b Jun 27 '14 at 18:23
  • We're exploring other techniques (PowerShell, WinRM, RDP), but in all honesty, we probably won't go that route. This is the first problem we've had with psexec, so if we can find the cause, we'll probably stick with it. Otherwise, the next time it happens, we'll probably reconfigure our current work to run as a service on the servers themselves. Thanks, though. And +1 for suggesting another good technology fit. – laindir Jun 27 '14 at 18:39
  • Start thinking ahead and plan for decommissioning Windows 2003, as its end of extended support nears (7/14/2015) http://support.microsoft.com/lifecycle/search/default.aspx?alpha=Windows+Server+2003+R2 – MichelZ Jun 28 '14 at 14:33
  • Thanks for the advice @MichelZ, we are transitioning away from Windows 2003, but I don't know whether that will solve this particular problem. Do you have some knowledge that this issue with psexec is specific to Windows 2003? Or is there a replacement technology that is native in newer Windows? – laindir Jun 30 '14 at 15:55

0 Answers0