wow64

I've got a python program which is supposed to clean up a number of directories and one of them is C:\windows\system32\inetsrv\metaback ; however, os.path.exists() returns False on that directory even though it exists (and I have permissions to access it). What's interesting also is that the tool windirstat completely misses it as well. Can anyone think of a reason why this might be and what's another way I could check to see if it exist? I can't even seem to run os.listdir() on it. Update: os.path.exists() works on this directory if the Windows box is 32-bit, but not if it is 64-bit. Also

i have injected my DLL into process and i try to scan memory for addresses with same value as mine, but it results in a crash after i get 1st address , it should be 10 addresses for(DWORD i = MEM_START; i< MEM_END ;i++) { VirtualQuery((void*)i,pMemInfo,sizeof(MEMORY_BASIC_INFORMATION)); if(pMemInfo->AllocationProtect == PAGE_READONLY || PAGE_EXECUTE_WRITECOPY || PAGE_READWRITE || PAGE_WRITECOMBINE) { if(*(DWORD*)i==1337) { addresses.push_back(i); } } } I believe my protection check is wrong but not quite sure. virtual memory scanner MEMORY_BASIC_INFORMATION mbi = {0}; unsigned char *pAddress =

I have written a simple Java class to generate the hash values of the Windows Calculator file. I am using Windows 7 Professional with SP1 . I have tried Java 6.0.29 and Java 7.0.03 . Can someone tell me why I am getting different hash values from Java versus (many!) external utilities and/or websites? Everything external matches with each other, only Java is returning different results. import java.io.File; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.util.LinkedHashMap; import java.util.Map; import java.util.Map.Entry; import

this code insert the registry value Microsoft.Win32.RegistryKey key; key = Microsoft.Win32.Registry.LocalMachine.CreateSubKey("SOFTWARE\\Microsoft\\Internet Explorer\\MAIN\\FeatureControl\\FEATURE_BROWSER_EMULATION"); key.SetValue("MyBrowser.exe", 8000); textBox1.Text = key.GetValue("MyBrowser.exe").ToString(); key.Close(); in windows 32 bit work, but in 64 bit is inserted to wow6432node how to disable the redirect? You need to open the key using RegistryView.Registry64 . You specify this in the OpenBaseKey method so you'll need to rejig your code a little. RegistryView is available only on

I'm trying to run the Windows System Assessment Tool (winsat.exe) using the following code: System.Diagnostics.Process WinSPro = new System.Diagnostics.Process(); System.Diagnostics.ProcessStartInfo WinSSInfo = new System.Diagnostics.ProcessStartInfo(); WinSSInfo.FileName = "cmd.exe"; WinSSInfo.Arguments = "/k winsat.exe"; WinSPro.StartInfo = WinSSInfo; WinSPro.Start(); This code works if I only call cmd.exe, and even if I call regedit.exe it still works. However, when I try to call winsat.exe as a argument of cmd.exe, it fails. The command prompt shows this: 'winsat.exe' is not recognized as

Our 32-Bit application launches Windows LNK files (Shell Links) via ShellExecute. When it tries to "launch" a link to a 64-Bit binary (such as the "Internet Explorer (64-Bit)" shortcut in Start Menu) it always ends up launching the 32-Bit binary. Internally, ShellExecute incorrectly resolves the link target: There's a hidden field inside the LNK which holds FOLDERID_ProgramFiles. A 64-Bit app resolves this to the 64-Bit Program Files directory, but a 32-Bit app won't. Wow64DisableWow64FsRedirection does not change this behavior of ShellExecute. Besides going through a 64-Bit "trampoline"

I originally designed a win32 application on win7 32bits, with VC9.0. I recently upgraded to win7 64 bits, and tried to build+execute the previous application. Building runs fine (win32 application), but on runtime I get the error "[...] has exited with code -1073741701 (0xc000007b)." I guess this results of the loading of a 64bits version of an [intended] 32bits dll. Specific dependencies for this project are: SDL.lib SDLmain.lib SDL_ttf.lib opengl32.lib glu32.lib wininet.lib SDL and SDL_ttf are only in 32bits version. I assume that Visual Studio is clever enough to fetch the opengl and glu