13

Situation

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.

Setup

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.

Update

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.

MarioDS
  • 223
  • 2
  • 4
  • 15
  • 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 06 '14 at 19:05
  • @slybloty well, as stated in the question, even when the task has just the program as an "action" it fails to run. Double clicking the `.exe` works, firing it up through `name.exe` in cmd works just as well. It isn't a shortcut so there are no "default" switches or parameters. – MarioDS Oct 06 '14 at 20:38
  • 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 06 '14 at 20:41
  • @slybloty that is an interesting suggestion. I'll try this when I get a chance! – MarioDS Oct 06 '14 at 20:46
  • The log lists event IDs which are not the same as return codes. See: http://technet.microsoft.com/en-us/library/cc774991(v=ws.10).aspx – Brian Oct 06 '14 at 21:59
  • I've recently encountered a very similar problem with a program that I could also describe as an "old monstrosity that displayed a splash screen". I highly suspected that the key issues lie with either: Task scheduler considering the "splash screen" as the program (therefore, when the splash screen closes, task engine considers the program "done" and closes all windows) **or** the program itself is somehow unable to properly display when run as a user other than the current user. Nonetheless, I had to solve this with a less than optimal workaround, but I'm curious to see how you resolve this. – Get-HomeByFiveOClock Oct 06 '14 at 22:28
  • 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 06 '14 at 22:30
  • @Ale Either that or some sort of escape/end code. But once again, I'm not familiar enough with how task scheduler works to say for sure. – Get-HomeByFiveOClock Oct 06 '14 at 22:34
  • You can perhaps use an API monitor like http://jacquelin.potier.free.fr/winapioverride32/ or http://www.rohitab.com/apimonitor to find out if something special is failing when the program is launched by the task scheduler (e.g., by comparing the trace with one obtained while running the program "normally") – Ale Oct 06 '14 at 22:35
  • Are you _sure_ the Windows service account you're using has the proper permissions? Does the account have the **Logon as a batch job** user right? Is the task configured to **Run with highest privileges** (I'm sure it is)? I've encountered many similar issues with the Task Scheduler and the majority have been traced back to permissions. – I say Reinstate Monica Oct 06 '14 at 23:52
  • @Ale I might try that later. – MarioDS Oct 07 '14 at 07:47
  • @Twisty it _should_ be right yes, but I'll double check with the guys who manage that. Run with highest privileges is definitely checked. Other permissions like ntfs are unlikely to be wrong since manual execution works fine.. – MarioDS Oct 07 '14 at 07:49
  • @out-null what did you actually do to solve your problem? – MarioDS Oct 07 '14 at 07:55
  • Since this application was not running on a server (It was basically an application that ran as a console) I set up the OS as a console. Automatically log into the service account and run the program as a shell. Once again, not great, but it works for how we are using the application. It seems like -for you- it being on a server may make that particular solution difficult. – Get-HomeByFiveOClock Oct 07 '14 at 13:48
  • Not sure if I missed this, but under which user account are you launching the task? Are you launching it under the SYSTEM account, or an actual user? Is it a local user or a domain user? Does the app interact with the network? – Lucky Luke Oct 07 '14 at 18:58
  • @LuckyLuke I'm launching it as a domain user (I believe a Windows Service Account). The program does interact with the network. – MarioDS Oct 07 '14 at 19:12
  • 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 07 '14 at 21:15
  • The error code 2147943859 means "This operation requires an interactive window station.". Looking around on the web, it seems generally related to the *absence* of the check in the "Run with highest privileges" checkbox... For the account you use: are you storing the password or not? If not, it might be a problem if the program needs access to a network resource. How do you check if your C# program with hidden GUI runs or not, is it writing something to a file? – Ale Oct 08 '14 at 12:19
  • You say a Windows Service Account, but I think you're referring to a Managed Service Account correct? – Brad Bouchard Oct 08 '14 at 16:57
  • In what way does the program interact with the network? – I say Reinstate Monica Oct 09 '14 at 00:58
  • Thanks for your reply concerning the MSA account; based off the fact that you're 99% certain you're not using an MSA, I'm going to delete my answer as it is not relevant and I don't want it clogging up other potential answers. Good luck. – Brad Bouchard Oct 10 '14 at 21:21
  • 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. – I say Reinstate Monica Oct 11 '14 at 12:33

8 Answers8

7

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 say Reinstate Monica
  • 3,100
  • 7
  • 23
  • 51
2

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.

Rob Wilson
  • 129
  • 2
  • This was the solution for running a custom console app developed in Visual Studio with supporting config files. – billfredtom Nov 23 '15 at 22:21
1

maybe this helps you?

https://stackoverflow.com/questions/6939548/a-workaround-for-the-fact-that-a-scheduled-task-in-windows-requires-a-user-to-be

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...)

Community
  • 1
frupfrup
  • 853
  • 3
  • 13
  • 27
  • 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 07 '14 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 07 '14 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 08 '14 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 08 '14 at 12:12
1

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.

MarioDS
  • 223
  • 2
  • 4
  • 15
1

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.

Kasa
  • 11
  • 1
0

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

AdamsTips
  • 171
  • 1
  • 9
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.

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': 

c:\windows\system32\cmd.exe

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.

Mark Allen
  • 474
  • 3
  • 8
0

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

https://stackoverflow.com/questions/32589381/

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....

Community
  • 1
MikeBeaton
  • 151
  • 4