scheduler tasks with security options “Run whether user is logged on or not”.

Question

scheduler tasks with security options “Run whether user is logged on or not”.

YOFFE Mike 40

We use the package <package id="TaskScheduler" version="2.12.2" targetFramework="net48" />

This is the code with three actions and its behavior:

|| | -------- | Task

|| | -------- | GUI

|| | -------- | Manually run from the scheduler

|| | -------- | Automatically run from the scheduler according to the trigger

Task

|| || GUI

|| || Manually run from the scheduler

|| || Automatically run from the scheduler according to the trigger

|| || Cmd echo

|| || No

|| || Run as expected

|| || Notepad

|| || Yes

|| || Run in the background and does not work and not ended

|| || Run as in the trigger time in the background and does not work and not ended

|| || Our utility

|| || No

The same applications work fine if we use the option “Run only when user is logged on”

= = = = = = = = = = = = = =

using (TaskService ts = new TaskService())

{

TaskDefinition td = ts.NewTask();

td.RegistrationInfo.Description = "Run task as SYSTEM user";

// ✅ Run whether user is logged on or not

td.Principal.UserId = "SYSTEM";

td.Principal.LogonType = TaskLogonType.ServiceAccount;

td.Principal.RunLevel = TaskRunLevel.Highest;

// Trigger: run once, 1 minute from now

td.Triggers.Add(new TimeTrigger

{

StartBoundary = DateTime.Now.AddMinutes(1)

});

// Action

1. td.Actions.Add(new ExecAction(@"C:\Windows\System32\cmd.exe /c ",

"echo SYSTEM task ran >> C:\temp\system_task.log", null));

2. td.Actions.Add("C:\Windows\notepad.exe");

3. td.Actions.Add(new ExecAction(@"OurCustom.exe",”Our arguments”));

// Register task

ts.RootFolder.RegisterTaskDefinition( "Test", td, TaskCreation.CreateOrUpdate, null, null,

TaskLogonType.ServiceAccount);

//Console.WriteLine("Task created and runs as SYSTEM.");

}

Answer accepted by question author

6 additional answers

Your answer

Answer 1

@YOFFE Mike I broke out a very old virtual machine that had VB6 installed. I copied the VB6 console code from Creating a real console application in Visual Basic as well as the code to change the SUBSYSTEM.

I removed all the code from the console application project and replaced it with the code to instantiate and use the scripting FileSystem object.

Built the project and changed the resultant executable SUBSYSTEM . Then I copied the VB6 console application to a Win10 22H2 system and ran it as a scheduled task under SYSTEM account as described for the previous proof of concept.

The VB6 console application completed successfully;y and created the test file in the C:\Users\Public\intergraph folder.

I could not replicate your issue.

Answer 2

The behavior is by design for tasks configured to “Run whether user is logged on or not” under the SYSTEM (service) account.

Key points:

Desktop interaction is not available
- When a task runs as SYSTEM with TaskLogonType.ServiceAccount and “Run whether user is logged on or not”, it runs in a non-interactive session.
- GUI applications such as Notepad (or any app that expects a user desktop) cannot display a window or interact with the logged-on user. They appear to “run in the background” and typically hang or never complete properly.
- This is why:
  - cmd /c echo ... works: it is a non-interactive console command that does not require a desktop.
  - notepad.exe and the custom utility (if it expects UI or interactive desktop resources) do not work and appear stuck.
Why it works when “Run only when user is logged on”
- In this mode, the task runs in the interactive user session with access to the user’s desktop.
- GUI apps (Notepad, custom UI tools) can create windows and behave as expected.
Recommended patterns
- For background/system tasks:
  - Use console or service-style executables that do not depend on UI or desktop interaction.
  - Keep actions like cmd.exe /c ... or non-UI utilities.
- For tasks that must show UI:
  - Configure the task to “Run only when user is logged on” and run under that user’s account, not SYSTEM.
- Avoid running GUI apps under SYSTEM with TaskLogonType.ServiceAccount because they cannot reliably interact with any user session.
Task Scheduler model
- Task Scheduler tasks are defined by triggers and actions. Actions that execute command-line operations (like ExecAction with cmd.exe) are supported for non-interactive scenarios.
- GUI actions are not suitable for non-interactive service accounts.

To fix the current code:

Keep the cmd.exe action as-is for background logging.
Remove or replace the Notepad and any UI-dependent actions when using SYSTEM + “Run whether user is logged on or not”.
If Notepad or the custom utility must be visible, create a separate task configured as “Run only when user is logged on” under a real user account.

References:

YOFFE Mike 40 Reputation points

2026-02-26T15:02:23.51+00:00

It is not solved my problem

As I wrote, our application is not GUI. It make the following operations

Read INI file

Read the database

Update the database

NO any GUI operations but it does not work in the mode “Run whether user is logged on or not”. Why?
JuliaMarvin 18,540 Reputation points Volunteer Moderator

2026-02-26T22:23:14.8033333+00:00

@YOFFE Mike
Seems that you answer-marked the AI-generated post in error.
You should unmark it by clicking on the Unaccept answer button.

Answer 3

Hi @YOFFE Mike ,

Thanks for reaching out.

Even though your application doesn’t have a GUI, Windows runs these tasks in a non-interactive session when no user is logged in. That session does not have access to your user desktop, profile folders, or mapped network drives, which can cause programs to hang if they rely on any user-specific resources.

I would recommend a few approaches:

Use absolute paths in your app - avoid user-relative paths like C:\Users\YourName\.... For configs or logs, use C:\ProgramData\YourApp\.
Check permissions - make sure the SYSTEM account can read/write all folders and files your app needs.
Avoid GUI-dependent code - even hidden windows or message boxes can make tasks hang.
Test as SYSTEM - you can use Sysinternals’ psexec to run a command prompt as SYSTEM and verify your app works:
```
   psexec -i -s cmd.exe
```
Consider a Windows Service - for non-interactive background tasks, services are often more reliable than Task Scheduler.

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

Answer 4

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 5

YOFFE Mike 40

TI am not satisfied with this answer.

As I wrote, our application is not GUI. It make the following operations

Read INI file
Read the database
Update the database

NO any GUI operations but it does not work in the mode “Run whether user is logged on or not”.

RLWA32 52,256 Reputation points

2026-02-26T14:52:19.22+00:00

Please provide details that describe the nature of the errors (error text and error codes) encountered to clarify what you mean by "does not work".
YOFFE Mike 40 Reputation points

2026-02-26T15:04:59.5766667+00:00

using (TaskService ts = new TaskService())

{

     TaskDefinition td = ts.NewTask();

     td.RegistrationInfo.Description = "Run task as SYSTEM user";

     // ✅ Run whether user is logged on or not

     td.Principal.UserId = "SYSTEM";

     td.Principal.LogonType = TaskLogonType.ServiceAccount;

     td.Principal.RunLevel = TaskRunLevel.Highest;

     // Trigger: run once, 1 minute from now

     td.Triggers.Add(new TimeTrigger

     {

         StartBoundary = DateTime.Now.AddMinutes(1)

     });

     // Action

     td.Actions.Add(new ExecAction(@"OurCustom.exe",”Our arguments”));

     // Register task

     ts.RootFolder.RegisterTaskDefinition( "Test", td, TaskCreation.CreateOrUpdate, null, null,

TaskLogonType.ServiceAccount);

No GUI. Run in the background and does not work and not ended
RLWA32 52,256 Reputation points

2026-02-26T15:24:04.21+00:00

Information ordinarily obtained from or related to a logged on, interactive user may not be available to a task running as SYSTEM in a non-interactive session.

Does your scheduled task requires such information?

And if your issue is not resolved maybe you should not have accepted the answer from Q&A Assist.
MotoX80 37,346 Reputation points

2026-02-26T16:08:09.5033333+00:00
td.Actions.Add(new ExecAction(@"OurCustom.exe",”Our arguments”));

We forum users would have no idea what "OurCustom.exe" is doing.

One common issue with tasks is that they sometimes reference mapped network drives that exist only in the logged on users desktop session.

The other common problem is that users try to run programs that display message boxes like "Click ok to continue". If you select "run whether the user is logged on or not", then there is no way for anyone to see that msgbox and click on the button. In that case the program/task just hangs.

If someone in your organization wrote that program, then they need to add code to it to implement logging and error handling. That is, when the program starts executing, it should write an entry to a log file indicating the start date and time. And before the program terminates, it should write an entry indicating that it's processing is complete.

It should have Try-Catch code blocks to process unhanded errors. And log those events too.

If the program already produces "console.write ()" output, you can capture stdout/stderr like this.

https://learn.microsoft.com/en-us/answers/questions/2141466/how-to-run-a-task-with-task-scheduler
RLWA32 52,256 Reputation points

2026-02-26T21:14:29.76+00:00

@MotoX80,

We forum users would have no idea what "OurCustom.exe" is doing.

Maybe if we combined our psychic powers... :)
MotoX80 37,346 Reputation points

2026-02-26T23:55:37.16+00:00

@RLWA32 Mr. Spock has tried to teach me the Vulcan Mind Meld where I could just connect to users computers and ask them what they are doing wrong. Sadly, I am not a very good student so the best I can do is to offer some solutions to common problems.
RLWA32 52,256 Reputation points

2026-02-27T12:16:35.26+00:00

@YOFFE Mike Another option is to include code that executes soon after the application starts (for example, the System.Diagnostics.Debugger.Break method) so that Visual Studio's just-in-time debugging facility can attach the debugger to your process. This will allow you to step through the code to determine the point of failure and related reasons after task scheduler has started the process in a non-interactive session.
YOFFE Mike 40 Reputation points

2026-03-05T10:02:10.81+00:00
I wrote the minimum code

Sub Main()

Dim fso As New Scripting.FileSystemObject Dim yourStream As Scripting.TextStream fso.CreateTextFile ("aaa.log") Set yourStream = fso.OpenTextFile("c:\users\public\intergraph\aaa.log") yourStream.WriteLine ("Enter") yourStream.Close

End Sub

I run it manually from the scheduler. It runs forever, I see it in the Task Manager, but no write is executed. If I put the mode "Run only if the user is logged on" it works
RLWA32 52,256 Reputation points

2026-03-05T10:12:35.94+00:00

@YOFFE Mike Unfortunately, posting the same code snippet (including inconsequential changes) multiple times does not provide any additional information. to enable us to assist you.

Have you seen my earlier comment about the proof of concept test that I performed?

Share via

scheduler tasks with security options “Run whether user is logged on or not”.

6 additional answers

Your answer