scheduled task

I have a scheduled task that writes to a open window. Using the following script. This task has been running for years. All of a sudden the task runs but does not write to the window. If I manually start the scheduled task it works. Is it a problem with not waiting ling enough? Or is it something that has changed in the way things work. Using Windows 20h2.
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.AppActivate "Utility1"
WScript.Sleep 1000
WshShell.SendKeys ".\utility shutdown 23"
WshShell.SendKeys "{Enter}"
WScript.quit

Originally I didn't have the sleep statement. I did a search and found an example of what I was doing. The code had a sleep statement. So I thought that I would try it. As I said this code has been working of years without the sleep. The application is a powershell window named Utility1. The utility is a powershell script the suspend the system at a specific time.

The utility script does more than shutdown the system. No matter when the script is run it will wait until the specified time before starting to shutdown. Once it starts the shutdown process. The system maybe recording TV programs. So it waits until all recording is done. It then renames all of the recorded programs from that day. Then start the VAP program to gather information about commercials. Then moves the vprj files created by the VAP program to the final folder folder then suspends to memory.

Instead of specifying the window title in AppActivate, the following code retrieves the Process ID of each process named Utility1.exe and uses that to work around the known problem of AppActivate no longer working as it should on Windows 10. As for the WScript.Sleep 1000 it causes the script to wait for one second to allow the active window to become ready to accept keyoard input after the window has just been been activated.

Code:

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * from Win32_Process WHERE Name = 'Utility1.exe'") 
If colItems.Count = 0 Then
    WScript.Echo "Process not found"
    WScript.Quit
End If
Set WshShell = WScript.CreateObject("WScript.Shell")
For Each objProcess in colItems
    With WshShell
        .AppActivate(objProcess.ProcessId)
         WScript.Sleep 1000
        .SendKeys ".\utility shutdown 23"
        .SendKeys "{Enter}"  
    End With      
    Exit For
Next

Not sure this code will work on my system. There is no process named utility1.exe. Utility1 is the title of the powershell window. In task manager the windows powershell has two sub processes. One called Console Window Host the other called windows Powershell. Not sure if I changed the select statement to powershell would be correct.
But thanks for the response. I will look into the possibility that this may fix my problem. I have two systems running this code generally only one fails at night.
From your post this is a known problem?

Interesting code. Difficult to to follow for a novice. Will try the code tomorrow.
Thanks.
PS not sure why you say that windows AppActivate no longer working. It seems to work over 50% of the time for me.

What I meant to say was that AppActivate produces inconsistent results if using it by specifying a window title. You can specify a process ID instead of a window title. (Process ID, not process name, sorry I wrote that wrong.) If, for example, I open one or two textfiles in notepad and I also open one empty notepad, then if I change Utility1 in your code to Untitled - Notepad (Naamloos - Kladblok on my Dutch speaking Windows), then it should activate the empty notepad and send the keys to it, right? As it turns out, it just never works, at least for me it doesn't. A quick search on the internet confirms that even the experienced scripting guys have been having similar troubles with AppActivate over the past several years or maybe longer. Sometimes it just works, but sometimes it refuses to work, and, no one AFAIK seems to have a clear in-depth explanation for this odd type of behavior. So, finally I gave up and took the powershell route out of this strange mess from Mickeysoft. You can try it yourself, by changing the If statement, like so:

Code:

If Not ShowWindow("notepad", "Untitled") Then

Please let me know results as for which script activates the empty notepad correctly for you and which one doesn't.

- - - Updated - - -

I did some further testing. If the notepad window that I want to be activated is minimized before it gets activated via WshShell.AppActivate, then the window doesn't accept the keystrokes from SendKeys. However, if the first keystroke from SendKeys is {Enter}, all subsequent keystrokes from SendKeys will be accepted just fine. No empty line will be inserted at the beginning, so then it works perfect. Only problem, if the notepad window is NOT minimized before it gets activated in this manner, then an empty line does get inserted at the beginning. That is, excepting if I leave out this same {Enter} keystroke from SendKeys, in which case the AppActivate works perfect again. So, in a nutshell, using AppActivate before SendKeys can produce different results depending on how the task that owns the window behaves, and potentially also depending on whether the window in question is minimized.