I am currently trying to get a list of all autoruns, but I am struggling on a 64-bit system. When I use:
My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\Microsoft\Windows\CurrentVersion\Run", False)
It shows me entries from:
My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run", False)
Anyone know why and/or how to fix this?
I should also state that the items in HKLM\..\Run are different to those in HKLM\..\Wow6432Node..\Run.
Your process is a 32 bit process and so, on a 64 bit OS, the registry redirector comes into play. The HKLM\Software key is redirected and there are two views of it, a 32 bit view that your process is finding, and a 64 bit view.
It is true that if you run a 64 bit process, you will see the 64 bit view of the registry. However, that is not the full story. Windows processes CurrentVersion\Run entries from both 32 and 64 bit views of the registry. So, if you just switched to an x64 or AnyCPU process you would then be missing the autoruns stored in the 32 bit registry view.
So, since your goal is to list all the autoruns, you will need to read both 32 and 64 bit views of the registry. You can do that using the RegistryView enumeration that was introduced in .net 4. This allows a 32 bit process to access the 64 bit view of the registry. And indeed it allows a 64 bit process to access the 32 bit view of the registry.
If you want a process that runs on both 32 bit and 64 bit systems you will need to target either x86 or AnyCPU. And then use RegistryView to read both views of the registry if you detect that you are running on a 64 bit system.
That's happen because your application is compiled for x86 platform and running on a 64bit operating system. There is a comprensive article on Registry Redirection on MSDN
The registry redirector isolates 32-bit and 64-bit applications by
providing separate logical views of certain portions of the registry
on WOW64. The registry redirector intercepts 32-bit and 64-bit
registry calls to their respective logical registry views and maps
them to the corresponding physical registry location. The redirection
process is transparent to the application. Therefore, a 32-bit
application can access registry data as if it were running on 32-bit
Windows even if the data is stored in a different location on 64-bit
Windows
You could fix the problem compiling your application for AnyCPU platform
Related
I'm running 64 bit version of Windows 8.1
Times ago I developed a win32 application that creates and access some keys in the windows registry, in a path like:
HKEY_LOCAL_MACHINE\SOFTWARE\MY_SOFTWARE
Today, in the 64 bit world, I've seen that without doing any changes in the source code, my old 32 bit application creates and access the same keys in a new path:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MY_SOFTWARE
Thanks to a redirection done by the system, with complete transparency from an application point of view.
If I compile my application to be a 64 bit software, will it write under a "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6464Node\MY_SOFTWARE" node or back to the standard node "HKEY_LOCAL_MACHINE\SOFTWARE\MY_SOFTWARE" ?
Since these keys are accessed by other applications (third party applications both 32 and 64 bit), should I write the keys both in
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MY_SOFTWARE and HKEY_LOCAL_MACHINE\SOFTWARE\MY_SOFTWARE
paths so that both 32Bit and 64Bit external applications can see them?
I'm trying to debug a 32 bit program on 64 bit Windows 7.
So I use gflags to set the debugger for that app. I fill in the path of the application, and the one of the debugger. But when I start the application, WinDBG doesn't run.
The same configuration works on 32 bit Windows 7.
So, is it impossible to debug a 32 bit application on 64 bit environment?
For me this has always worked, even if I use the "wrong" architecture gflags.
However Windbg must be in the PATH, or you must include path when you specify the debugger to gflags.
UPDATE
This is an old question. Older versions of gflags used to store the settings in one of the locations:
HTML\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
or
HTML\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Depending on which architecture you pick for gflags.exe, it will affect either 64 bit or 32 bit processes.
Apparently at some point (thanks, #Thomas Weller to point it out), Microsoft changed gflags behavior and now (November 2016) current version of gflags.exe writes to both 32-bit and 64-bit registry locations, irrespective of the architecture.
This is a bit of a problem, because I used to use to attach 32-bit debugger to 32-bit processes and 64-bit debugger to 64 bit processes with the same process name. Now I cannot use gflags for this. However the workaround is to directly modify registry keys under Image File Execution Options.
Old Answer
Processor architecture of gflags.exe actually matters. If you use 64-bit version of Windows Debugging tools and launch gflags.exe from there, it will affect behavior of 64-bit applications. Similarly, if you use 32-bit version of Windows Debugging Tools and launch gflags.exe, it will affect 32-bit applications.
32-bit and 64-bit versions could be installed side-by-side. Pay close attention on bitness of application you are debugging and use the same architecture of the debugger/tools.
Apart from the MSDN reference, I want to know what these keys do? Does KEY_WOW64_32KEY means that a 32-bit app on x64 OS will access the WOW64 Registry Tree ? And does KEY_WOW64_64KEY means that a 32-bit app on x64 OS will access the normal Registry Tree and not the WOW64 Registry Tree ? What if I have to access some keys which I do not know whether lies in the WOW64 or normal Registry Tree ?
KEY_WOW64_64KEY on a 64-bit OS means that the registry access, no matter if it's a 32 or 64 bit process, will access the 64 bit registry view.
KEY_WOW64_32KEY on a 64-bit OS means that the registry access, no matter if it's a 32 or 64 bit process, will access the 32 bit registry view.
Neither of them have any effect on a 32-bit OS.
Leaving the flag out (the default) on a 64-bit OS will send registry accesses from 32-bit processes to the 32 bit registry view, and accesses from 64-bit processes to the 64 bit registry view.
For more info, this reference page at Microsoft should tell the whole tale.
From the linked reference:
For more information, see Accessing an Alternate Registry View.
Which says:
KEY_WOW64_64KEY: Access a 64-bit key from either a 32-bit or 64-bit application.
KEY_WOW64_32KEY: Access a 32-bit key from either a 32-bit or 64-bit application.
Here's my scenario: the company I work has applications deployed to a 32bit Windows 2003 server and they want to move to a Windows 2008 Server that is 64 bit. It has been noted that these 32bit custom developed applications will not run on a 64 bit machine. I was not aware of this.
I have always thought that 32bit software CAN run on a 64 bit OS and just use the 32bit address. A 64 bit software on the other cannot run on a 32 bit OS. On a 64 bit, one does have to create 64 bit software but can and still also create software that is designed for 32 bit machines.
Can someone please elaborate on this?
In general, 32-bit applications will run under a 64-bit Windows (This is technically called WOW64 - Windows On Windows). This applies to all 64-bit Windows version to date, including Server.
WOW64 processes are marked in task manager with *32, For example: chrome.exe *32. Sysinternals' Process Explorer has a separate column for this: Image Type (64 vs 32-bit).
If the app has components hosted inside other processes, then those components must accommodate processes they're hosted in. Examples:
Shell extensions are hosted in explorer.exe, whose bitness matches the OS' bitness. Therefore, you should compile the extension in both 32- and 64-bit, and register the one matching the OS' bitness during installation.
Kernel-mode driver are hosted in the Kernel, whose bitness also matches the OS' bitness. So, the above applies.
Winsock LSPs (Layered Service Providers) are hosted in all processes, both 64-bit (native) and 32-bit (WOW64). Therefore, you should compile the LSP in both 32- and 64-bit, and register both in their respective catalogs during installation.
There are also considerations regarding file redirection (System32 / SysWOW64 / SysNative) and registry redirection (Wow6432Node), which I will not go into.
In general, 32-bit applications will run under a 64-bit OS. If your app relies on a 32-bit kernel driver (say, a VPN client), then you will have to port to 64-bit.
I know that with Vista you can generate a dump file by goigg to task manager->processes-> right clicking on the process.
Is this option available in other versions of windows meaning Windows 7, Windows 2003, Windows 2008 etc?
It is available in Windows 7 and 2008, but I don't know about Windows 2003. One thing to keep in mind is that on a 64 bit version of Windows, there are actually two versions of Task Manager - one 32 bit and one 64 bit. If you use the 64 bit, you'll get a 64 bit dump, even if the process is 32 bit. I.e. you'll get all the Wow64 in the process as well. However, if you use the 32 bit version of Task Manager, you'll get a 32 bit dump without the Wow64 stuff. The latter is significantly easier to debug as the abstraction layer isn't present in the dump.
To collect a 32 bit dump, by opening a 32 bit task manager found at C:\Windows\SysWOW64\taskmgr.exe
Check in process explorer that it has a (32) to it