Jump to content

Always need to RegDelete() both 64-bit -AND- 32-bit reg keys?

Recommended Posts


Under a 64-bit OS, do I always have to call RegDelete() with both the 64-bit reg path and the regular reg path if I want to delete a reg key or value?

I've been insulted here : for writing more than a dozen or so words in these posts, but I don't know any other way to explain myself, so here I go again (please be kind):

I've been struggling with the fact that the scripts I've recently written to delete some registry keys on a 64-bit Windows 7 Pro system don't end up actually deleting the keys in question.  In these scripts, I've always made sure to suffix the reg root key with "64", as emphasized in the RegDelete() help file.  For instance, to delete a key starting with "HKU", I've made sure the reg path starts with "HKU64".

I scrupulously check the return codes after every function, and certainly did so with the RegDelete() calls, but while there was never any error, the keys in question were always still there when I examined them using my 64-bit registry editor (Registrar Registry Manager 64-bit), using the standard key paths!

After repeatedly failing to actually delete the keys in question, I modified the scripts to call RegDelete() with both "HKU64..." -and- "HKU...", and lo and behold, it worked!  The keys were actually gone.

Questions: (1): Is this something everyone already knows?  If so, where is it explained?

(2): Is it always true under a 64-bit OS that one must always delete both sets of keys?  Or is it necessary sometimes but not others?

Please help me understand this.

(Misc Info: I have UAC disabled, and I always run with Administrator privelege.  All the reg keys and values I wish to delete are in the "HKU/HKU64" or "HKCU/HKCU64" trees.)



Share this post

Link to post
Share on other sites

If the key/value in question is in both hives (64-bit and 32-bit), then yes you have to call RegDelete twice. Are you running 64-bit AutoIt or 32-bit? What key/value are you trying to delete?

Edited by zorphnog
  • Like 1

Share this post

Link to post
Share on other sites

If the key/value in question is in both hives (64-bit and 32-bit), then yes you have to call RegDelete twice. Are you running 64-bit AutoIt or 32-bit? What key/value are you trying to delete?


Thanks very much for your helpful reply, zorphnog !

I'm using the 64-bit version of AutoIt.

Although there are several different keys/values I want to delete (depending on the script), a typical key I want to delete starts at this path: HKEY_CURRENT_USERSoftwareNeoSoftToolsSystem ManagerCommonFileInfo

But all of the keys/values I want to delete are either in the HKU or the HKCU paths.

Now here's an additional question, if you don't mind:  In the help file for RegDelete(), there's the following statement: "When running on 64-bit Windows if you want to delete a key or value specific to the 64-bit environment you have to suffix the HK... with 64 i.e. HKLM64."

Could you please explain how I can tell whether a given registry entry is "specific to the 64-bit environment"? 


Thanks again for your help!

Share this post

Link to post
Share on other sites


Basically, if 64-bit software (or a 64-bit process) is what wrote the registry keys/values, then they'll be under the default HKLM, HKCU, HKU hives on a 64-bit Windows OS. If, however, it was 32-bit software (or a 32-bit process) that wrote the registry keys/values, then they'll be under the WOW64 (32-bit) sub-keys (i.e. HKLMSOFTWAREWow6432Node; HKCUSoftwareWow6432Node; etc.) on a 64-bit Windows OS. In my experience, you'll see this more under the HKLM hive than under the user-level hives (HKCU & HKU).

And if you don't know what bitness created/wrote to the registry, you'll just have to look in both places to see where they are located. Worst case, you can always code for both as a catch-all. However, I usually find out where they are actually located and code accordingly.

You can read more about this here:


And, you can find a comprehensive reference of what all is involved (including redirections) here:


Share this post

Link to post
Share on other sites

You could write a Function for example

Func RegDeleteBoth(...)


  StringReplace the first "/" to 64"/"

  RegDelete(replaced string)


So that can make you coding easier :)

  • Like 1

Share this post

Link to post
Share on other sites

Wow(64 ;)) -- What great and extremely helpful information!

Huge thanks to zorphnog, jguinch, Unc3nZureD, and especially TXTechie!

I'll close by briefly pointing out the source of my confusion that led to my OP.  If you look at these two posts (from 2008):

by Emiel Wieldraaijer, and by GEOSoft,

... you'll see some code that, if running on a 64-bit OS, would completely modify ALL registry key root strings to add the '64' suffix.  That led me to do the same thing in my own code.  I now know from the info you four provided me here that that approach was wrong from the start.

Thanks again for setting me straight!


Share this post

Link to post
Share on other sites

I am having the same issue. It's doing my head in. lol When I run the below it deletes the 64 bit entry but not the 32 bit entry. 

I am running Windows 7  64 bit


;Local $aArrayOfData = _Security__LookupAccountName(@UserName)

If @OSArch="X86" Then
ElseIf @OSArch="X64" Then

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

  • Similar Content

    • Iznogoud
      By Iznogoud
      I have created a script on my own computer for uninstalling and installing a specific customer application. For some reason it works great on my own computer, but i doesn't run at all at the customer his or her computer.
      I have a Windows 7 Professional - 64-bit machine and the first machine i have tested it at the customers location was a 32-bit machine, so ok, maybe that is the problem, but at an other computer with 64-bit it also doesn't work.
      So i installed AutoIT with editior on both machines, but a simple RUN command doesn't work.
      #RequireAdmin Run("C:\TEMP\Setup2010\setup.exe") With or without the RequireAdmin doesn't make a difference.
      Could someone help me to understand why my script works great on my own computer, but when you move it to another computer it doesn't work? If you compile it or not.
      Kind regards,
    • DCCD
      By DCCD
      Hi, is this the right way to use RegWrite func on 32-bit and 64-bit Windows
      $HKEY_CURRENT_USER = 'HKEY_CURRENT_USER64' If @OSArch = 'X86' Then $HKEY_CURRENT_USER = 'HKEY_CURRENT_USER' RegWrite($HKEY_CURRENT_USER & '\Software\Microsoft\Windows\CurrentVersion\Run', 'Obd2Diag', 'REG_SZ', 'app') Thanks in advance
    • Ascend4nt
      By Ascend4nt

      I/O Port Functions UDF
      Windows 7 and x64-compatible!

      This is a simple I/O (Input/Output) UDF for interacting with ports. The ability to write to ports was stripped from Windows with Vista+. While many do not miss this ability, there are some uses still in existence:
      Re-enable the internal PC Speaker - the good ol' "Beep" function can be restored using basic I/O PS/2 Keyboard Functions - Turn it off/on, mess with LED's, inject keys into the keyboard output stream - even thwart UAC prompts! =O Also work with Parallel, Serial (COM), PS/2 mouse, and miscellaneous ports that devices interface through using I/O operations For some good lists of ports and programming, see:
      PORTS.LST Chapters from 'The Art of Assembly Language':
      20: The PC Keyboards - Part One and Part Two 21: The PC Parallel Ports - Part One, Part Two, and Part Three 22: The PC Serial Ports - Part One and Part Two 23: The PC Video Display 24: The PC Game Adapter - Part One, Part Two, Part Three and Part Four On the PS/2 Keyboard and PS/2 Mouse, some more links:
      8042 Keyboard Controller 8042 Keyboard Commands & Responses Keyboard Controller Commands, Keyboard Commands and Keyboard Scancodes The PS/2 Mouse The I/O DLL's, which will install the I/O drivers (they are embedded as a resource in the DLL), come from Phillip Gibbons. His webpage, where more information, and extra downloads are, is available here: InpOut32 and InpOutx64. Note: everything you need is already included in my UDF.

      IOInstallx86 and IOInstallx64 are included to help with the install. Run these once to install the DLL's and drivers. (Administrator rights are required!)

      In addition to the base _IOFunctions UDF, I've included _IOBeep, which is based on trancexx's _Beep function, and _IOKeyboardFunctions [PS/2 only*]. There are now three examples of the UDF usage included: IOBeepExample, IOCMOSReadExample (based on trancexx's CMOS code), and IOKeyboardExamples. If anyone else has more code suggestions, feel free to add to the thread.
      *Update: Some BIOS's allow Legacy USB Port 64/60 Emulation, which may allow the _IOKeyboardFunctions to work for USB (non-PS/2) Keyboards, though this is untested thus far.

      While I bundle the binaries with my code, remember they are not my own. However, they are released as freeware. To ensure proper credit goes where it belongs, I've included the Readme files from the download (linked above), as well as a link to the original page.

      Ascend4nt's AutoIT Code License agreement
      Screw silly licenses.  Just make sure you remember the people you get free stuff from!
      - Updated to use (and install) v1.5.0.0 of InpOut32 & InpOutx64
      - Version check & compare before install
      - Fixed links
      - Tiny bug fixes
      InpOut32 and InpOutx64 ChangeLog:
      v1.5.0.0 New Build (20-Jan-2011):
      - Added _stdcall to DlPortReadPortUshort, DlPortWritePortUshort, DlPortReadPortUlong, DlPortWritePortUlong to maintain compatibility with old DLPortIO driver.
      v1.4.0.0 New Build (13-Jan-2011):
      - Removed references to WinRing0 which was discontinued.
      - Fixed uninitialized buffers & return from Inp32 > byte value!
      v1.3.0.0 New Build (15-Aug-2010):
      - Removed bool's from header (replaced with BOOL). This is to maintain compatibility with other DLL’s (DLPortIO etc.).
      Added _IOKeyboardFunctions UDF Added IOKeyboardExamples and IOCMOSReadExample (based on trancexx's CMOS code)