1

We are running a Batch script call "C:\My Scripts\Script.vbs" which when run manually, executes the vbscript perfectly. However when setting up a scheduled task, it works some times, but most times it never completes and we have set the task to forcibly stop after 4 hours - which does not seem to work either. The task is set to run with administrator privileges and we can see in the task history that the task is running when it is set to run but it does not seem to ever execute the script properly. Any recommendations and help you can provide are much appreciated.

Update: It will run when set to run when user is logged on but will not run when set to run where user is logged on or not

JamesBong
  • 69
  • 8
  • What's in the `vbscript`? Is the `vbscript` actually starting? Are you using `cscript` or `wscript` to execute the script? What's different "some times" when it works? You really need to provide a bit more information if we're to be able to help you out – Dave Oct 02 '17 at 16:14
  • the vbscript is actually starting and running properly if I execute the batch script manually, it's a vbscript to send out automated email reminders, it just doesn't seem to work when run from the task scheduler – JamesBong Oct 02 '17 at 17:15
  • edit: it's *running* a vbscript which sends out automated email reminders – JamesBong Oct 02 '17 at 17:49
  • 1
    Did you try [this](https://stackoverflow.com/questions/4437701/run-a-batch-file-with-windows-task-scheduler) already? (second answer) – MatSnow Oct 03 '17 at 15:27
  • @MatSnow yes, I did try that as well and unfortunately it's the same result, it will only run when set to run while user is logged on. – JamesBong Oct 03 '17 at 15:35
  • @riomyers Do you access mapped network drives somehow inside the script? – MatSnow Oct 03 '17 at 15:38
  • @MatSnow there are no mapped network drives being accessed in the script – JamesBong Oct 03 '17 at 16:03
  • 1
    The email program that you're running (probably via COM dispatch) may require more desktop heap than is available by default for a Desktop in a Session 0, service WindowStation. In Windows 10, by default a Desktop in a "WinSta0" interactive WindowStation gets a 20 MiB heap for User/GDI UI objects, but a non-interactive Desktop is limited to 768 KiB. It's assumed that services (in Session 0) don't have a user interface. However, running GUI programs as tasks in Session 0 can violate that assumption. – Eryk Sun Oct 04 '17 at 06:42
  • @eryksun thank you for the recommendations! I was able to get it to run automatically overnight while run when user is logged on was enabled... so I guess that will have to do for now. I'll keep debugging to see if I can get it working the other way but this is a good start at least as before the script would never execute from the scheduled task – JamesBong Oct 04 '17 at 13:14
  • Each Session is served by a csrss.exe process. The Session Manager (smss.exe) executes this with the command line that's stored in the registry Key "HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems" in the "Windows" value. The "SharedSection" argument is what configures the Desktop heap sizes. For example, "SharedSection=1024,20480,768" sets the global shared heap to 1 MiB, the heap for interactive desktops to 20 MiB, and that for non-interactive desktops to 768 KiB. – Eryk Sun Oct 04 '17 at 13:33
  • 1
    I would try multiplying the third number by 8, and reboot. In my case on Windows 10, this increases it from 768 to 6144. You want the non-interactive heap size to be as small as possible. For example, if 6144 works, try half as much, 3072, and if that works try 1536. But if even 6144 KiB doesn't work, the problem is probably not the Desktop heap. – Eryk Sun Oct 04 '17 at 13:42
  • If you haven't solved it yet, can you show your exact string/line you are having the scheduler execute... e.g. the exact command you have it run – GWR Oct 06 '17 at 16:37
  • 1
    @GWR seems to be working now, stupid mistake.. I left some lines of Wscript.echo uncommented so when the task would run automatically it needed user input to confirm and continue.. since removing those it works fine – JamesBong Oct 08 '17 at 23:30

0 Answers0