Strange result when runnig batch script from Windows 10 schedule

[Sfor]

I encountered strange result when runnig batch script from Windows 10 schedule.

The script uses WGET.EXE to connect to check if a HTTP service is running on the same computer (127.0.0.1). If thre is a problem an Email is sent and the service gets restarted. The WGET output is redirected to a file, so all operations are visible there.

When running from command line or explorer there is just one connection in the HTTP service log, as it should be. But if the same script was executed from Windows 10 schedule, there are multiple connections visible in the log, from the same source at the same time. All connections are done in 1 to 2 s time frame.

I did test the idea with using a reverse proxy server co connect to the same service. The proxy log shows the same multiple connections effect. So, it is not a problem of the HTTP service. There are multiple connections from the same address, because the proxy logged them, as well.

The output file from WGET shows just one connection. The command line has a -t1 switch to limit the attempted connections to just one. The -o switch redirects output to a text file, and there is just one connection attempt in the output file.

I'm stuck. I do not know how to crack this behavior. I wish to know what is going on here.

[Tripredacus]

First the main difference is that you are actually executing the script in two different ways. Your manual methods are being run as an interactive user, likely in Session 1. Scheduler is likely running the script via a security context and also could be running in Session 0. 

If the presumption is that scheduler is running the script under a security context, I am not able to find out definitively why this type of behaviour may occur other than the obvious reason that a security context has different privileges than an interactive user. Wget may operate differently. There is a debug option you can try adding to your script like so:

wget -t1 --debug http://localhost

Also you can see about setting the scheduler to run it as a specific user. You can also try using a different tool to see if it behaves differently such as curl:

curl --max-time 10 --retry 0 http://localhost