Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Our customer has some Windows 2003 servers running batch jobs activated by Task Scheduler. The actual programs performing the work are custom .exe processes, and they are aggregated into .cmd scripts so that they get launched together by Task Scheduler when the scheduled interval comes by. The lines within the cmd scripts may or may not use the Call command to launch the separate .exe programs.

In this setup, Task Scheduler is effectively monitoring cmd.exe, and when using Process Explorer, one can observe that the child .exe processes are parked under the cmd.exe process tree. However, when Task Scheduler kills cmd.exe due to exceeding the permissible time limit, the child .exe processes may not be killed along with their parent and become orphaned. Those processes remain stalled indefinitely. Due to the state of the process threads shown in Process Explorer, i suspect those processes end up in error and popped up a .NET debugger dialog box (these are .NET applications) which cannot be seen since the batch job user is a separate user account.

Initially when i was investigating this behaviour on my Windows XP workstation, I observed that child .exe processes launch from my test .cmd script do get killed together with the cmd.exe when Task Scheduler decides time is up. There was no way I could orphan the child processes.

Based on a hunch, i eventually moved over to a Windows 2003 machine to test this. Similarly, the child processes to get terminated like those in my workstation. My second step was then to use another user account to run the scheduled task. This time round, cmd.exe gets killed after the time limit is exceeded, but the child processes remain standing, just like what my customer observed in their production servers.

If i preemptively logon that batch user account (which just so happened to be another admin account) to claim a desktop session, any error or info pop-ups from my test .exe programs would be routed and rendered on that desktop, allowing me to see the actual user output. If i only logon after the scheduled task had been invoked, the desktop session will not "reclaim" the existing processes' windows; they stay hidden forever.

My question is, what condition(s) am I missing here that can cause Task Scheduler not to wipe out the child processes under a cmd.exe? What is special about using another account that would induce this behaviour, but not when using my current administrator account to run the schedued task?

share|improve this question
    
We have the same problem. Did you ever get this solved? –  Bengt Jun 29 '11 at 12:30
    
Nope ..... T__T –  icelava Jun 29 '11 at 14:04

5 Answers 5

Try using "Taskkill /T" on the command line. (/T = “…Terminates the specified process and any child processes which were started by it…”)

If you have multiple processes running (we often have 5 or more "powershell.exe" running) then add the "Command Line" column to the "Details" tab in Task Manager. That should make it clear which Process ID is the one you want to kill off

share|improve this answer

Processes are independant in Windows - Killing a parent process will not automatically terminate a child process.

share|improve this answer
    
If that is the case, why would Task scheduler ending cmd.exe also end the other .exe processes in my test cases? –  icelava Mar 22 '10 at 3:33

I don't know that it will solve your problem, but if it is related to the popup boxes (and it might be - the app is in a faulted state, and suspended while the non-existent user decides what to do about it).

Take a look at http://blogs.msdn.com/shawnfa/archive/2004/07/15/184490.aspx, and see if you can't get rid of those boxes...

share|improve this answer
    
While that is interesting note, I am asking about what causes a child process to get orphaned or not after the parent cmd.exe is terminated. –  icelava Jul 30 '09 at 18:00

How about using the pskill utility, which is part of the SysInternals suite. This program can kill processes by name. I would add a scheduled task, which will run a few minutes after you expect the processes to be finished, that will run pskill to terminate them.

PSKill can also run under user credentials you supply on the command line.

share|improve this answer
    
I am not asking about killing processes. I am asking about what causes a child process to get orphaned or not after the parent cmd.exe is terminated. –  icelava Jul 30 '09 at 17:58

If you think it is due to a debugger message popping up, have you tried wrapping the code in a try{}catch{} block and logging the error?

Otherwise, maybe what you could do is have the processes write the output of WindowsPrincipal wp = new WindowsPrincipal(WindowsIdentity.GetCurrent())

I suspect that the children are somehow escalating their priveledge level to Administrator and then can't be killed with the parent.

To test this without modifying code, you could write another scheduled task that tries to kill the other processes using taskkill. This scheduled task should be run as the Administrator. If that works, then it looks like it is a security issue.

share|improve this answer
    
those programs were not written by us and we are not allowed to modify them unless there are serious problems that call for fixing them. my question here is not about .NET application development. It is about the Task Scheduler and process tree control. –  icelava Jul 29 '09 at 3:59
    
If I run the scheduled task as my own user account, which is administrator, they can be killed. –  icelava Jul 29 '09 at 4:00
    
Right, because your application then starts in the right security context. But I suspect the other apps escalate their security context, making it impossible for non-administrator accounts to then kill them. –  Adam Brand Jul 29 '09 at 4:19
    
I updated my answer with an alternate approach. –  Adam Brand Jul 29 '09 at 4:22
    
But when i tested this using another administrator account, the behaviour surfaces. –  icelava Jul 29 '09 at 5:26

protected by Sven Apr 10 at 10:57

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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