Sign in to follow this  
Followers 0
Anteaus

RequireAdmin difference 3.3.8.1>3.3.12.0

5 posts in this topic

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



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

#3 ·  Posted (edited)

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

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

#5 ·  Posted (edited)

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                                                          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  
Followers 0

  • Similar Content

    • 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.
    • tremolux66
      By tremolux66
      I've abandoned the FileSelectFolder() approach and rolled my own UDF to create a dialog containing the folder list in a ListView, which seems to work fine. It's also a better fit to our requirements: we don't really want the user wandering around in the folder-selection dialog, plus the UDF displays some associated info for each folder in a second column. Thanks again to the forum members who took a look at this.
      I'm writing an installer script that needs to run as Administrator so it can, e.g., write files into protected directories. The problem is that when I call FileSelectFolder(), there is a 60-second delay before the dialog appears. If I run as an ordinary user (in the Administrators group), there's no delay, but I don't think that will work: for one thing, the installer needs to create a symbolic link, which a member of the Administrators group can't do unless the program is elevated. (This is Win 7 x64.)
      (The installer will be run using an Admin account; the other user accounts are locked down and don't have access to the filesystem, the Start menu, Computer, etc. - it's a turnkey system.)
      Any idea what causes the delay? And is there a way around it?
       
    • dreivilo47
      By dreivilo47
      When I use the following code I receive an UAC message:
       
      #RequireAdmin RunWait("msiexec /i winzip205-64.msi /quiet") Exit How can I hide (bypass) the UAC message?