windows task scheduler API: sanity check when creating a task? - windows

I am using the Windows Task Scheduler API to create a timed triggered task. All works fine so far.
But during creation there's no sanity check to verify if the .exe would actually run. For example it would not start if the user-account has no "logon-as-batch" privilege, or the filepath is wrong. This can only be found out when actually starting the task (.exe)
Creating the same in windows own "control schedtasks" UI will immediately report an error if the privilege is missing without the need to run the .exe
Is there a way to do the same with the API?
I don't want to run the .exe for a test, because that would start a lengthly process.

Related

Application runs as scheduled task but nothing happens

I'm trying to set up a scheduled task to run an application (.exe). The application, if run manually (by double-clicking), would check a folder for new files, process them, and exit.
However, if the application is set up as an "action" in a scheduled task, when you run the scheduled task, all you see is the application starts up and appear as a process in Task Manager, but nothing else really happens. The files in the folder are not processed at all, and the process will be stuck in Task Manager, when it should shut itself down.
Any idea what's going on there? How do I get more details on what might have happened in the background?
The scheduled task is set up to run "whether user is logged on or not", with administrative privileges.
I'm running Windows 7 Professional SP1.
Update:
This is the stack output from Process Explorer:
ntoskrnl.exe!memset+0x61a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xbd0
ntoskrnl.exe!__misaligned_access+0x186d
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xde
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!EtwEventSetInformation+0x1da09
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
jvm.dll!_JVM_FindSignal#4+0x4e1df
jvm.dll!_JVM_FindSignal#4+0x8c1b1
jvm.dll!_JVM_FindSignal#4+0x8c5e6
jvm.dll!_JVM_MonitorWait#16+0xac
there is an option called Start in (optional) while you editing Action. For me that helped, because my app required to have some additional resources and only could access them, when started in correct directory.

Unable to open word document from jenkins

I have one windows utility which opens word document, extract data out of it and generate another word document using that data.
Now my problem is that this windows exe is working fine directly on command prompt, but if I call this exe through jenkins, i.e. build step "Execute windows batch command" it gives error, it is not able to open word document so utlity exists with error.
I have tried other options also like calling exe from pom file, and from batch file. every time it gives me same error. My tomcat service is running with the same user from which I am login to windows.
Any guidance on this topic will helpful.
You have to add "Desktop" folder in BOTH locations: C:\Windows\System32\config\systemprofile\Desktop
and
C:\Windows\SysWOW64\config\systemprofile\Desktop
Jenkins is not able to manage such application with a GUI as Tomcat is launched with a Windows service.
One option is to try to check this option on your Windows service: "Allow service to interact with desktop"
If it doesn't solve your problem, I'm not sure you will find a solution :(
Create an empty directory "Desktop" in
C:\Windows\SysWOW64\config\systemprofile\
this solved the issue.
I guess this is problem with user rights for the desktop folder under users directory. The user by which tomcat service is running.

Task Schedular Running Fails #Permission?

I have some really strange phenomena appearing on my PC, using Task Schedular.
We created a normal Task which is triggered every morning at 7 o'clock.
The interesting part is, that the history of Task Scheduler says, that it was running successfully.
But it didn't work.
I then created 2 other Scripts.
The first script is starting calc.
The second script creates a folder in c:/Temp
When starting those scripts over Explorer everything is running as expected.
But when running those scripts over task scheduler only the calc is starting and there won't be any folder in c:/Temp.
I already created a policy report, but nothing configured in the category Task Scheduler.
By the way the account configured in the Task Scheduler has local Admin right and run as batch job rights.
Thanks for your help.
Make sure to check any dependent files and permissions:
If permissions or ownership of a file changes that your task managed script depends on or uses (not necessary the one IN YOUR TASK), you need to make sure you re-sync your task to recognize those changes.
(for instance, if you've changed any permissions to C:\Temp but HAVEN'T resaved your Task...)
I've had the steps below fix issues when a script would run fine by itself, but after some change to it or a dependent file, would no longer run properly from Task Scheduler.
1) Open task schedular
2) find and double-click the troubled task like your going to edit it
3) Hit 'Ok'.
4) When prompted, enter credentials to save it. (If your credentials don't work then update them...that is a different problem)
5) try to re-run task from scheduler (r-click -> Run) then see if it works correctly.
NOTE: Just because the task successfully runs does NOT mean your script worked as it should. Check yourself to make sure the log file you want WAS created.

Windows job scheduled through TWS gives MDAC error

I have a job defined for a Windows FTA (TWS term). This job calls a bat script.
When thte script is run from the command prompt on the windows box, it runs ok, but when it is scheduled through TWS it comes up with the errors:
Application started at 6/3/2014 10:00:16 PM
There is error in the file Field_Details.csv.Please check with the below error
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.
There is error in converting Field in Excel(Field_Details.csv) to list in program. Please Check with below error message
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.
Application ended at 6/3/2014 10:00:16 PM
This error is stopping the script from continuing. I've seen some other posts about stopping and starting app pools on the windows box, but the box this is running on does not have an IIS Manager, so I don't know whaere to go from here.
ANy help is appriciated.
I work on TWS. I had a very similar error message (MDAC) coming up on one of our FTAs. There wasn't a fix per-se, but what was missing was that the file that TWS calls before the jobs starts, to check if there is a user-specific setup file to call was not checking for that file. We set it to check and ultimately call the setup-file and everything was good.
The file which does the check is in the TWS install dir, named jobmanrc.cmd. The scripting in that file checks to see if the (user-specific) setup file, djobmanrc.cmd exisits, if it does, it sources it to set up variables, etc.
I'd say check to see if your jobmanrc.cmd is checking for djobmanrc.cmd.

Dummy Task for the Task Scheduler

I am writing some integration tests for a C# wrapper round the Window Task Scheduler: Task Scheduler Managed Wrapper
Can someone suggest a suitable dummy application that I can call from the scheduled task. E.g. an app that will run silently. I can then check that it ran OK.
I did think of any empty batch file, but then I would have to ensure it was present on the server running the integration tests, before starting the test.
Well I tried
cmd.exe /c exit
which launches the command window and then closes it down. This seems to work OK. Open to any other suggestions though.

Resources