Thanks for posting the info, I'll give it a try at some point.

In reply to a post by StephenTodd:

Just to say that my scheduled task has been working consistently for over a week (Windows 8).

In case it helps anyone, exported XML below (sorry it is a bit long):
I've left the details such as Author, UserId and WorkingDirectory; those will obviously need a change for use by anyone else.

I'm not familiar with interpreting the xml output, but I can see that you are still directly running the exe rather than the VBS script & that you have specified the working directory:-

<Command>D:\Temp\HG612_Modem_Stats\Scripts\HG612_stats.exe</Command>
<WorkingDirectory>D:\Temp\HG612_Modem_Stats\Scripts</WorkingDirectory>

Are you running the task on a DAILY basis for 24 hours, repeated each day rather than our default of ONCE, indefinitely?

Also, is this the the bit that sets "Do not store password"?:-
<LogonType>S4U</LogonType>

Hi.
First a disclaimer: I'm not saying that this is the way I think it should be done,
just a comment that this is a way that has worked for me and so may help others if they have issues.

Yes, not using the VBS as discussed before. Basically a desire to keep things as stripped down as possible for my environment.
Not sure whether this is appropriate for other environments (though I don't see why it shouldn't be),
and also not sure if all the choices I made can also be made from an automated script as by the Settings Editor.

The VBS seems to have two purposes; to launch quietly and to launch in the correct current directory.
Launching quietly comes from not ticking 'Run only when the user is logged on' (I think), or maybe from the 'Do not store password, ...'
The correct directory is ensured by specifying it in the <WorkingDirectory>
As discussed before, some curiosity of Windows 8 prevents the VBS launching properly; which can be overcome with the extra HG_612_Run.exe that Ronski provided.
My use of a different directory was just experimental setup which I haven't been bothered to change.

I changed the scheduling as it wasn't working smoothly while I was experimenting.
Sometimes it didn't retake after I had made an experimental change.
That was why I added the 'At task creation/modification' trigger (<RegistrationTrigger> in the XML).
I think that the use of 'At startup' (<BootTrigger>) rather than 'On a schedule: one time' was random experimentation rather than informed intent.
So the main trigger is the one that starts at boot time and repeats every minute. Should have the same effect as a 'once' and repeat every minute.
The other is to make sure it keeps working if I make an experimental change.

Just checked and yes the S4U (service for user) is the 'Do not store password' bit.
See http://msdn.microsoft.com/en-gb/library/windows/desk...

In reply to a post by StephenTodd:

Hi.
First a disclaimer: I'm not saying that this is the way I think it should be done,
just a comment that this is a way that has worked for me and so may help others if they have issues.

Yes, not using the VBS as discussed before. Basically a desire to keep things as stripped down as possible for my environment.
Not sure whether this is appropriate for other environments (though I don't see why it shouldn't be),

The VBS is there mainly just to ensure invisibilty regardless of user login settings.
Depending whether users need to enter their login password or not, running the exe directly can cause cmd.exe to flash up briefly, also seeing it minimised briefly in the task bar on Windows 7 & Vista.

XP has different requirements again to a) ensure it keeps running & b) to ensure it is invisible.

and also not sure if all the choices I made can also be made from an automated script as by the Settings Editor.

RONSKI's the man who can confirm that one way or the other.

The Do not store password part was to combat a known Vista bug where tasks sometimes stop running after a couple of hours, sometimes days & didn't always restart again following a PC reboot.


Thanks for all the other detail.
Most interesting & useful indeed.

Edited by deleted (Tue 26-Mar-13 20:39:00)

Not all options are available from the the command line via SCHTasks, in theory I should be able to do it via the XML export/import options though. I'll need to find some time to make the modifications and try it though, at least with my laptop running W8 I'll be able to test it.

Once again, for those interested (not many were before), alternative more interactive graphing at
http://www.programbits.co.uk/modemGraph/plotstats.html

Requires modern browser (latest Chrome, IE, Opera and Firefox all work for me).

Just noticed that task scheduler forgot to schedule stats collection from 16:51 on 28 March until this morning.
I can't see any reason; just seems to be a typical task scheduler failure?
I'm 99% sure that this is a task scheduler problem and not to do with the stats program.

No particular issue for me as my Internet has been reasonably steady over that time,
just reporting for reference after commenting before how it had been behaving correctly.

Thanks for the update, it's certainly nothing to do with the program, I've tested it with another scheduled task just updating a text file and it failed.

I'm surprised I've not had any replies to my threads on various Ms forums.

perhaps the only way around it on W8 would be to run it as a service with it's own built in time trigger.

Thanks for the response. I'm not sure Task Scheduler is any worse on Windows 8 than other windows: I think it has always been a bit iffy. I had lots of gaps in my stats pre Windows 8; using the 'standard' scheduling. I know some of these were due to the old script getting a bit confused and locking itself out, but I'm pretty sure some were just Task Scheduler errors.

Running as a service would be a very good idea.