3

I am using the Windows Task Scheduler to start an elevated administrator program when a user logs on. The technique is based on this article:

http://www.sevenforums.com/tutorials/11949-elevated-program-shortcut-without-uac-prompt-create.html

Note: The elevated administrator program is an automated test program, which needs to run as administrator to install programs and run various tests. Some of the tests require administrator rights and access to the desktop.

The task is configured to run at above normal priority as described in this article:

https://stackoverflow.com/questions/2427142/is-there-any-way-for-a-win2k8-scheduled-task-to-have-normal-priority-io

Everything works fine on Windows Vista, Windows 7 and Windows Server 2008.

On Windows 8 and Windows Server 2012 the performance of test program is terrible, typically taking 5 – 10 times longer to run. CPU usage and Disk I/O are both very high. Process Hacker (http://processhacker.sourceforge.net/) shows I/O Priority as Normal, and Page Priority as Normal.

The poor performance only happens if the test program is run by the task scheduler during logon. If I stop the test program and re-start it by running the task scheduler task manually, normal performance is restored.

Here are some numbers from a cut down version of the test program:

  • From test program run from user login: Time 37.6 seconds, Page Faults 4530, Peak WS 17.8M
  • Same test program after manual restart: Time 1.1 seconds, Page Faults 4383, Peak WS 17.7M

Any help would be appreciated.

Community
  • 1
bradfordrg
  • 141
  • 5
  • Could it be that the task is competing with other login tasks and processes? Can you try the "Delay task for" on the trigger properties dialog? – charleswj81 Mar 22 '14 at 18:47
  • There is a delay built into the automated test program to allow for this. The testing phase does not begin until several minutes after the logon process has completed, which should give enough time for all of the logon stuff to complete. The same test program works fine on Vista, Windows 7, Windows Server 2008. – bradfordrg Mar 22 '14 at 18:59
  • Do you happen to have asynchronous logon processing set for the other machines but not the new systems with the issue? – MDMarra Mar 23 '14 at 04:21
  • Thank you for your interest in this issue. Group policy is applied syncrhonously on all systems. – bradfordrg Mar 23 '14 at 10:06
  • @bradfordrg, have you actually measured that the delay is long enough? For example, ProcMon traces to see that IO activity has settled down? – Daniel Goldberg Mar 29 '14 at 07:18

1 Answers1

1

I think I have a solution to the problem. It looks like the behaviour of a scheduled task on Windows 8 and Windows Server 2012 depends on when the task is started in relation to the logon sequence.

My test task had a delay built in. The task was started early in the logon sequence, paused for 60 seconds, then started the test run. Various delays were tried, but in all cases performance on Windows 8 and Windows 2012 was abysmal. Note: The test task was run in a nearly clean install of Windows, so 60 seconds was more than enough to get past the logon sequence.

I changed the Test Task to remove the built-in delay, and instead use the startup delay feature of the Task Scheduler. On Windows 8 and Windows Server 2012 the test task is configured to start 60 seconds after logon. After this change the test task behaves normally.

I've searched MSFT docs for an explanation for this behaviour, but so far drawn a blank.

I big thank you to @charleswj81, @MDMarra, and @Daniel Goldberg. Your comments helped me look at the problem from different angles and eventually figure out a work around.

bradfordrg
  • 141
  • 5