Jump to content

Recommended Posts

Hi

I hope someone can clarify an issue that I am having with regread reporting under W7 were I have administrative rights on the machine

The situation is that I am performing the following code in a for loop against an ini file under but I am getting contradictory results depending on whether I engage UAC for the script

$Transaction = RegWrite($vidBranchPath & "\" & $iniFileSectionUSB[$i][1])
$Transaction = RegRead($vidBranchPath & "\" & $iniFileSectionUSB[$i][1], "")

If I run the script without UAC the script does not error branch even though the previous regwrite has not successfully completed the write task. If I engage UAC the registry entries are created.

My concern is not that the entries are not being created but that under non-UAC the regread is reporting their existence.

Link to post
Share on other sites

What happens i think is that whithout UAC it writes the registry with Regwrite, and reads the values with Regread , but doesnt save the changes,

so when the script finishes there are no changes to the registry done. You can test it by rinning the script with NO UAC and manually checking the registry

after script finishes.

Link to post
Share on other sites

What happens i think is that whithout UAC it writes the registry with Regwrite, and reads the values with Regread , but doesnt save the changes,

so when the script finishes there are no changes to the registry done. You can test it by rinning the script with NO UAC and manually checking the registry

after script finishes.

Juvigy

Thanks for the response. I had already tested this anomally but was not able to site temporary registry entry creation by examining the registry as the script was running. At no time did there appear registry entries to match the coding. At this point it is not a major concern as the script was developed for an XP environment but at some point we will move forward to W7

If your suspicion is correct then I am wondering how long the entries would exist for if indeed this is the case or if regread is actually returning a false result? Is this a question I should be asking in dev?

Link to post
Share on other sites

At the basic level certainty of operation so a test of true existence on non-existence, and as indicated previously there will be a requirement to support this functionality in the W7 environment which is probably the same thing that that is certainty of success of failure of an operation.

Link to post
Share on other sites

This had already been done. The rub is that in developing the script for xp without the #RequireAdmin in W7 for the XP environment still indicated that there were no errors when testing and developing the script. Doing the regread to confirm key entry was returning a true result while the key had not been written permanent hence the original question "How long do they exist for and when could a valid test be performed that would return a result of false without the #RequireAdmin in the W7 environment for use in the W7 environment

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
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Doniel
      Hi there! ūüėÉ
      I've 2 simple scripts:
      Script 1 starts script 2 Script 1 gets executed with normal user rights (un-elevated) Script 2 contains an #RequireAdmin and therefor can only start elevated I want to read the output of script 2 with script 1 AND have the UAC of script 2 being activated as fullscreen Script 1 (Scripts location is the same as script 2 that I'm running with Run()
      Local $iPID, $sOutput $iPID = Run(@ComSpec & " /c " & "C:\Entwicklung\Autoit\Test\Temp.exe", @ScriptDir, @SW_HIDE, 0x2) ProcessWaitClose($iPID) $sOutput = StdoutRead($iPID) StdioClose($iPID) ConsoleWrite($sOutput) MsgBox(1, 1, 1) Script 2 (compiled as Temp.exe)
      #RequireAdmin ConsoleWrite("Return") MsgBox(1,1,"ADMIN") Now my problems are the following:
      Without the #RequireAdmin I can read the output with no problem, but not with the #RequireAdmin ($sOutput is empty) Using @SW_HIDE in the Run() command makes the UAC always start minimized (see attached picture) and the admin has to always manually click on the icon to enter his credentials since the UAC doesn't start in fullscreen. Here and on a few other sites they explain that the program launching the elevated program NEEDS to be activated in order to directly show the UAC fullscreen and not minimized. Using @SW_SHOW would get rid of the problem, BUT that leaves me with an ugly cmd.exe floating the whole time while the elevated script ist running. And my questions to that I'm seeking an answer for are:
      Problem 1: Is it just not possible to read from an elevated program with an un-elevated user/script? I also get the Access Denied if I press No on the UAC as an Output in $sOutput (Guess since its's still un-elevated) Problem 2: Is there a way to either make the floating black and blank cmd.exe being moved to the background and be non visible to the user OR to somehow bring the minimized UAC to the foreground/fullscreen? What I already tried and what didn't help me:
      $iPID = Run(@ComSpec & " /c " & "C:\Entwicklung\Autoit\Test\Temp.exe", @ScriptDir, @SW_HIDE, 0x2) While Not WinExists("Temp.exe erfordert Ihre Berechtigung") ConsoleWrite(1) WEnd WinActivate("Temp.exe erfordert Ihre Berechtigung") WinSetState("Temp.exe erfordert Ihre Berechtigung", WinGetText("Temp.exe erfordert Ihre Berechtigung"), @SW_SHOW) WinSetState("Temp.exe erfordert Ihre Berechtigung", WinGetText("Temp.exe erfordert Ihre Berechtigung"), @SW_MAXIMIZE) WinSetState("Temp.exe erfordert Ihre Berechtigung", WinGetText("Temp.exe erfordert Ihre Berechtigung"), @SW_ENABLE) The While-Loops helps a lot and also stops after a second or so (‚Ėļ Stops to write ones (1)). That means that the actual "window" of the UAC is found, but all the WinXXX functions don't do anything and the UAC stays minimized. I also tried to minimized/move the cmd.exe to the background with WinActivate() and WinSetState() with no success.
      $iPID = ShellExecute("C:\Entwicklung\Autoit\Test\Temp.exe", "", @ScriptDir, "open", @SW_HIDE) Using ShellExecute() instead of Run() completely solves the UAC to fullscreen problem BUT I haven't found a consistent way to read the output of ShellExecute(). Neither here on the forum nor somewhere else. If I'd be possible to read the output from ShellExecute() then all my problems would be solved at once!
      Also tried a few more things and playing with some parameters but everything with no success.
      I'd really love some help and support here from you.
      Thanks in advance!
       

    • By rudi
      Hi,
      When a non compiled AU3 script is run with #RequireAdmin, then if the UAC prompt can be authorized due to the fact, that the currently loggedon user has local admin rights, then the macro @UserProfileDir correctly reflects the profile dir of the user of the windows logon session.
       
      When the script with #RequireAdmin is started by a "normal user" without local admin rights, and I use a domain admin account to authorize the UAC prompt, then @UserProfileDir reflects the profile dir belonging to the AD-Admin account.
      As the script originally was started using the "regular user" I'm wondering, if there is a chance to "pass" the original user's @UserProfileDir to the UAC elevated script?
       
      As playing around with this feature I realize, that I basically don't know the exact mechanism of the UAC elevation authorization process:
      The script is started by right mouse click, execute script This is invoking e.g. "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" "C:\Users\Rudi\Desktop\test.au3" as by this registy value: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\AutoIt3Script\Shell\Run\Command] @="\"C:\\Program Files (x86)\\AutoIt3\\AutoIt3.exe\" \"%1\" %*" But what I honestly don't know is, how does the UAC propt interact in the program startup? I guess, that Autoit3.exe is parsing the AU3 source, is seeing the #RequireAdmin and then "relaunches itself with the AU3 as %1" requesting UAC elevated rights "from windows"??? With Process Explorer I can see, that The commandline then is this one with a "!" before "%1"
      "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3"  It it should be something like this, then it might be possible to pass the original @UserProfileDir to the second, UAC elevated "Startup"??? <edit>
      I just noticed:
      When I use "WIN+R" and then directly use the command line, I see in Process Explorer, ...
      "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3"
      ... then this script with #RequireAdmin is started *WITHOUT* UAC elevation.
      Guessing, that this ! is just reverting #RequireAdmin I tried the "opposite" one as well:
      AU3 script without #RequireAdmin Starting with "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3" does not invoke UAC elevation prompt. So to me it looks like, this ! is a "status flag from Autoit3.exe to Autoit3.exe", that the elevation process was done already? amazing...
      the topic Autoit on Windows Vista is telling no details of  this UAC process...
      </edit>
       
      Regards, Rudi.
    • By joseLB
      Hi
      This piece of code creates and reads OK a key at  "HKEY_LOCAL_MACHINE" and can be changed for a key at "HKEY_CURRENT_USER"
      $sta= RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor", "wav", "REG_SZ", "5555") MsgBox(4096,"wrote", $sta &@cr& @error) $zz= RegRead ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor", "wav") MsgBox(4096,"readed","="&$zz &@cr& @error) Exit With  HKEY_CURRENT_USER, in RegEdit we can see the created key, and we can create the key by hand/RegEdit and everything Works OK.
      At¬† HKEY_LOCAL_MACHINE we can¬īt see the created key above ¬†thru RegEdit, but it Works (even not seeing, I can read).¬†But¬†¬†if¬†I create "by hand"/RegEdit¬†¬†the key,¬† it can¬īt read it with¬†¬† $zz= RegRead¬† ("HKEY_LOCAL_MACHINE.... above.
      I¬īm the PC¬īs WIN.7 administrator. Even so I ran RegEdit as administrator and also the compiled AU3 and also plain. No changes.
      edit: even if Try   "HKEY_LOCAL_MACHINE\SOFTWARE\AAA", "wav", the same holds true.
      $sta= RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\AAA", "wav", "REG_SZ", "4444") MsgBox(4096,"wrote", $sta &@cr& @error) $zz= RegRead ("HKEY_LOCAL_MACHINE\SOFTWARE\AAA", "wav") MsgBox(4096,"readed","="&$zz &@cr& @error) Exit Seems that it creates this key at another place.... I can read the above value ("4444"), even after a boot, even the key not showing in regedit. And if I create it by hand key AAA/wav with a distinct value (666), t, it continues Reading the old value = 444.
      Thanks
      Jose
       
    • By GeorgeB
      I'm writing a little applet that basically tells you when Windows was installed.  There is a REG_DWORD in Windows that gives you this. It's basically a value that is the # of seconds from 1970.
      The location is:  "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate"
      So if I run this in AutoIT, I should get the value displayed within the msgbox:
      MsgBox($MB_SYSTEMMODAL, "InstallDate Test", RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion", "InstallDate"))
      However, what happens is it always returns a value of "0"  I tried this on several machines (Windows 8, Windows 8.1 and Windows 10). 
      Am I missing something?  If I manually view this REG_DWORD with RegEdit, it shows me the HEX value, or I can view the Decimal value. I don't care which value AutoIT reads, as I can always convert back and forth, but I just don't see why it can't read a value from this REG_DWORD.  As a test, I've read other REG_DWORD values, and with most it doesn't return any value, not even a 0.
      Please, even if you guys have some other (perhaps better) way to read the Windows install date, I would still like to find a resolution to this problem, because I want to understand why I am having so much difficulty with reading REG_DWORD values from the Windows Registry with AutoIT.
      Thanks for any help!
       
       
       
       
       
    • By timmy2
      I want to determine if AutoLogon is enabled on a Windows 10 Pro (64-bit) system. It's my understanding that the following registry key will exist and equal 1 if autologon is enabled, or equal 0 if disabled. 
      Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon So l looked up RegRead in AutoIt's help file and tested the example.
      #include <MsgBoxConstants.au3> Local $sVar = RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion", "ProgramFilesDir") MsgBox($MB_SYSTEMMODAL, "Program files are in:", $sVar) The resulting message box says:  C:\Program Files (x86)
      Regedit says the value in ProgramFilesDir is C:\Program Files. "C:\Program Files (x86)" is in a nearby key "ProgramFilesDir(x86)", which makes sense.
      I ignored this anomaly and tried RegRead in my own script:
      #include <MsgBoxConstants.au3> $isEnabled = RegRead("Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon", "AutoAdminLogon") If $isEnabled = 1 then MsgBox($MB_SYSTEMMODAL, "", "Autologon enabled.") Else MsgBox($MB_SYSTEMMODAL, "", "Autologon disabled.") EndIf My punishment for ignoring the problem with the Help file example is that regardless of whether the AutoAdminLogon key equals 0 or 1 in reality, my script's $isEnabled variable returns 0.
      Despite the problem with the RegRead example I still figure I'm at fault, but I would appreciate someone pointing out my mistake, please. 
       
       
×
×
  • Create New...