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
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.
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 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
I was wondering if its possible to detect if a costumer's Windows is 64x or 86x based via Director. The reason for this is that some Xtras don't work as intended when running on a 64x windows, and I wanted to create 2 versions of my program for better compatibility.
If possible, I wanted a code based solution, with no other program involved other than Director.
You can try using BuddyAPI and the baVersion( "Wow64" ) code.
this will return 1 if running as a 32 bit application under 64 bit Windows. Since projectors are only 32 bit applications, this will be true if Windows is 64 bit. It will return 0 if running under 32 bit Windows.
baVersion ("64Bit" ) will return 1 if running under a 64 bit processor, regardless of the Windows version.