I have a 32-bit application and a 32-bit installer, written in Wise Installation Studio. I know...I shouldn't be using Wise and I should switch to something else. But for now, I'm stuck with it.
Our application is graphics-intensive and to improve performance, we want it to disable desktop composition (Windows Aero) while running. We accomplished this on 32-bit systems by adding a registry entry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
with a value of DISABLEDWM.
This sets the "Disable desktop composition" checkbox in the compatibility tab of the properties for our EXE to be checked by default.
This works perfectly on 32-bit systems, but when running the installer on a 64-bit system, Windows redirects the creation of registry entries to HKLM\SOFTWARE\Wow6432Node, and the flag is not set correctly. If I manually create an entry in the 64-bit registry view, then it works.
So how can I force this registry key to be created in the 64-bit registry view from our 32-bit installer? Or is there a better way to set this property aside from creating a registry entry?
I'm not sure what possibilities Wise gives you regarding scripting, but the way to access the 64-bit registry from a regular program is to use KEY_WOW64_64KEY when manipulating the registry.
If it's a possibility to at the least run an external EXE file from the setup, it should solve your problem.
I am not sure if this solution was possible at the time this question was asked, but you can create a custom action that executes a REG ADD command and include the /reg:64 switch, like this:
REG ADD "HKLM\Software\Example" /v "Name" /t REG_SZ /d "Data" /reg:64
The /reg:64 switch will force it to the 64-bit registry. I am not entirely sure what this will do on a 32-bit system, but I expect it will probably be ignored.
Usually you can not access the 64 bit registry from 32 bit applications. I have found some code, which is for PowerShell, that allows you to access the 64 bit registry through WMI: http://gallery.technet.microsoft.com/scriptcenter/6062bbfc-53bf-4f92-994d-08f18c8324c0
However, I'm not sure whether you can use this in Wise. You could use Windows Installer XML instead and have it create a 64-bit MSI.
I also use Wise and have to support both 32 and 64 bit windows. I have had some success using batch files to call reg.exe to delete and query 64 bit registry entries. You should be able to employ the same technique to add and modify the registry. I look for "program files(x86) to determine if it is 64 bit windows. If not, I use the native registry controls in wise, otherwise, I use the batch files with passed in parameters. Reg.exe should be in your path. go to a dos prompt and type reg /? to get the syntax.
I have a regtest.bat, which contains the following:
reg.exe query %1 /v %2 > %3
The first param is the registry key, second is the value, and third is the text file it is written to.
My regdelete.bat contains:
reg.exe delete %1 /f The param is the registry entry you want to delete.
The problem still exists although query registry with Reg.exe
Because when the bat file called by Wise, the reg query can not find 64 bit key(only 32 bit key can be found).
You could also use
c:\Windows\SysNative\REG.exe ADD "HKLM\Software\Example" /v "Name" /t REG_SZ /d "Data"
This forces the use of the 64-bit version of reg.exe. Of course, that's not going to work if you're on a 32-bit OS. So you should put in a check for the OS type, and then call the proper reg.exe program (either c:\Windows\System32 for 32-bit OS, or C:\Windows\SysNative for 64-bit OS).
The environment variable PROCESSOR_ARCHITEW6432 will have the value of AMD64 if it's a 64-bit OS, and empty if 32-bit OS.
Related
I have a batch file that copies a directory to a new location, creates 2 other .bat files, 2 .json files, and Inserts Registry Keys. When running the batch script for the command line, I get no errors and all desired outcomes. While running it from the post-build event command-line, I get no errors, but I'm missing the Registry entries. Co-worker suggested that this could be due to Visual Studio not having Admin permissions whereas the command line can. My question is: is there a way (without running Visual Studio as an admin) to elevate permissions for a post-build event? If you're wondering why not just run VS as admin, it's because this solution is shared via TFS, and not all my co-workers will know to run their instance of VS as admin for this one particular solution. I've Googled away with nothing to show for it. Thanks in advance for help! Here's the Post-build event command line I'm using. Again I know it works... it just doesn't plop the Registry values. CMD does. PS. Using VS 2013 on Windows 7
if $(ConfigurationName) == Debug call "$(ProjectDir)BatchFiles\DebugHelper.bat" "$(TargetDir)" C:\CEC\Batch\Test\
This is from Windows SDK about redirection (there is also reflected and shared)
Registry Redirector
The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of key portions of the registry on WOW64. The registry redirector intercepts 32-bit registry calls to each logical registry view 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.
Redirection is enabled for the following registry keys:
HKEY_LOCAL_MACHINE\Software
HKEY_USERS\*\Software\Classes
HKEY_USERS\*_Classes
Note * indicates a match for all user security IDs (SID).
The following scenario illustrates the use of these logical views:
A 32-bit application checks for the existance of the following registry key: HKEY_LOCAL_MACHINE\Software\Hello. If the key does not exist, it creates it with a default value of "Hello 32-bit world"; otherwise, it reads and displays the value.
The same application is modified to write "Hello 64-bit world" instead of "Hello 32-bit world" and recompiled as a 64-bit application.
When the 32-bit application is run on 64-bit Windows, it displays "Hello 32-bit world". When the 64-bit application is run, it displays "Hello 64-bit world". Both applications call the same registry functions with the same predefined handle and the same key name; the difference is that each application operates on its logical view of registry, and each view is mapped to a separate physical location of the registry, which keeps both versions of the string intact.
To help applications that write REG_EXPAND_SZ keys containing %ProgramFiles% to the registry, WOW64 intercepts these writes and replaces them with "%ProgramFiles(x86)%". This environment variable is defined for all processes. For example, if the Program Files directory is on the C drive, then "%ProgramFiles(x86)%" expands to "C:\Program Files (x86)".
To enable application interoperability through COM and other mechanisms, WOW64 uses registry reflection, which copies specific registry keys and values between the two registry views to keep them in synch. The reflector is intelligent and copies COM activation data for Local servers between the views, but not in-process data, because 32/64 in-process data mixing is not permitted on 64-bit Windows.
What to do
In a program
KEY_WOW64_64KEY 0x0100 Access a 64-bit key from either a 32-bit or 64-bit application.
Windows 2000: This flag is not supported.
KEY_WOW64_32KEY 0x0200 Access a 32-bit key from either a 32-bit or 64-bit application.
Windows 2000: This flag is not supported.
From command prompt see reg flags /? allowing your key to opt out of redirection.
And a reminder that UAC also may be virtualising it. As it redirects some writes to HKLM to HKCU. Giving permission for users to write to your key will overcome that.
Can I set up a 64-bit registry key to refer to a 32-bit program files path using WiX?
I'm writing a plugin for another piece of software. I want my plugin dll to go in C:\Program Files (x86)\MyPlugin\MyPlugin.dll not in C:\Program Files\MyPlugin\MyPlugin.dll because the dll is 32-bit, not 64-bit.
However, I need the registry key to go in HKLM/Software/Company/Product/Etc.... not in HKLM/Wow6432Node/Software/Company/Product/Etc.... because the process that actually reads the registry key is 64-bit. That 64-bit process reads the registry and launches a 32-bit process to sandbox the dll.
Is there any way to do this? I've tried using different components with different Win64 attribute values, and even putting them in separate component groups. However, I keep getting these build errors (not warnings):
ICE80: This 64BitComponent RegistryComponent uses 32BitDirectory INSTALLFOLDER
A somewhat poor solution, but you could just a custom action to add registry entries, if you don't mind them sticking around after an uninstall.
If you write a custom action in C# you can just do something like this:
using (var hklm = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
{
// do it
}
If you support 32-bit and 64-bit machines you need two separate MSI setups:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
So your 32-bit install creates any COM entries for any 32-bit Clients and the 64-bit setup has 32-bit and 64-bit components that write to the registry.
http://msdn.microsoft.com/en-us/library/aa367451(v=vs.85).aspx
A rather easy solution to only have one installer version for 32 and 64 bit is to export a .reg file with the keys you want to add (from regedit) and then run a custom action during install, ie:
<CustomAction Id='Add_Registry_Keys' Execute='deferred' Directory='DriverDir' Impersonate='no' ExeCommand='regedit.exe /s "[DriverDir]default.reg' Return='ignore' />
You can suppress ICE errors also, not just warnings. This means you can use Win64 attributes in your x86 msi.
The setting to ignore ICE validations is found in the Project Properties under the Tool Settings tab.
It might not be recommended, but if it works its still better than the alternative of a custom action.
I am using REG QUERY HKLM/SOFTWARE command to retrieve all installed soft wares,
but its not returning few of applications, what ever the application I needed is a 64 bit one.
OS:- Windows 7
Note:- When I use the command its returning the applications which are under [Wow6432Node] folder, but my application is not presented under this folder. Its present under [HKLM/SOFTWARE] location
Please help me to solve this problem.
This behaviour is due to the registry redirector. You are running the 32 bit version of REG, presumably because the process that invokes it is a 32 bit process. And so the 32 bit version of REG reads the 32 bit view of the registry by default.
You should use /reg:64 switch to force reg to use the 64 bit view of the registry, as described here: MS-KB-948698.
If you are doing this from a program then it's better to use the registry API to read entries than using the REG tool.
I set up the registry key, HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps as described on MSDN.
I have a test program - a console program, compiled with Visual C++, that tries to dereference a NULL pointer before printing a message and exiting. The test program used to exit and dump a core file, but now it just exits. I get no core.
I'm running Windows Server 2008 R2 Enterprise, SP1 on physical hardware.
I don't know what changed. What could have changed that prevents WER from dumping cores now?
The following may go wrong:
Permissions of the folder to write to
Looking at the permissions of the folder C:\ProgramData\Microsoft\Windows\WER it has
Read & execute
List folder contents
Read
Creating a subfolder LocalDumps will inherit the permissions.
So you should either modify the permissions of that folder or use a different folder with write permissions.
Permissions of the Registry key
Windows might not be able to read the Registry settings if the permissions do not allow it. E.g. the following (really silly) permissions will prevent a LocalDump as well:
32 vs. 64 bit
Windows Error Reporting is executed by Windows and only uses the registry key with the bitness of the OS. You said you set up both. If that's true, it`s fine. If you only set up the 32 bit Registry key, it won't work.
AeDebug
If you have a setting for AeDebug HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug, those are executed before WER.
Note that this entry may exist in 32 bit (WOW6432Node) and 64 bit.
Usually that should result in starting a debugger, but who knows ... it might do nothing and just exit.
LocalDumps is disabled
Make sure that there is no DWORD Disabled with a value of 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Use of REG_SZ instead of REG_EXPAND_SZ
I have seen people using a REG_SZ for DumpFolder in combination with %APPDATA%. Only REG_EXPAND_SZ will expand environment variables.
Make sure you've added a key on the LocalDumps node like "LocalDumps\MyApplication.exe". Then, update the values that are explained in that link. At the time of a crash, WER looks for a key with the matching application name to decide how to handle the dump.
Within VB6 I have used the following code to add to Registry,
Dim x As Object
x = CreateObject("WScript.Shell")
x.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell", "MADNESS"
It creates a key, however in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
Instead of:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Any help is appreciated.
It looks like it's because you have a 64-bit OS and you're running a 32-bit (x86) application which is handled by Windows'"Windows On Windows" (WOW) feature. Basically, it allows you to run an x86 program on an x64 Windows OS. x86 programs usually have their own registry key structure (ie. the Wow6432Node) and their own program files folder (ie. Program Files (x86)). You can try using something like this which uses WinAPI hooks. This may allow you to bypass the issue and write directly to the key you want. Though, I'm not sure if Windows has security measures in place that prevent x86 applications to write to x64 parts of the registry. (I can't see why it would.)
You can shell C:\Windows\System32\cscript.exe which is the x64 version.
FYI: The x86 version is C:\Windows\SysWOW64\cscript.exe
First off, I would stop using WScript.Shell and switch to this registry access class: http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=70915&lngWId=1
It's a little confusing to use at first, but it's solid and provides built-in support for accessing 64-bit registry entries rather than the re-directed Wow6432Node. You can do so simply by setting the desired access in the .Path method of the class. Here's an untested example:
Dim objRegistry as New UniRegistry
Dim objHKLMStartup as New UniRegistry
Set objHKLMStartup = objRegistry.Path([hKey Local Machine], "SOFTWARE\Microsoft\Windows\CurrentVersion\Run", [Registry: Read] + [Registry: WOW64 64-bit])
You can then use a For Each variant In objHKLMStartup to extract any/all values in the given registry path.