It's well known that when starting tasks via TaskScheduler in recent versions of Windows, that if the task is "run whether user is logged on or not", then the task will not run interactively - i.e. it will not start a UI.
For reference, this is according to Microsoft, and has been highlighted in this SuperUser question and this StackOverflow question:
You can specify that a task should run even if the account under which the task is scheduled to run is not logged on when the task is triggered. To do this, select the radio button labeled Run whether user is logged on or not . If this radio button is selected, tasks will not run interactively. To make a task run interactively, select the Run only when user is logged on radio button.
However, my problem is derivative of this.
The task started by TaskScheduler is a Java client application which can be instructed to run processes - these are run via ProcessBuilder in the client application. As such, it is okay that this client application is hidden / does not start a UI - indeed, there is no UI.
However, if the client application is started via TaskScheduler to 'run whether user is logged on or not' as above, then any processes that are started by ProcessBuilder in the client application are also unable to run interactively / unable to show a UI. This is a problem, as some of the processes started by the client are UI applications.
I'm not sure why this would be the case, but really I'm trying to work out if there is a work around - e.g. some environment variables or properties that could be added to get a visible process started by the (invisible) client.
Any thoughts?
So, the workaround that I found was to stop using TaskScheduler, but to create a script to start my application and added a shortcut to that script in the Start Menu > Programs > Startup folder.
Credit to this article on HowToGeek:
On Windows 7 and earlier versions of Windows, the Start menu contained a “Startup” folder to make this easy.
This folder is no longer as easily accessible on Windows 8, 8.1, and 10, but it’s still accessible. To access it, press Windows Key + R, type “shell:startup” into the Run dialog, and press Enter.
Shortcuts you add to the “shell:startup” folder will only launch when you log in with your user account. If you’d like a shortcut to launch itself whenever any user logs in, type “shell:common startup” into the Run dialog instead.
Since I want my application to start on system startup, rather than user login, I used the “shell:common startup” link.
Applications started in this way - or in my case, applications started by applications started in this way - are visible and/or interactive via their UIs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With