Hi Tom,
I'm sorry I did not respond to your question but .... I just have no idea,
what the answer might be. I guess I could try to debug it via WinDBG. But
that could be at least a couple of hours work; and I don't have time to
spend a couple of hours on every newsgroup question I don't know the
answer to!! Like other MVPs and newsgroup regulars I have a fulltime day
job, and a family, and I just hang out here in my (very limited) spare
time, answering whatever questions I can.
However ...
The first thing I'd try is toggling the "Run only when user is logged on"
setting - this setting could easily have unexpected side-effects. Whatever
you have set currently, try the opposite. Go back and forth a few times,
to be sure. You might also want to check the "History tab of the task -
it's possible that the Task is actually executing; it's just not
executing in your user session (ie, not visible to your desktop). If the
task executes in a different user context, it will not have access to the
interactive desktop - this is enforced in Vista, as a security measure. In
this case, you'd need to fiddle with the task settings to make sure it is
running in your own logged-on user context
Secondly: well as far as I know, there is no easy trace logging for Task
Scheduler, but you may be able to get some insights into the underlying
isseu by exporting the Task to XML. In Task Scheduler 2.0 (ie in Vista),
the Task Scheduler service runs a Task Object. The task Object can be
created in three different ways: programmatically, via C/C++ API calls; in
script, via a TaskService object; or by reading in an XML Task definition.
When you create a Task via the Task Scheduler MMC snap-in, you are simple
creating an XML text file, to define the task you wnt to run. The MMC is
just acting as a fancy text editor for you - it isn't directly
manipulating the task object which will be executed; only the XML
definition of the task. One could (in theory) just write the XML task
definition in Notepad, and let the Service run that, without ever defining
the task in the snap-in.
So, the cause of the problem you're seeing could be in 2 different places:
- the way in which the Task Scheduler service handles the Task Object; or
- the XML which is output by the Task Scheduler snap-in.
You can examine the XML by exporting it to a file. Highlight your task in
the Task Scheduler MMC, right-click, and choose Export. Then study teh
resulting XML via Notepad, or other text editor. You can make changes to
the XML file to "fine-tune" the behaviour of the Task, and then re-import
it into the Task Scheduler snap-in. You'll find links to the schema
definition and descrtion of all the XML task elements, via this link:
http://msdn2.microsoft.com/en-us/library/bb264558.aspx
In your case, for example, you'd probably want:
<StartWhenAvailable>true</StartWhenAvailable>
but other tags may also affect the behaviour.
You can also enable ddebug and diagnostic logging for Task Scheduler. This
may, or may not, shed some light on the problem. In Administrative Tools,
run Event Viewer. Navigate to Application and Service logs, Microsoft,
Windows, TaskScheduler. There are three logs here: operational, debug and
diagnostic. By default, only operational is enabled; debug and diagnostic
are disabled. Right-click each of debug and diagnostic and choose Enable.
This will cause the Task Scheduler service to log any significant debug or
diagnostic events, as well as teh normal operational events. This might
give you a few clues as to what's going on "under the covers".
If all else fails, open a Service Request with Microsoft PSS, and give
them a step-by-step explanation of precisiely how to reproduce the
problem. They can then go in and debug it in detail. Unlike MVPs, the PSS
guys do work for Microsoft, and do actually get paid to troubleshoot this
stuff
I wish I had a better answer for you. But I hope this helps a little bit.
