Sendkeysto not working once script is compiled

[ddewar]

The Wbt File with the following script works fine on windows 7 64 bit

Run("c:\windows\system32\MsiExec.exe", "/X {88C972E7-D7FC-40F3-9FE5-180957F37B45} /q /norestart")
WinWaitExist("Global VPN Client", 10)
SendKeysTo("Global VPN Client", "{SPACE}{TAB}{TAB}{SPACE}")
exitcode = 123 ; assume failure
IntControl(1000, exitcode, 0, 0, 0)
exitcode = 123 ; assume failure
IntControl(1000, 0, 0, 0, 0)
Exit

Once I compile this it seems to fail to answer the popup box that occurs after the Msiexec has uninstalled the software

I need winbatch to answer the question

Running winbatch 2016b

[td]

There is nothing about the act of compiling a script that in and of itself will affect the behavior of the 'SendKeysTo' function.  The difference in behavior is the result of something different in the environment the script is running in when it is compiled when compared to when it is executed by WinBatch.exe.  For example,  are there any difference between the UAC settings of the Compiled script and WinBatch.exe UAC settings for .wbt files?   Are there differences in the user account type running the uncompiled and compiled script?   

[ddewar]

This compile was done with default setting in place and also with elevated credentialls
I have just tried running the exe as is on an machine logged in as the local admin
and I have tried running it as administrator  the results were the same

[td]

'Default settings' could be why it is not working.  Running the compiled script as an admin, local or otherwise, tells little other than it could be a UAC problem.  But without a lot more information little else can be said.   You will need to figure it out yourself or provide more information.   But first you need to get passed the idea that the problem is because it is compiled.

[td]

A few things to consider:

• WinBatch's UAC manifest settings are highestAvailable and True.  How does that compare to the compiled script's?
• WinBatch executes from a secure location.  Does the compiled script do so also?
• What version of Windows is on the computer running the compiled script and how does that affect script execution?
• What are the UAC settings on the computer running the compiled script and what impacts does that have on the compiled script?
• Does the install process spawn other processes and if so, what are the integrity levels of those process?

[ddewar]

The environment is as listed:
Win 7 64  UAC enabled
Sonicwall Global Vpn 4.9 64 bit

Uninstall is calling the guid in the uninstall dir in the registry
When I compile
The requested execution Level is Either Elevated or require admin
Uiaccess flag is false
Sign code is unchecked

I have also tried including extenders


AS a side note this issue occurs on windows 10 as well

This works when its a WBT file  but not once its compiled

[snowsnowsnow]

Note that the script itself has a bug - which is that if the needed window takes longer than 19 seconds (yes, 19) to appear, the script will fail.  OP has not told us exactly *how* the script fails, but my guess is that some error/abort/message is being generated.  Perhaps he is running in a mode where he does not see the error box.

The problem is that the script has:

WinWaitExist("somewindow",10)
Sendkeysto("somewindow",...)

Which gives a total delay of up to 19 seconds, with no error checking.

[ddewar]

So there is no error that pops up.
What does happen with Sonic wall is:
Msiexec /x  successfully uninstalls the program
At the end of that uninstall Global Vpn client pops up a box with two check boxes and a continue
One box needs to get checked and continue need to be pressed.

In the WBT as written it successfully complete the task of uninstall and answering the popup box
The compiled exe uninstalls the app but leaves the popup box unanswered and up on the screen forever
So the send keys function isn't running or is sending the keystrokes at the wrong time

[td]

Every time a list is posted in any form on this forum, the responder ignore some of the items.

Since you keep repeating that it works when not compiled, I will keep repeating that the failure to work when compiled is not simply because it is compiled.  The SendKeysTo function works exactly the same in a compiled script and a non-compiled script.  The problem is the result of either the difference in manifest settings (UAC settings) or a difference in the executable's computer environment or a combination of the two. 

Some random thoughts:

Environment differences may include but are not limited to the compiled scripts startup directory (see list above.)  The startup directory is related to the fact that uiAccess is set to TRUE for WinBatch but FALSE for the compiled script.

Another possible environmental cause is that your compiled script is not the foreground application at the time the SendKeysTo function is called but WinBatch is at the time of the call.

It could also be that you are not compiling the same script that you are running with WinBatch.exe - it happened more times that you might think.

As Snow++ pointed out the script is not well written but the SendKeysTo function only errors when it can't find the target Window.  It does not error when it can't bring the target window to the foreground.  The latter appearing to be the problem here.

[ddewar]

Thanks for the Info TD
I am completely new to winbatch  so I didn't understand all your  random thoughts.
I will try and address them here:
Manifest setting as If i understand what you wrote that invoking the wbt file through winbatch studio that runs with UIACCES set to True  (by default)
   During compiling i was leaving UIACCESS set to false because I do not have a cert to self sign this script
Compiled script is not the foreground app when run,  I run this from the desktop of the test machine  and tried running as admin or just double clicking
           Sometimes i click the App in the task bar  to hopefully see if an error is thrown
I definitely am compiling the same script

   If my script is written badly I would appreciate so suggested improvements.

[td]

The issue of code signing and uiAccess set to true is not straight forward.  It has been reported that simply placing the executable with uiAccess set to true in a protected directory will enable the executable to bypasses "User Interface Privilege Isolation" even though MSFT sometimes states that it must be signed and in a protected directory.  Note that a protected directory is a directory that only Admins can write to and that the signing requirement may be influenced by group policy registry settings.  A sub folder of Program Files (x86) is an example of a protected directory.   WinBatch.exe is signed, executes from a protected directory, and has uiAccess set to true but it would appear that your compiled script does not have any of these attributes.  You should consider testing your compiled script in a protected directory with uiAccess set to true.  It may or may not make a difference but only you can determine that.

Another avenue of investigation is to use IntControl 61 to change the activation method of your script.  This may or may not allow your compiled script to activate your window.  Assuming that window activation is the problem. 

[td]

In order to add to any existing confusion, it should be mentioned that Microsoft documentation states that you only need to set uiAccess to true if the application is running at  medium or low integrity level and the targeted application is running at a high integrity level.  If your application is running at a high integrity level, you should not need uiAccess set to true.   MSFT documentation also states that the secure location requirement can be turned of using a registry setting but that the code signing requirement cannot be turned off via the registry.

Whether or not either of these documented statements are always accurate is not completely certain given that observed behaviors on some newer versions of Windows differ from expectations based on documentation. 

[td]

Better late than never but on giving this a little more thought, I may have incorrectly assumed  that the compiled and uncompiled script are being executed on the same test system.  If that assumption is incorrect and the two versions were tested on different systems then snow++'s idea that the problem is a timing issue is more likely the correct explanation.