Task Scheduler unreliable in NT/2000/XP

[Mike Reed]

I have encountered a problem with Windows Task Scheduler at many
client sites over the years, where tasks may run flawlessly for days
or weeks, then magically - they stop running (listing "Could Not
Start" for the task's status). To correct the problem, I simply have
to re-enter the task's password - the SAME password that has always
been there. The task will then run for several more days/weeks! This
has been a problem in Windows NT 4.0(sp6a) SERVERs AND XP Prof
workstations. And no surprise, since XP probably uses some of the
same underlying code as NT! I have talked with other consultants -
and we've all concluded that Microsoft's task scheduler is "unreliable
at best". I would love to find out the real cause of the problem and
solve this once and for all... More info: generally a single domain
exists, YES user account associated with task ALWAYS has/had a
password...

SchedLog.txt reports: The attempt to retrieve account information for
the specified task failed; therefore, the task did not run. Either an
error occurred, or no account information existed for the task. The
specific error is: 0x8004130f: No account information could be found
in the Task Scheduler security database for the task indicated.

How does Windows lose the "account information"? I can log in as the
same user assigned to the task - without a problem!

Thanks to all,

-Mike

 

[Colin Nash [MVP]]

A couple of causes of this problem were corrected in one of the Windows 2000
Service Packs (SP4 I think.) The causes are described in the following
articles:

http://support.microsoft.com/default.aspx?kbid=328773

http://support.microsoft.com/default.aspx?scid=kb;en-us;826895


I couldn't find any info about this on XP - but make sure you have SP1 for
XP.

 

[Pegasus \(MVP\)]

There is a known issue with the Task Scheduler: It loses all account
details during the transition from standard time to daylight saving
time (and back), but only on machines where the system is installed
on a FAT32 partition. Machines with NTFS partitions are not
affected.

Perhaps the same happens when you manually change the time
by more than a certain amount.

 

[Mike Reed]

Thanks, but your explanation doesn't explain why Task Scheduler loses
account information every few days up to several weeks. The changover
from standard to DST (and back) only occurs twice a year...

 

[Mike Reed]

Thanks for the tips Colin! Most, if not all, of my clients are
configured with a small FAT partition on their NT 4.0 (sp6a) systems.
Plus, they have the latest version of IE installed - so I do meet a
number of the criteria mentioned in those KB articles...

It's a real shame that MS has left such a critical bug remain in all
their OS's, from NT thru XP. Task Scheduler, as least for me and my
clients, is a vital tool for scheduling mission critical backups,
virus definition updates etc. I thought that keeping IE up-to-date
was a smart thing to do - but the KB article implies otherwise I
wonder how many more years and versions of Windows will be plagued by
this?

Come on Microsoft - slow down a little and spend more time fixing your
existing products rather than rushing new products out the door (along
with the inherent bugs)!

 

[Pegasus \(MVP\)]

Convert one of your machines to NTFS and see if it makes
a difference.

 

[Guest]

I am running xp with NTFS and having the same issue, so that is not the solution. What else could it me

 

[Pegasus \(MVP\)]

The vast majority of all Scheduler issues are caused by
either of these:
- Inappropriate coding (e.g. failing to fully qualify executables);
- Expecting a screen output, waiting for user input
(most scheduled tasks run invisibly in the background);
- Insufficient access permissions;
- Other coding errors.

All of these can be identified by implementing simple
batch file diagnostic measures. Since you've written
nothing at all about your specific problem, it is not possible
to suggest possible reasons for the failures you observe.

I am running xp with NTFS and having the same issue, so that is not the

solution. What else could it me?

 

[Guest]

I am running xp pro in a domain with all patches applied

The programs that are being run are almost all vb6 applications with command line switches to do various overnight processing (address CASS, CreditCard batching, data transfers, data sync...)

The programs run for day/weeks/months at a time and have no problems, then out of the blue they will fail with the exact same senarios and error messages through thread

If I go into each job and retype the password everything starts working fine

Thanks for your help

-R