Bizarre problem launching app from script shortly after boot-up ONLY

[Mbee]

I have a puzzling problem with a script that works correctly ONLY if it is run manually well AFTER the system has been booted up for several minutes on ONE of my systems, but ALWAYS works fine at any time on my other systems!

Here's my situation: I occasionally run, at shutdown, an application (which I call "MiscApp" in the code I'll post below) that unfortunately sets itself to run again the next shutdown, which is something I do NOT want to do.  So after years of manually canceling it, I found AutoIt and coded up a script that will do it automatically.  The script is set to run (by a startup app) 60 seconds after every boot-up is finished.  It checks to see if the shutdown task is scheduled (it will appear in one of the run sections in the registry), and if so, it will launch a sister app and then perform some mouse actions and button presses to cancel the unwanted app.

But on one (and only one) of my 32-bit XP Pro/SP3 boxes, I see a very puzzling thing: For some reason, the "sister app" doesn't actually get launched, even though I always test the return codes and the AutoIt "Run()" function never returns an error!  So since no error code is returned even though the app is never launched, the rest of the script keeps on running and so I see the mouse moving across the non-existent app and all the non-existent buttons are pressed!

The only thing I can think of that is different about the system in question is that it has a quad-core processor (Intel Q9650), which makes me wonder if some synchronization issue may be involved (even though I realize that shouldn't make the tiniest bit of difference).  The other bizarre thing about this is that the script will work perfectly if I launch it manually several minutes AFTER boot-up has finished (instead of having the script run automatically 60 seconds after boot-up).

Here's my code (with some Includes and comments stripped out):

expandcollapse popup

Const $Cmy_MiscAppPath = "C:\Program Files\Misc\MiscAppRun.exe"
Const $Cmy_MiscAppDPath = "C:\Program Files\Misc\MiscAppD.exe"
Const $Cmy_MiscAppName = "MiscApp"
Const $Cmy_MiscAppProcName = "MiscAppRun.exe"
;
Local $L_Stat, $L_RegString, $L_MBoxReturn, $L_ProcessID
Local $L_ThisStr = "", $L_MiscAppWinHandle
Local $L_MiscAppStatChange = "unchanged"
;
;
; --- Entry Point - Begin
;
AutoItSetOption("WinTitleMatchMode", 1) ; 1 = Matches partial titles from the start (Default value)
AutoItSetOption("MouseCoordMode", 0) ; 0 = Use coordinates relative to Window
;
; First we need to see if MiscApp's got a current task run set, so we read the registry...
;
$L_RegString = RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run", "MiscAppD")
If $L_RegString == "" Then
    $L_Stat = 0
    Exit 1          ; There's nothing to do, so exit
Else
    $L_Stat = 1
    $L_MiscAppStatChange = "cancel"     ; No user interaction in this AUTO process - Therefore ALWAYS "cancel"
EndIf
;
;   First check to see if MiscApp is already active. If not, launch it.
;
$L_ProcessID = 0
$L_MiscAppWinHandle = ProcessExists ( $Cmy_MiscAppProcName )    ; Returns PID if active, else returns zero
If $L_MiscAppWinHandle = 0 Then                 ; If MiscAppRun.exe is NOT already active, then...
    $L_ProcessID = Run( $Cmy_MiscAppPath )          ; Launch MiscAppRun.exe
    If $L_ProcessID = 0 Then
        MsgBox($MB_OK, "MiscApp Windows Activation Failure", "MiscApp Activation Error (1) - Error Code = " & @error)
        Exit -1
    EndIf
    $L_MiscAppWinHandle = $L_Stat
EndIf
;
; If we've reached here, then the target app is SUPPOSED to be an active task, so we need to cancel it.
;
; First, activate MiscApp's main window
If $L_MiscAppWinHandle = 0 Then
    $L_MiscAppWinHandle = WinActivate($Cmy_MiscAppName)
    If $L_MiscAppWinHandle = 0 Then
        MsgBox($MB_OK, "MiscApp Tool Exiting", "MiscApp Window WinActivation Failed (3)")
        Exit -1
    EndIf
EndIf
Sleep(200)
;
; Now, resize window so that we know exactly where MiscApp's non-standard controls are relative to the window
$L_Stat = WinMove($Cmy_MiscAppName, "", Default, Default, 1040, 841)
Sleep(500)

; First click on "Full Job" Task button near top right of MiscApp page to activate the window portion we need
$L_Stat = MouseClick("left", 990, 104)
Sleep(500)

; Then click on "Full Job" row in Task List
$L_Stat = MouseClick("left", 405, 710)
Sleep(500)

; Now click the appropriate pseudo-button
If $L_MiscAppStatChange == "cancel" Then
    $L_Stat = ControlClick($Cmy_MiscAppName, "Deactivate Task", "[CLASS:Button; INSTANCE:110]")
EndIf
Sleep(500)

; Finally, exit MiscApp process
$L_ProcessID = ProcessExists($Cmy_MiscAppProcName)
If $L_ProcessID <> 0 Then
    $L_Stat = ProcessClose($L_ProcessID)
    If $L_Stat <> 1 Then
        MsgBox($MB_OK, "MiscApp Tool Error", "MiscApp Process Closing Failed with status: " & $L_Stat)
        Exit
    EndIf
Else
    MsgBox($MB_OK, "MiscApp Tool Error", "MiscApp Process Doesn't Exist")
EndIf
;
$L_Stat = ProcessWaitClose($L_ProcessID, 30) ; Wait for close, but no more than 30 seconds
If $L_Stat <> 1 Then
    MsgBox($MB_OK, "MiscApp Tool Error", "MiscApp Process Wait Failed with status: " & $L_Stat)
    Exit
EndIf
;
;---------------  Script succeeded with no errors...
;
MsgBox($MB_OK, "MiscApp Tool Exiting", "MiscApp Auto-OFF Successful - Exiting")
Exit 1

Again, note that I ALWAYS see the message "MiscApp Auto-OFF Successful - Exiting" and no error reports are seen!

What the heck's going on??

Edited October 2, 2013 by Mbee

[abberration]

How about using ProcessExists and/or WinExists to make sure the program is up and running? If it is not running, then try restarting the program. You could even use a Do... Until loop and sleep the script for something like 10 seconds between retrys.

[MHz]

So the app adds a exe nag or something to the registry. Perhaps a logoff script set by Group Policy could remove the registry entry that is added and thus you may not need to treat the symptom.

This is a tidy up of your script. I found too many variables used to compare to integers that was confusing to evaluate any issue. A WinWait for the windows before moving, clicking etc. was added. I am amazed that the instance of the buttons go up to 110. You may want to check that. See if it does any better.

expandcollapse popup

Const $MB_OK = 0

Const $Cmy_MiscAppPath = "C:\Program Files\Misc\MiscAppRun.exe"
;~ Const $Cmy_MiscAppDPath = "C:\Program Files\Misc\MiscAppD.exe" ; not used ?
Const $Cmy_MiscAppName = "MiscApp"
Const $Cmy_MiscAppProcName = "MiscAppRun.exe"
;
;
; --- Entry Point - Begin
;
AutoItSetOption("WinTitleMatchMode", 1) ; 1 = Matches partial titles from the start (Default value)
AutoItSetOption("MouseCoordMode", 0) ; 0 = Use coordinates relative to Window
;
; First we need to see if MiscApp's got a current task run set, so we read the registry...
;
If RegRead("HKCU\Software\Microsoft\Windows\CurrentVersion\Run", "MiscAppD") == "" Then
    Exit 1          ; There's nothing to do, so exit
EndIf
;
;   First check to see if MiscApp is already active. If not, launch it.
;
If Not ProcessExists($Cmy_MiscAppProcName) Then                 ; If MiscAppRun.exe is NOT already active, then...
    ; Launch MiscAppRun.exe
    If Not Run('"' & $Cmy_MiscAppPath & '"') Or @error Then
        MsgBox($MB_OK, "MiscApp Windows Activation Failure", "MiscApp Activation Error (1) - Error Code = " & @error)
        Exit -1
    EndIf
EndIf
;
; If we've reached here, then the target app is SUPPOSED to be an active task, so we need to cancel it.
;
; First, activate MiscApp's main window
If WinWait($Cmy_MiscAppName, "", 30) Then
    If Not WinActivate($Cmy_MiscAppName) Then
        MsgBox($MB_OK, "MiscApp Tool Exiting", "MiscApp Window WinActivation Failed (3)")
        Exit -1
    EndIf
    Sleep(200)
    ;
    ; Now, resize window so that we know exactly where MiscApp's non-standard controls are relative to the window
    WinMove($Cmy_MiscAppName, "", Default, Default, 1040, 841)
    Sleep(500)
    ;
    ; First click on "Full Job" Task button near top right of MiscApp page to activate the window portion we need
    MouseClick("left", 990, 104)
    Sleep(500)
    ;
    ; Then click on "Full Job" row in Task List
    MouseClick("left", 405, 710)
    Sleep(500)
    ;
    ; Now click the appropriate pseudo-button
    ControlClick($Cmy_MiscAppName, "Deactivate Task", "[CLASS:Button; INSTANCE:110]")
    Sleep(500)
Else
    MsgBox(0x30, "MiscApp Tool Error", "Window """ & $Cmy_MiscAppName & """ does not exist")
EndIf

; Finally, exit MiscApp process
If ProcessExists($Cmy_MiscAppProcName) Then
    If Not ProcessClose($Cmy_MiscAppProcName) Then
        MsgBox($MB_OK, "MiscApp Tool Error", "MiscApp Process Closing Failed with error: " & @error)
        Exit
    EndIf
Else
    MsgBox($MB_OK, "MiscApp Tool Error", "MiscApp Process Doesn't Exist")
EndIf
;
; Wait for close, but no more than 30 seconds
If Not ProcessWaitClose($Cmy_MiscAppProcName, 30) Then
    MsgBox($MB_OK, "MiscApp Tool Error", "MiscApp Process Wait Failed with error: " & @error & ' ' & @extended)
    Exit
EndIf
;
;---------------  Script succeeded with no errors...
;
MsgBox($MB_OK, "MiscApp Tool Exiting", "MiscApp Auto-OFF Successful - Exiting")

Exit

Your Exit 1 to finish seemed strange so I omitted the 1. The Exit codes could use a review. Perhaps your not seeing error reports as all your MsgBoxes are $MB_OK (in humor).

[Mbee]

How about using ProcessExists and/or WinExists to make sure the program is up and running? If it is not running, then try restarting the program. You could even use a Do... Until loop and sleep the script for something like 10 seconds between retrys.

 

I'll try it!  Thanks, you abberration! 

[Mbee]

 

MHz, on 02 Oct 2013 - 10:17 AM, said:

So the app adds a exe nag or something to the registry. Perhaps a logoff script set by Group Policy could remove the registry entry that is added and thus you may not need to treat the symptom.

 

Hey, that's very insightful!  Why didn't I think of that?

The only thing is, although the main app will no longer run at shutdown after I delete it from the registry, the app's state is left "confused" in that it still thinks the task is scheduled.  Thus, I still want to do it the long way...

 

MHz, on 02 Oct 2013 - 10:17 AM, said:

This is a tidy up of your script. I found too many variables used to compare to integers that was confusing to evaluate any issue. A WinWait for the windows before moving, clicking etc. was added. I am amazed that the instance of the buttons go up to 110. You may want to check that. See if it does any better.

 

Thanks again - I am genuinely grateful for your helpful criticism (I'm still an AutoIt newbie)!  But one reason the code is awkward is because I mangled the posted version and omitted parts that weren't relevant for posting, and more to the point, I've been editing the thing like crazy trying to solve or work around the strange behavior I'm seeing.  One of the several things I did was to separate out conditionals (rather than combine them as I would have normally done) so that I could step through the code during debug and/or insert debug message boxes.

Your Exit 1 to finish seemed strange so I omitted the 1. The Exit codes could use a review. Perhaps your not seeing error reports as all your MsgBoxes are $MB_OK (in humor).

 

Ha! Got it.  But as I stated in my OP, I also stripped out several Includes before posting.  One of those "missing" Includes was "Constants.au3", which defines $MB_OK and so forth.

Thanks again!  I'll give it a try, and if I still have problems, I'll post again.  Otherwise, I'll credit you for the solution...

 

[Mbee]

That worked, MHz, thanks!

Aside from the stylistic changes (though again, I appreciate your constructive criticism), the key functional difference between my code and yours was that you surrounded the path in the "Run ()" call with quote marks, which I failed to add.  That's an important lesson!  I wasn't really aware that they were needed even when the path string argument provided was a constant.

One minor puzzle remains, however: Why do my versions of the script withOUT the added quote marks work properly on all my other systems? And why does it work correctly on the system in question when I ran it manually after a couple of minutes?

I guess it's another of those "wrong, but works sometimes if you're lucky" things, eh?

 

(Oh, and by the way, the app that the script works on is a commercial app that uses lots of non-standard ( ) controls, so there are actually even more than 110 non-standard buttons & controls!

Edited October 2, 2013 by Mbee

[MHz]

Well, that was easier then what I thought may happen. So the quotes may have been the prime concern.

I guess it's another of those "wrong, but works sometimes if you're lucky" things, eh?

IMO, you are relying on a bug. Whitespace is a terminator of parameters in a command. If the system is guessing that the next whitespace terminated parameter is part of the previous parameter then that is incorrect and should fail every time. What is happening, depending on the structure of the file system etc. is that it is allowed sometimes. Quotes are used to prevent whitespace termination between the quotes so you should use them unless you like failure happening sometimes.

[Mbee]

Damn, it doesn't work right after all - sorry MHz!  It looks like you were prescient to think the problem wasn't going to be solved that easily after all...

I just booted up this box after having the "misc app" conditions set as described in my OP, and once again it continued to move the mouse around and click non-existant buttons even though the app it was supposed to operate on never launched.  Also, no errors were reported.

The mystery persists!

I'm looking into it again, and I'll post the latest version if aksed....

[Mbee]

I should add some additional information, now that it seems that perhaps the mysterious issue I'm having isn't directly related to the AutoIt code itself.

(1): The purpose of the commercial apps (main app and sister app) in question is to clean up a bunch of potential system security leaks (similar to CCleaner and the like) and then shut down the machine.  Some of the things it clears are various caches, including stored application data and so forth, that will have to be re-created during (or after?) boot-up.  It's therefore theoretically possible that some resource that the AutoIt script needs may not yet be fully re-established within 60 seconds after the startup has completed, and that's what's causing the weird behavior.  However, that seems unlikely to me...

(2): The fact that the bizarre behavior is only seen when the script (which has been built into an executable) is run automatically by a startup app (WinPatrol), but has never been seen when launched manually bears considerable scrutiny.  What might be going on here?

(3): Starting only within the last month or so, during startup a never-before-seen message window has started coming up and staying up for 30-40 seconds or so.  I don't know what it's referring to and I don't know how to find out, either!  I've attached an image of the window:

Pressing "Switch To" raises the Start menu (but nothing is chosen or identified to switch to), and "Retry" does nothing but refresh the message window.  I have no idea what it wants me to do.

Might this have something to do with it?  How can I find out what it's referring to?

For the record, however, the window is always gone by the time the AutoIt script/app is launched.

 

I don't know if any of that is relevant; what do you think?

 

[MHz]

(1) In the name of... usually amounts to deception and can be known as a coverup. The app seems to be doing stupid things in the name of...

(2) No evidence that WinPatrol is the culprit. No matter how I feel about antivirus programs and who they seem to be protecting.

(3) Probably getting confused if some how starting another instance of it. Multiple instances could be trying to access the same data files etc which could cause hung processes. And you may find that the windows are hidden and will not show as they are still in the hung startup of the code stage.

Perhaps you should instead log to file its behavior rather then trying to automate it and see what it is doing. You can use WinList to get the window titles of the app. Perhaps use ProcessList to see what is running at that time. Check the Run keys in the registry for odd entries. You may need to isolate the program by disabling some other programs to see if a conflict was happening. Do whatever is in your control to understand it and if it is bugged then submit a bug report to the developers of the program.

In your post #8, WinWait should be triggered by a shown window, so how the mouse actions are being processed may evaluate to the window showing for the tiniest amount of time and disappearing again. It may be good idea to add If WinWaitActive with timeout after the If WinWait and give it a little Sleep.

That is about the best advice I can give you about your Misc App at present.

[Mbee]

Update - I just tried moving the app-that-doesn't-appear launch out of the AutoIt script and into a preceeding batch file.  The results were somewhat better, in that the app actually launched to some extent.  However, the app in question never finished fully loading, such that there was little more than a frame showing, and none of the controls were visible.

What that tells me is that, at least on this XP Pro system, apps don't quite launch properly even a full minute after booting!  At a guess, I'd speculate that some kind of initialization is still taking place that prevents a full launch, at least from WinPatrol's delayed startup.  Yet manually launching the script at that time works fine. What a puzzle!

Next, I'll try two different things: (1) Changing the startup delay from 60 seconds to 3 minutes ; and (2) Moving the startup launch from WinPatrol's delayed startup to the regular startup list and see if that makes any difference...