I have a batch script that prepares some files, executes a program (.exe) and then deletes said files.

This task should run hourly, so I'm trying to configure this using Scheduled Tasks. The problem is that the previously mentioned program does not run properly when invoked from the task (neither via the .bat script, nor when calling the .exe directly), but I don't get any warning or error messages in the logs.


The task is configured to run as a Windows Service Account that has all the privileges set properly. When using this account to logon via RDP, I can execute the .bat and .exe directly without problems, but still the task appears to do nothing. This is easily observed because the program always modifies a file, and the modified on timestamp does not change through the task.

In the scheduled task logs I get the information messages for the task starting a process, exiting, etc. The "result code", however, is 111 (tried to Google this without luck, the only association I get is "file name is too long", which is just completely irrelevant AFAIK). In the application logs, I get absolutely nothing.

What I suspect is the problem

The program is an old monstrosity that spawns some sort of splash screen (it's actually a normal window), even though the GUI is not needed because it requires no interaction and closes itself after operations. The window appears for about 2 seconds.

I suspect that this requirement for a GUI has something to do with the task failing, but I'm not sure. When I log in with the user that the task runs under (via RDP), no window appears when I start the scheduled task.

Edit about the GUI

I've built a very small C# executable that launches the program without the main window (using ProcessStartInfo.WindowStyle = ProcessWindowStyle.Hidden). Even this way, the scheduled task still does not succeed to launch the program correctly, but the return code is now 0.


When I configure the task to say "run whether the user is logged on or not", and the run with highest privileges option is unchecked, the error value is 2147943859.

What can I do to troubleshoot?

OS = Windows Server 2008 R2 SP1

If more info is needed, please let me know in the comments.

  • Do your script and "program" take any input, like options or parameters? Have you tried using PowerShell instead of batch? When starting a .exe "program" with parameters from within a script, the input has to be properly provided as argument.
    – slybloty
    Oct 6, 2014 at 19:05
  • 1
    Have you tried the scheduler with a different program? Just replace the one program with a different one, and see what results you get.
    – slybloty
    Oct 6, 2014 at 20:41
  • 2
    @out-null I don't think that the task scheduler uses the window to know when the program has finished running, it should wait for the process, whatever it does with windows. But if the program attempts to look for something specific to create its splash screen (let's say the task bar) and fails to find it (because it runs on a separate desktop/window station), it might be that then it stops...
    – Ale
    Oct 6, 2014 at 22:30
  • 1
    OK. Have you tried running it under the LocalSystem account? Also, have you tried monitoring the process launch event with Process Monitor from Sysinternals?
    – Lucky Luke
    Oct 7, 2014 at 21:15
  • 1
    @BradBouchard Even though your answer may not solve the OPs question in this specific case, it is a valid answer and could be useful for future visitors to SF, and I'd therefore encourage you not to delete it. Oct 11, 2014 at 12:33

8 Answers 8


I believe your problem has to do with either the permissions of the account being used to run the task, or the context of the account as exists when trying to run the task.

Test for Console Session Requirement

It's possible your .EXE must be run in Console session (aka Session 0) on the computer. To test for this:

  1. Configure the task to Run only when user is logged on and specify a task start time of 2 minutes in the future
  2. Log on to the machine with the same user account used to run the task (preferably log on to the console session, either by physically being at the console or using a remote access program that gives access to the console. To confirm you are using the console session, from a Command Prompt run QWINSTA, observe the SESSIONNAME column, and confirm the > indicator is next to console, in other words it should appear as >console)
  3. Wait for the task to run

If the task runs correctly, try scheduling the task with SCHTASKS.EXE using the /IT parameter. Failing that, you may have no choice but to configure the computer to automatically log on as your service user account and run the task as a startup program.

Check Permissions

Additionally, as I've already suggested, check the following to confirm the account used to run the task is properly permissioned:

  1. Grant the account the Logon as a batch job user right (Found in Local Group Policy at Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignments)
  2. Confirm the task is configured to Run with highest privileges
  3. Confirm the user has full NTFS permissions to all folders & files it must interact with. Make no assumptions; instead confirm by navigating to such file locations and using the Effective Permissions tab in the file/folder's Properties at Security > Advanced

Additional things to check/try

  • Does the task require access to access to network resources? Things like mapped drives may be present when you logon with the user account, but depending on the server's configuration may not be present in the context of the user account when executed from Task Scheduler.
  • Add some logging to your batch file. After every line it executes, have it write some output to a log file so you know where it's getting stuck. For example:

    @echo off
    echo Line 1 >> "C:\MyLog.txt"
    "C:\My Folder\myOldProgram.exe"
    echo Line 2 >> "C:\MyLog.txt"
    DEL somefile.dat
    echo Line 3 >> "C:\MyLog.txt"
  • Try running your .EXE with START, for example START "myTitle" "C:\full\path\to\my.EXE"


I'm responding to an old post in case it helps someone else. I had the same issue. The event log said the program completed normally, but not even the first line of code would write to the log for me. It ended up being the "Start In" option in the Task Scheduler. It occurred to me that the program ran fine from the command line when I was in the current directory. There are manifest files and other dependencies in the same directory. So if you tell the scheduled job to start in the same directory as the EXE, you may get favorable results. It was the solution for me.

  • This was the solution for running a custom console app developed in Visual Studio with supporting config files. Nov 23, 2015 at 22:21

maybe this helps you?


We had a similar problem and your only solution was that we made a special account on the server with autologin. So if the task ran under the already loged in user our .exe worked well...

i know this is not a very nice solution but for us it was the only thing that worked. i don't know if this works for you... (But with this work around you have to check if the user is really logged in all the time...)

  • The task doesn't even run correctly for me when the user it runs under is effectively logged on (via RDP). I use the service account to log on through RDP, start the task manually and I don't see a window appear.
    – MarioDS
    Oct 7, 2014 at 13:10
  • 2
    Have you UNchecked the "run with highest privileges" option? I think that when you have checked this option an evelation of rights will happen (UAC) and you will not see a window even when the user is logged in (will be called in a separate session without window and will fail). Also try to select the option "configured for" --> "Windows Server 2003, Windows XP or Windows 2000".
    – frupfrup
    Oct 7, 2014 at 13:24
  • That seems to make no difference, except when I now set "run whether the user is logged on or not" I get error code 2147943859. I can only set "Configured for" to either Windows Vista/Windows Server 2008 or Windows 7/Windows Server 2008 R2. It seems to make no difference.
    – MarioDS
    Oct 8, 2014 at 11:48
  • ok. one last test: Create a new task with "create new task" instead of "create easy task" (i don't know which text is really shown - my servers are german - but i hope you know what i mean.) and then i think you can select "windows Server 2003, ...". and then pls try once again with the other options...
    – frupfrup
    Oct 8, 2014 at 12:12

The guys of the company that runs the servers of our customers said that a GUI program would not run via scheduled tasks in any way whatsoever.

They use a monitoring system that also has task scheduling features. They've set it up through that and it appears to work.

Sorry that I didn't get the chance to evaluate more suggestions here, but thanks for trying to help anyway. I hope that it may help others in the future, which I think it certainly will.

  • Solution worked for me is to change the "Start in (Optional)" to the same Directory as the EXE. Feb 17, 2021 at 23:48

I was attempting to start and old VB6 program using the task scheduler on a Windows 2008 R2 server. The application would run from the exe, via batch file or clicking on a shortcut, but would not run from the task scheduler. I found that when the configuration files for the application, which were stored in the applications folder in C:\program files (x86) directory were copied to application folder on c:\programdata. the scheduler worked. it appears that cmd.exe applies the configuration from a different location to that used by the task scheduler. If your application has configuration files, you could try moving them to the c:\programdata\application folder.


Are you referencing any mapped network drives in your script or program? I had a similar issue a while back where my scheduled task would not run, and I couldn't figure out why. Changing the path(s) to UNC paths solved it for me.

Change T:\Apps\MyProgram.exe to \\MyServer\MyShare\Apps\MyProgram.exe

  • Nope, the program is on the local C: drive.
    – MarioDS
    Oct 10, 2014 at 8:17

When I configure the task to say "run whether the user is logged on or not", and the run with highest privileges option is unchecked, the error value is 2147943859.

2147943859 converted to Hex is 800705b3 which a quick trip to Google tells me means "Could not start installation program on the computer. this operation requires an interactive window station."

Now, there may be some way to cause it to run interactively without using PSEXEC (from Sysinternals) but since I already know how to do it via PSEXEC that's what I'd use.

PSExec: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Therefore, change your action to prepend everything with psexec.exe -i (and -h if you need it elevated) and it ought to work.

I've tried this on Windows Server 2008 R2 SP1 with the following in my 'action':


and then the parameters:

/c psexec.exe -h -i notepad.exe

When I manually run the task (since I don't have it schedule) I get an elevated notepad running in my current session.


Maybe the answer to this question will help someone else reading this thread?


Summary: Windows 2012 Scheduled Tasks do not see the correct environment variables, including PATH, for the account which the task is set to run as.

I read through all this quite a long time before I worked out the above. (Which was my own problem leading to the same as the OP's question.)

Once you (finally!) know this, it is quite easy to test for it (as per the stackoverflow answer), see it happening, and work around it....

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .