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

YOFFE Mike 40

Yes, I can make changes. It is not enough to write as in my code to "c:\users\public\intergraph\test.txt"?

Answer 4

YOFFE Mike 40

Sub Main()

Dim fso As New Scripting.FileSystemObject

Dim ts As Scripting.TextStream

fso.CreateTextFile ("c:\users\public\intergraph\test.txt")

Set ts = fso.OpenTextFile("c:\users\public\intergraph\test.txt", ForWriting)

ts.WriteLine ("Test text")

ts.Close

Exit Sub

End Sub

I build the standard EXE

I created two scheduled tasks that execute this code.
The SINGLE difference is:

Run only if user is logged on
Run whether user is logged on or not

In the first case it runs, in the second it is stalled and does not do anything. We have customers that say that our scheduled application worked for years and now stopped to work.

MotoX80 37,346 Reputation points

2026-03-04T14:02:07.4966667+00:00
Sadly, we forum users do not possess super-human powers that would allow us to somehow just "know" what your computer is doing. That was the joke that @RLWA32 and I were sharing.

You are focused entirely on those 2 bullets and ignoring the obvious point that you have to implement debugging functionality within the entire process to find the root cause of your problem. Or to at least determine "where do we look next".

So, it appears that you have 3 key items in this process.

A C# program.

A scheduled task.

OurCustom.exe

Start with OurCustom.exe. If "ts.WriteLine ("Test text") " is now working, that's great. Add more ts.WriteLine calls to the program. Put one at program start, another one when it ends. Add other writelines at key points in the processing. Include a timestamp.

Your goal is to modify OurCustom.exe so that it produces a log file that looks something like this.

3/4/2026 8:20:00 AM - OurCustom.exe starting. 3/4/2026 8:20:01 AM - Read INI file 3/4/2026 8:20:02 AM - INI processing complete. 3/4/2026 8:20:03 AM - Read the database 3/4/2026 8:20:04 AM - Database read complete. 3/4/2026 8:20:05 AM - Update the database 3/4/2026 8:20:06 AM - Database update complete. 3/4/2026 8:20:07 AM - OurCustom.exe ending.

I highly recommend adding Try/Catch calls within the code so that unhandled errors are trapped. If you encounter an error, then write the exception information out to the log file. If you don't know how to program that, do an internet search. There are plenty of examples.

Once you get that code working in Visual Studio, copy the .exe to a test machine. Check the Task Manager and make sure that there are no other instances of OurCustom.exe running. Kill them if you find any.

Then run OurCustom.exe from a command prompt. Verify that it works correctly and generates the log file.

Create a .bat file that executes OurCustom.exe. Maybe call it c:\users\public\intergraph\SchedTask.bat.

@echo %date% %time% SchedTask starting c:\users\public\intergraph\OurCustom.exe @echo %date% %time% OurCustom RC = %errorlevel% @echo %date% %time% SchedTask Ending

Next, launch Computer Management and manually create a scheduled task that executes the .bat file. Capture stdout (1) and stderr (2). Like this.

Run the task and see what happens. What do you see in both log files?
YOFFE Mike 40 Reputation points

2026-03-04T14:15:41.3533333+00:00
Sub Main()

Dim fso As New Scripting.FileSystemObject Dim ts As Scripting.TextStream fso.CreateTextFile ("c:\users\public\intergraph\test.txt") Set ts = fso.OpenTextFile("c:\users\public\intergraph\test.txt", ForWriting) ts.WriteLine ("Test text") ts.Close Exit Sub

End Sub

I build the standard EXE

I created two scheduled tasks that execute this code. The SINGLE difference is:

Run only if user is logged on

Run whether user is logged on or not

In the first case it runs, in the second it is stalled and does not do anything. We have customers that say that our scheduled application worked for years and now stopped to work.
MotoX80 37,346 Reputation points

2026-03-04T14:27:59.72+00:00

Please see my comment dated Mar 4, 2026, 9:02 AM.
MotoX80 37,346 Reputation points

2026-03-04T14:34:54.5233333+00:00

When you manually create the scheduled task, be sure to set it to "Run whether user is logged on or not" so that it recreates the settings that the C# program would use. Ie: recreate the problem.
YOFFE Mike 40 Reputation points

2026-03-04T15:51:17.72+00:00

I do not see your comment dated Mar 4, 2026, 9:02 AM
MotoX80 37,346 Reputation points

2026-03-04T15:55:21.85+00:00

Timestamp might be in your local time.

Its this one.
YOFFE Mike 40 Reputation points

2026-03-04T16:05:54.28+00:00

Dear MotoX80. Thank you for your detailed study of my example. But 1. It is not C# but a VB6 program, do not need super-human force to understand this 2. Instead of OurCustom..exe I wrote code with 7 rows (see my comment Mar 4, 2026, 4:15 PM) and manually added this task to the scheduler. The behavior is described in the same comment. 3. It happens on all our computers, and we receive complaints from our customers. We really do not know what to do
MotoX80 37,346 Reputation points

2026-03-04T16:25:29.7533333+00:00

but a VB6 program, We really do not know what to do

I would start by migrating the VB6 code to a current VB.Net version. VB6 is 32 bit, it is ancient and the compiler has been out of support for decades.

Do you have the old VB6 compiler? Are you able to make changes to that code? That is the code where you need to add the statements that write to a log file.

If you are telling me that the code that you posted was written in VB.Net, and it also hangs when run through the task scheduler, then follow the instruction that I posted. Add more writeline calls. Use SchedTask.bat and capture stdout/stderr.
YOFFE Mike 40 Reputation points

2026-03-05T08:09:00.58+00:00

Yes, I can make changes. Is it not enough that I write to "c:\users\public\intergraph\test.txt"? The point here is that the application started; I see it in Task Manager, but it does nothing. But with the option "Run only if user is logged on" it runs
RLWA32 52,256 Reputation points

2026-03-05T09:22:53.7933333+00:00

@YOFFE Mike As distributed by Microsoft VB6 does not natively provide support for the creation of console applications. There are various methods available on the net to compensate for this limitation but as I see it they all involve third party code and tweaks to the resultant "Standard exe" to change the PE executable from IMAGE_SUBSYSTEM_WINDOWS_GUI toIMAGE_SUBSYSTEM_WINDOWS_CUI.

Given the lack of available information there is no way for us to diagnose the issue or even make an informed guess as to why a 32-bit executable created in this manner might function as you describe.

I replicated your use of the scripting filesystem object and related interfaces in a small console application written in C++. This executable wrote to the same file system locations as your posted code. For my test it was necessary to manually create the "intergraph" subfolder under c:\users\public. The test program also logged to a folder under C:\Users\Public.

The test program was run from a scheduled task under the SYSTEM account with "Run whether user is logged on or not" -

So there's nothing inherently problematic about what you want to achieve as demonstrated by the proof of concept test that I performed.

You need to find a way to debug your VB6 code. We cannot do that for you. Have you tried the Task Manager's "Analyze Wait Chain" option available from its Details view?
YOFFE Mike 40 Reputation points

2026-03-05T10:09:46.23+00:00
What to debug? I wrote the minimum code, wrote one row to the file, nothing to debug. The problem is not in the code but something in the scheduled mechanism, maybe together with Windows attributes/properties.

The problem began with customer complaints (not ALL, just some). The problem with the option "Run whether user is logged on or not"

Sub Main()

Dim fso As New Scripting.FileSystemObject Dim ts As Scripting.TextStream fso.CreateTextFile ("c:\users\public\intergraph\test.txt") Set ts = fso.OpenTextFile("c:\users\public\intergraph\test.txt", ForWriting) ts.WriteLine ("Test text") ts.Close Exit Sub

End Sub
RLWA32 52,256 Reputation points

2026-03-05T10:22:43.1733333+00:00

Did you try the Task Manager's "Analyze wait chain"?
MotoX80 37,346 Reputation points

2026-03-05T14:43:35.12+00:00

I created a test task on my Win11 laptop. On the initial definition, it won't let me create a task that runs as the SYSTEM account AND has "Run whether user is logged on or not". That option is greyed out, I am forced to use "Run only when user is logged on".

But after the task has been defined, I see that the account changes from "NT AUTHORITY SYSTEM" to "SYSTEM". And I am forced to use "Run whether use is logged on or not".

If you were able to define a task that runs as the SYSTEM account, and is set to "Run only when user is logged on", then I don't understand why the C# API calls allow that when the mmc interface does not.

Mike, I think it would be a good idea if you could provide us some background information about what you are trying to do.

Why are you using a scheduled task? Why can't the C# "control" program just call the OurCustomVB6.exe directly?

Why does the task need to run as the SYSTEM account? Have you tried using a different local user account that has been granted the necessary permissions to access the file system?

If you can define the task and set it to run as the SYSTEM account, AND has "Run only when user logged on" set, AND the VB6 program successfully executes, then why can't you use that?
RLWA32 52,256 Reputation points

2026-03-06T08:59:30.49+00:00

@MotoX80 I assumed that the Questioner's task configured to "Run only when user is logged on" was using a user account, not the SYSTEM account.

On Win10 22H2 I did a quick test to programmatically create a task using the SYSTEM account and a LogonType of InteractiveToken. The task was created but was configured to "Run whether user is logged on or not".

I exported that task to XML and deleted the task, After editing the XML to add the LogonType of InteractiveToken I imported it back into task scheduler. The task scheduler UI opened and displayed the principal using "Run whether user is logged on or not".

So I could not configure a task running as SYSTEM for "Run only when user is logged on"
MotoX80 37,346 Reputation points

2026-03-06T13:17:07.4166667+00:00

The code he posted had this.

And it took us a while to learn that he was trying to run a VB6 program.

I suspect that there are more key details that we don't know about.

@YOFFE Mike can you provide more details about the overall process? That is, why do to need to use a scheduled task to run the program? Why are you using the SYSTEM account? Have you tried using a normal local user account to run the task?

From my experience I have found that the solution to a user's problem often has nothing to do with the question that they ask. You have the attention of 2 very experienced users. But I would have to say that at this point in time, we're a bit confused about what you are trying to do.
RLWA32 52,256 Reputation points

2026-03-06T13:23:48.47+00:00

@MotoX80 The posted code creates a scheduled task for SYSTEM configured as "Run whether user is logged on or not". We have no idea what he has done with respect to creating a scheduled task that is configured as "Run only when user is logged on". I doubt that any such task is running as SYSTEM.
YOFFE Mike 40 Reputation points

2026-03-08T07:31:50.5533333+00:00

RLWA32 - you are right. I found the root of the problem. It was invalid TaskLogonType. I used TaskLogonType.ServiceAccount with user SYSTEM. After I changed this to TaskLogonType.Password it began to work. Thank you very much for all for your help.
RLWA32 52,256 Reputation points

2026-03-08T08:51:24.1933333+00:00

It was invalid TaskLogonType. I used TaskLogonType.ServiceAccount with user SYSTEM. After I changed this to TaskLogonType.Password it began to work.

@YOFFE Mike The SYSTEM account does not have a password. Even though the code to create a scheduled task to run under the SYSTEM account that specifies a TaskLogonType.Password instead of TaskLogonType.ServiceAccount will succeed the resultant task will be created to "Run whether user is logged on or not".

We still don't understand how you could create a task configured to "Run only when user is logged on" under the SYSTEM account, or how the change you describe could resolve your stated issue.

Did your resolution also include creating the task to run under an account other than SYSTEM?

Answer 5

YOFFE Mike 40

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

MotoX80 37,346 Reputation points

2026-03-01T16:13:02.8166667+00:00

Why are you using the old scripting host objects? If you are writing the program in VB.Net, then use the native I/O calls.

https://www.bing.com/search?q=VB.NET+StreamWriter+examples

In the code that you posted, the CreateTextFile just uses an unqualified file name. The file would be created in whatever the current working directory is.

You fully qualify the path to the file in the OpenTextFile call, but you didn't specify ForReading or ForWriting or For Appending. I don't see how that could possibly work.

Did you test that program by itself? That is; open a command prompt and just run OurCustom.exe by itself. Does it produce any messages? Does it create the log file with messages in it?

What folder did you put that program in? Is that folder in the system path or do you need to specify the path to it? (C:\Apps\WhateverFolderYouPutItIn\OurCustom.exe)

MotoX80 37,346

CoPilot can help you.

"build me a sample vb.net console based program that demonstrates how to write to a log file"

Imports System.IO
Module Program
    ' Path to the log file
    Private ReadOnly LogFilePath As String = "c:\users\public\intergraph\aaa.log"

    Sub Main()
        Log("Application started.")
        Console.WriteLine("Doing some work...")
        Log("Work step completed.")
        Console.WriteLine("Application finished. Check aaa.log for entries.")
        Log("Application ended.")
    End Sub
    ' Simple logging helper

    Private Sub Log(message As String)
        Dim timestamp As String = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss")
        Dim line As String = $"{timestamp}  {message}"
        ' Append the line to the log file
        File.AppendAllText(LogFilePath, line & Environment.NewLine)
    End Sub
End Module

Share via

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

6 additional answers

Your answer