7

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?

icelava
  • 870
  • 4
  • 13
  • 28

5 Answers5

2

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

Warren Stevens
  • 181
  • 3
1

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

Christopher_G_Lewis
  • 3,647
  • 21
  • 27
0

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.

Adam Brand
  • 6,057
  • 2
  • 28
  • 40
  • 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 03:59
  • If I run the scheduled task as my own user account, which is administrator, they can be killed. – icelava Jul 29 '09 at 04: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 04:19
  • I updated my answer with an alternate approach. – Adam Brand Jul 29 '09 at 04:22
  • But when i tested this using another administrator account, the behaviour surfaces. – icelava Jul 29 '09 at 05:26
  • Hm...then I'm out of ideas. – Adam Brand Jul 29 '09 at 14:44
0

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.

Bork Blatt
  • 453
  • 2
  • 7
  • 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
0

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...

M Aguilar
  • 879
  • 5
  • 5
  • 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