I wrote a COM Dll for explorer that extends windows context menu, registration via regsvr32 works fine on 32 bit Windows, but on 64 bit it does not work without any clue. regsvr32 reports successful registration, although Dll is not working. I tried to call regsvr32 from SysWow64 directory aswell as from system32 and this is not the cause as far as I can guess. Checked the registry - everything was written to the registry to wow3264Node ofcourse (as installation was on 64 bit OS). Still nothing happens. Hard to provide any specific information for now. Can anyone suggest or point to other possible causes of such behavior. Thanks in advance.
You need to compile your DLL for 64 bit. The fact that the registration code writes to Wow6432Node indicates that your DLL is 32 bit. On a 64 bit OS, Explorer is a 64 bit process and so can only load 64 bit shell extensions.
Don't forget to register both 32 and 64 bit versions of the shell extension on a 64 bit machine so that any 32 bit programs can see your shell extension. You do that using C:\Windows\SysWOW64\regsvr32
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 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
I'm about to do a clean get of 32 bit source code onto my new Windows 7 64 bit machine. Is there anything special I need to do (switch to 32 bit mode, etc) or will Windows detect this and adapt accordingly?
The "bitness" of the operating system has nothing to do with getting source code. Your IDE determines what the target is of your compile of the source code, and most IDEs now can target either.
In other words, Windows doesn't have to do anything, and neither do you. Your development environment uses the source code, and determines what happens with it. Windows has absolutely nothing to do with it, except to run any resulting executable that's produced if it's compatible with that version of Windows. (And Win64 runs 32-bit applications just fine.)
Just as a note: You can't "switch to 32-bit mode" with a 64-bit operating system. It's always going to be a 64-bit operating system, even if you're running a 32-bit application. The application may not know it's running on a 64-bit OS, but it will be despite it's ignorance of that fact. :)
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
I ask because I noticed that many 64 bit EXEs link against what appear to be 32-bit DLLs.
For example, my 64 bit MFC app links against user32.dll, urlmon.dll, wininet.dll - all of which are 32 bit DLLs that reside in windows\system32.
So is this some MS specific wizardry that applies to these DLLs, or is there backward compatability, as it were, for 64 bit EXEs that need to use legacy 32 bit DLLs?
You cannot link 64-bit EXEs to 32-bit DLLs or vice versa. On a 64-bit Windows OS, the DLLs in Windows\System32 are actually 64-bit DLLs. The 32-bit versions are in Windows\SysWow64.
Call 32 from 64, Sure It can. (In windows this is called WOW wich means Windows on Windows). But, viceversa It doesn't work.
Here you have the explanation of how:
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
Hope it serves.
The latest version of Dependency Walker (found here: http://www.dependencywalker.com/) fixes this issue. It finds the correct DLLs, and avoids the inaccurate errors.
(I'm late to the party, but google still found this question when I had a similar problem.)