Jump to content

HLKM64; it's documented but does it work?


Recommended Posts

As documented here, it is possible to bypass registry redirection when running a 32bit application on a 64bit Windows installation, using HKLM64 or HKCR64. I quote:
 

For registry interaction, use HKCR64 or HKLM64 to bypass the redirection mechanism see Registry Functions documentation.

 
In this thread, >this feature's existence is denied.

Also, if this feature exists and works, does it work on both production and beta? And can I also specificy HKEY_LOCAL_MACHINE64 and HKEY_CLASSES_ROOT64 instead of HKLM64 and HKCR64?

Link to post
Share on other sites

Hmmm, I just tested it on Windows 7 Home Premium x64, and what HKLM64 does is evade the registry redirector as documented: instead of storing registry writes to virtual locations under Wow6432Node, Windows now lets my 32bit application write to and read from the normal non-redirected locations...

Am I missing something here? :)

Link to post
Share on other sites

you need to correct multiple path in registry to help windows to call the correct DLL's that are not called in HKLM x86 this feature exist i can give you the complet set of key you have to check i need to get back my documentation if i found it i ll edit that post

My video tutorials : ( In construction )  || My Discord : https://discord.gg/S9AnwHw

How to Ask Help ||  UIAutomation From Junkew || WebDriver From Danp2 || And Water's UDFs in the Quote

Spoiler

 Water's UDFs:
Active Directory (NEW 2018-10-19 - Version 1.4.10.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX (2018-10-31 - Version 1.3.4.1) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example Scripts
PowerPoint (2017-06-06 - Version 0.0.5.0) - Download - General Help & Support
Excel - Example Scripts - Wiki
Word - Wiki
 
Tutorials:

ADO - Wiki

 

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 RTFC
      Please answer me these questions three, ere the other side you see:
      Are you running a 64-bit machine with a 64-bit Windows operating system? Can your AutoIt scripts cope with having directive #AutoIt3Wrapper_UseX64=Y, and thus @AutoItX64=True? Are you sick and tired of seeing this error message?
      If you (like me) answered "YES" to all three questions, then the _HighMem library may ease your pain (the name commemorates a useful utility from the days when CPUs were still steam-powered). Forget about pathetic boot switches /3GB and /userva; in a full-fledged 64-bit environment, _HighMem can pre-allocate all available physical/virtual RAM you've got (or any smaller size you need), and manage individual allocations therein with four simple functions:
      _HighMem_StartUp( $nSize, $sUnit="GB" ) ; parse size of total region to pre-allocate, e.g. (10,"GB") _HighMem_Allocate( $nSize, $sUnit="B" ) ; returns $pOffset (new allocation's base address) _HighMem_Release( $pOffset ) ; existing allocations are identified by their offset (base address) _HighMem_CleanUp() ; close handles, release all pre-allocated memory Of course, existing AutoIt limitations remain in force (e.g., DllstructCreate() is still limited to 2 GB per call), but the maximum of 2-4 GB of virtual memory per Windows process can (under the right circumstances, in the proper environment) be circumvented. However, this is the first beta release, so glitches are likely, and performance may vary. In fact, it may not work at all for you (if you're running 32-bit, for example). And since this involves your own hardware, it's unlikely I would be able to reproduce your issues in my own work environment. Nevertheless, if you find obvious bugs or mistakes in the code, please do post. And if it works for you, that's also good to hear. My own motivation for developing it was to supercharge my matrix computing environment (Eigen4AutoIt), so it can handle matrices of any size that fit in machine RAM.
      The attached zip contains the library itself (HighMem.au3) and two test examples. HighMem_Test1 performs a dry run stress test of the allocation management system; it does not actually do any memory I/O. By contrast, HighMem_Test2 pre-allocates a 6 GB space, stores 3 x 2GB structs there, performs some basic I/O, and releases the allocations one by one. Obviously, for this to work you'll need at least that much free RAM to begin with (check with Task Manager -> Performance -> Memory if you're unsure). My own test environment has 16 GB of physical RAM, and runs W10Pro/64.
      EDIT: minor edits added to improve user experience (many more status messages if $_HighMem_Verbose=True)
      HighMem.v0.85.7z
      EDIT: from beta version 0.9, HighMem supports shared memory, including mutex negotiation.
       
       
       
      HighMemv0.9.2.7z
    • By diepfeile
      I'm using the following:
      Autoit 3.3.14.5
      newly installed Beta 3.3.15.5
      SQlite version 3380000 aka 3.38.0
      I put sqlite3.dll and sqlite3_x64.dll in C:\Windows\System32 since many scripts depend on them.


      I extended the output of _SQLite_Startup()
      with:
      ConsoleWrite("@AutoItX64 " & @AutoItX64 & @CRLF) ConsoleWrite("$sDll_Filename " & $sDll_Filename & @CRLF) ConsoleWrite("_SQLite_LibVersion=" & _SQLite_LibVersion() & @CRLF)

      Also using the script from https://www.autoitscript.com/autoit3/docs/libfunctions/_SQLite_Startup.htm for testing.

       
      >Running:(3.3.14.5):C:\Program Files (x86)\AutoIt3\autoit3.exe "R:\Download\aasdf.au3" @AutoItX64 0 $sDll_Filename sqlite3.dll _SQLite_LibVersion=0 >Running:(3.3.14.5):C:\Program Files (x86)\AutoIt3\autoit3_x64.exe "R:\Download\aasdf.au3" @AutoItX64 1 $sDll_Filename sqlite3_x64.dll _SQLite_LibVersion=3.38.0 >Running:(3.3.15.5):C:\Program Files (x86)\AutoIt3\Beta\autoit3.exe "R:\Download\aasdf.au3" @AutoItX64 0 $sDll_Filename sqlite3.dll _SQLite_LibVersion=0 >Running:(3.3.15.5):C:\Program Files (x86)\AutoIt3\Beta\autoit3_x64.exe "R:\Download\aasdf.au3" @AutoItX64 1 $sDll_Filename sqlite3_x64.dll _SQLite_LibVersion=3.38.0


      Why doesn't it work in 32bit, despite me having the 32bit sqlite.dll? Autoit urges running scripts in 32bit mode and Scite starts scripts just in 32bit mode without the flag?
      With #AutoIt3Wrapper_UseX64=Y it just works, both normal Autoit and beta!
      sqlite3.dll sqlite3_x64.dll
    • By SWSSSM
      Hi there,
      maybe someone can help me.
      If automated a script that should xcopy from various paths (all within C:\*\...) to a external Disk (HDD). (Backup data of users who get new pcs win10)
      I tried it several times with windows 10 home/pro any clients and never got any failure. (after the testing was done)
      But when i tried to run it shortly ago on a windows 7  pro x64 client, the script started (as i saw in taskmanagr.exe) but i didn't performed any of the actions when i came down to the xcopy part.
      (in the systemtray, it showd the scipt to start, but it was marked as "paused" and i couldn't stop this. No plan why)
       i inserted/attached the script down here.
      Does anyone know why? any ideas?backup-scrp.au3
      PS:  the tray debug line just added by today (i re-try it tomorrow when i've set up another win7 client to test with)
      PPS: i know my coding-style isn't very optimized
    • 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 Beege
      Heres a function for searching for a bitmap within another bitmap. The heart of it is written assembly (source included) and working pretty quick I feel. I have included an example which is pretty basic and should be easily enough for anyone to get the concept. 
      You will be given a small blue window that will take a screencapture of that size:

       
      It will then take a full screenshot and highlight all locations that it found

      Please let me know if you have any issues or questions. Thanks!
       
      Update 8/5/2019:
      Rewrote for fasmg. Added full source with everything needed to modify
      BmpSearch_8-5-2019.7z
      BmpSearch.zip
       
      GAMERS - Asking for help with ANY kind of game automation is against the forum rules. DON'T DO IT.
×
×
  • Create New...