Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use PsExec to deploy small .exe files to my workstations. Sometimes the .exe, for some reason, is incompatible with the system and opens a popup window with an error or some other message.

Is there any way to know when the executable is 'stuck' there requiring user interaction? On my side I just have psexec running and waiting for the .exe to return (which will never return because the popup is stuck there).

Since I run PsExec programmatically and I automate all the executions, when this Popup thing happens I find myself with hundreds of psexec processes stuck there and have no result back from them..

What's the best way to handle this sort of issue?


share|improve this question
If you do not find an answer here, go to the Sysinternals Forums, which are very good for help with the PStools. – paradroid Aug 14 '10 at 18:49

As a last resort try using one of the other automation tools in addition to PsExec to deal with the popups. Like AutoIt.

I would guess that this will have to be the way forward for you since there is no standard that each software must adhere to.

share|improve this answer

PAExec has a timeout option (-to) that will terminate the process after the specified number of seconds. I would highly suggest you switch from PSExec to PAExec.

share|improve this answer

psexec has an -i option that should work.

-i Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is.

Also, you could use some sort of pslist.exe script to monitor the process spawned on their system and see how long it's been there. If msiexec is hanging for 5 mins, that probably means it's hung.

share|improve this answer
Yeah, but i dont want to show the user the popup or whatever made it hung... I guess a timing thing would be the only way to solve this. – Luca Matteis Aug 14 '10 at 20:12
You can go ghetto and have your .bat file write a "working.txt" file, and then delete it when it's done. If that file is there the next morning the proc can be killed. :) – Matt Aug 14 '10 at 20:22

The best way to handle this sort of situation is to test before trying to apply automation.

One easy, albeit brutal, way to deal with the stuck processes is to run a separate batch using pslist and pskill at a later time when the psexec processed that would complete normally would have done so. Use pslist to test for psexec still running on the remote machine and pskill to terminate any that are found.

share|improve this answer
Okay, but what if psexec is actually doing something and it's just taking a really long time? Is there a way to understand that it's stuck there with a popup? – Luca Matteis Aug 15 '10 at 9:11
@Luca, You would need to run another process on the client to detect the popup. That is really getting into a programmatic solution. – John Gardeniers Aug 15 '10 at 21:30
I'm already running my psexec routine programmatically... – Luca Matteis Aug 16 '10 at 9:04
@Luca, I'm not talking about how you run psexec. I'm referring to what will be required on the client to achieve what you want to do. – John Gardeniers Aug 16 '10 at 21:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.