Task Scheduler only killing cmd.exe but not its child processes

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?