A Plethora of Conhost.exe and PsExec.exe sessions remain open

[JNO]

After running a process on a small group of servers ( < 50 ), dozens of conhost.exe and psexec.exe sessions remain open, consuming server resources and slowing/stopping Batchpatch performance.

Link to task manager image – http://i59.tinypic.com/1i1weo.jpg

I’ve also had server owners complain of PsExec.exe sessions remaining open on their end, blocking them from establishing their own PsExec sessions.

Are they supposed to remain open indefinitely? Is there a way to configure a timeout for the connections?

Thank you,

Jason

[doug]

Jason – They should *not* remain open. In fact, if PsExec.exe is remaining open, then that means it is not finishing its work, and I would expect that you would not see progress in the BatchPatch grid either. The fact that you’re saying the connections are also remaining open on the target server as well is another indication that the process simply is not completing. The normal behavior is for you to start the action in BP, then psexec is launched for the duration of the action, and then psexec terminates and BP reports the status. If psexec doesn’t terminate, then BP will not update the grid with any changes, so essentially what I’m saying is that if psexec isn’t terminating then BP basically isn’t going to be able to complete most actions, including all Windows Update actions.

When you say that the connections remain open, consuming server resources and slowing/stopping BP, I think you might have it backwards. Obviously I haven’t looked at your server, so I can’t say for sure, but it seems like BP is “stopping” simply due to the fact that the psexec instances aren’t returning (or they aren’t returning quickly enough – not sure how long you waited or how quickly you expect them to return, but it depends on the action), but it’s not “stopping” because of a resource problem. It’s simply waiting for the psexec connections to close so that it can continue doing what it’s doing. If you’re installing 200 windows updates, it could take a couple hours, depending on the setup). 50 rows in a grid all running at the same time shouldn’t require a ton of resources. Maybe something like 100 megabytes of RAM for all the psexec instances. If the psexec connections never close, then BP simply waits, indefinitely for them to close. BP relies on the psexec processes to end because that’s how psexec works. If psexec is never ending, then it means it’s not working.

My question to you is has BP ever worked on your system? Is this a new problem? There is no configurable timeout for the psexec connections in BP. BP waits for them to close, otherwise BP can’t do what it needs to do. If none of them are returning then it does sound like there’s a problem, and BP basically isn’t working at all. I have never experienced nor heard of this happening before, so something might be jacked up with your system. As a start I would suggest you reboot the machine that’s running BatchPatch. After that you should make sure you have the latest version of psexec and then test running psexec at the command line to make sure that it is behaving properly. So for example you could run “psexec \targetcomputer IPCONFIG” in a cmd prompt. The normal behavior is for psexec.exe to open for just a handful of seconds. The target computer would see a psexesvc.exe in its processes list for that same handful of seconds. After the IPCONFIG command returns output to the cmd prompt, both psexec.exe and the target machine’s psexesvc.exe disappear. If psexec isn’t behaving properly when run from a cmd prompt, then BP certainly isn’t going to work.

I can’t really think of any reason why such a problem would occur. The only thought that comes to mind is what is the network connection like between the BP machine and the target machines? If there is very little bandwidth and a lot of latency, then perhaps that’s where your issue is. In that case you simply might not be able to execute 50 at a time. You might have to do just a few at a time. Not sure. It would require some experimentation. I’ve never run BP on such a severely limited network.

You probably already know this, but just in case you weren’t aware– you can kill all the psexec connections with a single command “taskkill /IM psexec.exe”

I hope this helps.

-Doug

[Author]

Posts