Jump to content
Sign in to follow this  
Anteaus

RequireAdmin difference 3.3.8.1>3.3.12.0

Recommended Posts

Anteaus

A specific executable compiled with Aut2Exe 3.3.8.1 running under Windows 7.1/64 requests UAC/UAE elevation if it is compiled with the RequireAdmin option. Which is the expected behaviour.

However, when the same code is compiled with 3.3.12.0 no UAC prompt occurs, and instead the exe (or possibly the calling program) reports 'CreateProcess failed; code 740' and fails to launch.

Just wondering if there are any known differences here. If the issue hasn't been seen before I'll do a few more tests to try and establish under what conditions it occurs.

Share this post


Link to post
Share on other sites
JLogan3o13

Or you could post the code so we can see what you're doing, rather than asking us to first guess and then troubleshoot ;)


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites
Anteaus

Or you could post the code so we can see what you're doing, rather than asking us to first guess and then troubleshoot ;)

#RequireAdmin

In this case the compiled script is called by an Inno Setup installer. Though, I don't think the actual mode of calling is significant so long as it's from a limited account.

The reason I need to recompile, BTW, is that the 3.3.8.1 build is suffering antivirus false positives.

I found a couple of other threads relating to this or similar issues:

 '?do=embed' frameborder='0' data-embedContent>>

 '?do=embed' frameborder='0' data-embedContent>>

-though they don't seem to offer any definite answer to this one.

Edited by Anteaus

Share this post


Link to post
Share on other sites
JFX

The only difference seems to be that the newer version adds "requireAdministrator" to exe manifest.

Actually question is why isn't your "Inno Setup installer" not running with admin rights?

Share this post


Link to post
Share on other sites
Jos

The only difference seems to be that the newer version adds "requireAdministrator" to exe manifest.

.. and doesn't re-shell itself as the other one would do to run with the different level in case not running at the required level.

Jos

Edited by Jos

Visit the SciTE4AutoIt3 Download page for the latest versions  - Beta files                                How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

    • griefman
      By griefman
      Hi everyone,
      i am writing to you after a very long struggle i had while trying to figure out how to send a simple click inside a virtual machine running in vmware workstation 14.
      i have an autoit script running on my host machine watching for the UAC prompt to be displayed in a running vm. Both the host and the guest OS are Windows 10. This script worked perfectly with virtual box. It recognized the UAC prompt and clicked inside and the UAC was accepted. Since i switched to VMware Workstation 14, the script no longer clicks inside the VM successfully. It acts as if it clicks, but it doesn't. 
      I tried sending key combinations instead of a click, so that the VM can grab the input, but it also did not work. Every attempt that i made to send clicks or keys from the host inside the VM did not work. I tried using:
      MouseClick
      ControlClick
      MouseMove
      _WinAPI_Mouse_Event
      _WinAPI_Keybd_Event
       
      I also noticed that while the cursor moves to the target which has to be cilcked when my vmware worstation window is not focused, it even doesn't do that when i WinActivate the vmware workstation window first.
       
      Did anyone experience such an issue, or maybe could give me a hint, what else i could use to send a key combination or a mouse click in a vmware workstation 14 pro guest window?
       
      here is my code, which works with virtualbox:
       
      #AutoIt3Wrapper_Icon=".\uac.ico" #include <ImageSearchSubrogated.au3> FileInstall(".\ImageSearchDLL.dll", ".\ImageSearchDLL.dll", 0) FileInstall(".\UAC_ginloSetup.bmp", ".\UAC_ginloSetup.bmp", 0) FileInstall(".\UAC_Yes.bmp", ".\UAC_Yes.bmp", 0) ; set global variables for the coordinates, which should be delivered global $x1 = 0, $y1 = 0 global $x2 = 0, $y2 = 0 global $counter1 = 0 global $counter2 = 0 global $sleep = 10000 global $smallSleep = 5000 ; execute the script in a loop, so that it will hopefully recover from some unexpected errors While $counter1 < 1 checkForImage() WEnd #cs ------------ Functions #ce ------------ Func checkForImage() While $counter2 < 1 ; search for the UAC in the entire screen - 2 screens supported local $searchUac = _ImageSearchArea('UAC_ginloSetup.bmp', 1, -2568, -8, 5136, 1440, $x1, $y1, 0) If $searchUac = 1 Then ; if the UAC was found search for the Yes button in a an area 200 x 200 from the middle of the found UAC image local $searchYes = _ImageSearchArea('UAC_Yes.bmp', 1, $x1, $y1, $x1 + 200, $y1 + 200, $x2, $y2, 0) If $searchYes = 1 Then ; if the Yes button was found click it and pause the script for $sleep seconds MouseClick("left", $x2, $y2, 1,0) Sleep($sleep) Else ; if the Yes button was not found retry from the beginning in $smallSleep seconds MsgBox(0, "UAC found error", "UAC was found but the 'Yes' button was not found. Script will retry in " & $smallSleep & " seconds.", $smallSleep) EndIf ; another way to accept the UAC - via shortcut ;Send("{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}") ;Send("!y") Else ; if UAC was not found try again in $sleep seconds Sleep($sleep) EndIf WEnd ; if some error occured which expired the loop, pause the script for $sleep seconds MsgBox(0, "Error", "Some Error expired the timer and the script could not recover. The script will restart in " & $sleep & " seconds.", $sleep) EndFunc  
    • RC86
      By RC86
      Morning! I've searched for a definitive answer on the forums on this but can't find one so here goes.  I need admin for one of my functions so I'm using #RequireAdmin.  I then noticed that regardless of that function being used or admin actually being required, the program pops up and requires admin all of the time.
      Is this the way it's designed and is there a way around it so that I can launch my program as normal until admin is required, then and only then prompt the user to run the program as admin?
      The only solution I could think of is to produce 2 executables and do something like:
      $adminrequired = 1 If($adminrequired = 1) Then Run(Run first executable which includes #RequireAdmin) Else Run(Run second identical executable without #RequireAdmin) EndIf Obviously I'd rather keep to making a single executable rather than having 2 or 3!
      Thanks
    • tcurran
      By tcurran
      Here's a short UDF that will, at least in most cases, detect whether a window can be copied from or pasted to programmatically--for example, by Send()ing ctl-c, ctl-v. This is often disabled when programs (like your AutoIt script) run at a lower UAC integrity level than the application they are trying to operate on.
      #include <WinAPI.au3> Func _WindowIsPasteable($handle) ;accepts window handle; returns true or false whether a window will accept Ctl-C, Ctl-V Local $bCanPaste = True Local $hTestWindowPID = 0 Local $hTestWindowTID = _WinAPI_GetWindowThreadProcessId($handle, $hTestWindowPID) _WinAPI_AttachThreadInput(_WinAPI_GetCurrentThreadId(), $hTestWindowTID, True);attach to window we want to paste into $bCanPaste = _WinAPI_GetFocus() ;Test whether window is paste-able--returns False if it is not _WinAPI_AttachThreadInput(_WinAPI_GetCurrentThreadId, $hTestWindowTID, False);detach from window thread Return $bCanPaste EndFunc Pass it a window handle; it returns true or false whether a window will accept programmatic pasting. The function may not work on the CMD window, since it handles the clipboard uniquely.
      This function works by attaching to the program thread of the window whose handle it receives, then attempting to perform a GetFocus on that thread. In most cases, the attempt will fail if the window will not accept programmatic copy-paste.
    • knuxfighter
      By knuxfighter
      Hello. I've been working with Imagesearch library lately and it did a good work, although I moved to a new PC and didn't copy the old files with me so I downloaded the Imagesearch from the following post
       hoping that it will work. It doesn't though. First time I when I use (run as subscript to my code) the Imagesearch.au3, Scite finds errors (missing spaces). Ctrl+T (scite tidy) fixes these missing spaces but the script returns the following error on every run after:
      _ImageSearch('search.bmp', 0, $x, $y, 0) outputs
       
      "C:\Users\Knuckles\Desktop\AutoIt\include\ImageSearch.au3" (44) : ==> Subscript used on non-accessible variable.: If $result[0] = "0" Then Return 0 If $result^ ERROR no matter if I put the searched bmp in the script folder or folder img in the script directory. Also, it doesn't matter if the searched image on screen or not, it returns the same.

      Can you provide me any help please? I remember having these problems 2 years ago when I first met the imagesearch library also (I fixed it somehow though in that time). Seems nothing changed.

      Using this version posted in the following post gives the same error:
      Also I run windows 10 64bit and I have no shell options for script editing, running as x86 or whatever as I used to have on windows xp/7. I went through some steps like deleting a key in registry and I even reinstalled autoit and scite but that only resulted to au3 as unrecognized file format and not in getting back the menus and the icon on au3 files. Any thoughts on this?

      Edit: Installing 64-bit AutoIt and using 64bit ImageSearch is no change.
      code.au3

      FOUND WORKING: http://www.codebot.de/index.php/Thread/12713-Imagesearch-au3-funktioniert-nicht/
       but why is this one working and the original aren't? :(
    • nss
      By nss
      Hi all. I am creating an app that runs a program with the admin privileges using the shellexecute's run as verb, but what my problem is, that no matter what I use to launch the program, it doesn't quite work like the run dialog would (certain programs don't get found, etc.). I've tried using the explorer.exe and passing the program to it, that is unreliable and opens documents folder sometimes instead, I've tried using the @comspec /c and that works better, but still some of the programs aren't being found that would be with the run dialog e.g., if I do @comspec /c diskpart it won't find it, I've even tried setting the working dir, but still no luck. I also tried passing commandline params to C:\WINDOWS\system32\rundll32.exe shell32.dll,#61, but no luck. can anyone help me what way to go in order to be able to launch programs in the run dialog style? is there a function in winapi that run dialog uses that I could use as well? Or what would be the best way to go about this? Any help much appreciated.
×