I changed my registry via C# with the following code:
RegistryKey regKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry32);
RegistryKey openSubKey = regKey.OpenSubKey(#"SOFTWARE\ASA\Suite", true);
openSubKey?.SetValue("Password", encryptedString, RegistryValueKind.String);
openSubKey?.SetValue("UserName", UserNameTextBox.Text, RegistryValueKind.String);
openSubKey?.SetValue("DomainName", DomainNameTextBox.Text, RegistryValueKind.String);
openSubKey?.Close();
regKey.Close();
These entries did already exist and were only replaced. When I use the same kind of code to read the settings I get the correct settings back, BUT when I open the registry with regedit.exe and search for it manually I find only the old values. In the regedit.exe it is this path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ASA\Suite
I already looked into the path without WOW6432Node (and even in the HKCU) but there is no ASA entry at all.Has someone an idea what that could be? Why don't I see the changes I made? I am completly puzzled here...
EDIT: I changed my project from anyCPU to x86 and no change, but as soon as I changed it to x64 the keys read were the ones that regedit.exe shows. But I open the 32bit variant of the registry hive, and when I write something here the question persists... why can't I see the changes made? A x86 app under x64 Windows should automatically write to the WOW6432Node, shouldn't it?
EDIT2: I tested the x86 version on an x86 Windows. I change the registry and can read it, but with regedit I cannot see the changes... wtf is this?
EDIT3: I found the changed keys under HKCR\VirtualStore\MACHINE\SOFTWARE\ASA\Suite I don't know why yet, but I search for an answer and post it here.
May be somebody else is overwriting it ?
May be this can help?
http://www.advancedinstaller.com/user-guide/registry-wow6432-node.html
The Wow6432Node registry entry indicates that you are running a 64-bit Windows version.
The operating system uses this key to display a separate view of HKEY_LOCAL_MACHINE\SOFTWARE for 32-bit applications that run on 64-bit Windows versions. When a 32-bit application writes or reads a value under the HKEY_LOCAL_MACHINE\SOFTWARE\\ subkey, the application reads from the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\\ subkey.
A registry reflector copies certain values between the 32-bit and 64-bit registry views (mainly for COM registration) and resolves any conflicts using a "last-writer-wins" approach.
Ok, I have the answer. I didn't wanted to use a manifest so I removed it and thus didn't got asked if the app had to be elevated. So, because a normal user (even if the logged in user had admin rights) can't write to the HKLM, it wrote a key to HKCU\VirtualStore... that way my app could also read the keys but in the regedit.exe it was not where it was expected.
To get around this I implemented a manifest and changed the line with the requestedExecutionLevel:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Now I don't even have to build an x64 and an x86 version but can use Any CPU instead and let my app do the work (i.e.: to look if to use the RegistryView.Registry32 or RegistryView.Registry64)
Related
Can anyone tell me why I can't access the registry key of "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData"?
if I query the GetSubKeysNames of "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer" it only returns one value being "Secure" ----> Where are all the other subkeys?
Thanks.
High odds that you are running your program on the 64-bit version of Windows and it is forced to run in 32-bit mode. The registry redirector will make you actually read the keys in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. And yes, that one also has a Microsoft\Windows\CurrentVersion\Installer key but it is pretty empty. Use Regedit.exe to compare.
The simplest fix is to remove the forcing. Project + Properties, Build tab, set the Target platform setting to AnyCPU. If you have VS2012 and up then untick the "Prefer 32-bit" option. Repeat for the Release configuration. If you must run in 32-bit mode then you can use the .NET 4+ RegistryKey.OpenBaseKey() method, passing RegistryView.Registry64.
I've created a WPF Window with a lot of buttons, each of them run a different program. To run MS Word, for instance, I used:
System.Diagnostics.Process.Start("C:\\Program Files (x86)\\Microsoft Office\\Office14\\WINWORD.EXE");
But when I try to run the Windows 7 Snipping Tool the same way it doesn't work. It was supposed to be like this:
System.Diagnostics.Process.Start("C:\\Windows\\System32\\SnippingTool.exe");
I'm sure the path is correct, but always appears a message saying the file wasn't found. I would like to know why is this happening.
Important: I use Windows 7 64 bits.
Use this:
// if the build platform of this app is x86 use C:\windows\sysnative
if(!Environment.Is64BitProcess)
System.Diagnostics.Process.Start("C:\\Windows\\sysnative\\SnippingTool.exe");
else
System.Diagnostics.Process.Start("C:\\Windows\\system32\\SnippingTool.exe");
The problem is in your build platform (x86) and the automatic redirection of the folder C:\Windows\System32\ on 64-bit OS'es.
Basically, for several reasons, in vista/windows 7 64-bit OS'es when a 32 bit application try to access to C:\Windows\System32\ it is automatically redirected to the folder called C:\Windows\SysWOW64\. Hence, you cannot start snippingtool.exe because it is not present in that folder.
The only way is to use C:\Windows\sysnative\ and bypass the redirection.
My psychic debugger tells me that you are running a 32-bit program on a 64-bit version of
Windows, so your call to %WINDIR% (C:\Windows) is actually being re-routed to C:\Windows\SysWOW64.
Use the environment variable instead of hard-coding paths to directories that may move around depending on the environment and/or Windows version..
You should use an environment variable instead. Likely you are running it on a 64 bit system and C:\Windows\System32\ is getting redirected.
I'm writing a .NET 4.0 based ActiveX control for IE7+. I have to manage an interface with a key-reader device. I followed some great tutorials and articles about "how to do" it, and currently is working well.
My problems started when I wanted to deploy an other version of my control.
I'm using VS2010 with setup deployment project and cabarc for the .CAB. The 1.0.0.0 version went well. Currently I would like to get the 1.0.2.0 version working, and it is doing its job well, but IE always prompting for an install. Again and again.
What I did:
1: Changed the AssemblyInfoVersion.cs to version 1.0.2.0
2: Changed the .inf file according version to 1.0.2.0
3: Changed the .msi version to 1.0.2
And I changed the OBJECT tag in the HTML page to #version=1,0,2,0
So far so fine. It is installed! I can see it under the "Uninstall Programs", the version of the control is 1,0,2 ! Great, but the IE still wants me to donwload and install it every time when I open the page.
I saw a thread connected with Excel: How to get COM Server for Excel written in VB.NET installed and registered in Automation Servers list?
And I got usefull information about I should change something in the registry. I did some search there, and I fould my classId under :
HKLM\SOFTWARE\Wow6432Node\Classes\CLSID{GUID}
I have here the following subkeys:
InstalledVersion
Implemented Categories
InprocServer32
ProgId
I was happy, because I saw, that in the InstalledVersion part the version still 1,0,1,0. I changed it to 1,0,2,0 and... it did not worked. I serched through the registry, now everywhere the InstalledVersion is 1,0,2,0. The .dll version is 1,0,2,0. The installed control's version is 1,0,2. Under the InprocServer32 I have all three 1,0,0,0 ; 1,0,1,0; 1,0,2,0 versions. And of course in the HTML code the version is also 1,0,2,0.
(My machine is 64 bit Win7, IE9)
Could anybody help in this, what I missed?
Other problem with this whole scenario: After the version increase by the first install my dev machine is rebooting without any question. Do you have any idea what kind of settings can make this behavior?
UPDATE:
The problem solved. I'm kind of blind or just a bit tired because of this.
But the problem is may important for the future:
First a summary about the issue:
After a new version was deployed (installed well on client) the IE was always propting for install the version.
The problem source is in the registry. You should have the rigth version number in the InstalledVersion(Default) registry key.
I had a very special case here (and I don't know the cause yet), but I had two entries with (Default) under the SubKey InstalledVersion. The firs one was empty, the second one contained the rigth value. I could not delete the first one, but the second one only. After I changed the first (Default) everything worked find!
The second problem with the automatic restart solved too.
This thread helped: MSI installer with Silent or Passive mode will automatically restart computer without prompt for user sometimes
Have to add the /qn /norestart or /promptrestart to end of an msiexec call, because without this flag the windows automatic restarts itself without questioning.
If somebody has a similiar issue, then here is the solution in my case:
[RunSetup]
run="""msiexec.exe""" /i """%EXTRACT_DIR%\KeyReaderEngineInstaller.msi""" /qn /promptrestart
According to Microsoft Documentatation:
/promptrestart
Prompt before restarting option. Displays a message that a restart is required to complete the installation and asks the user whether to restart the system now. This option cannot be used together with the /quiet option.
You can either use /qn /norestart or just /promptrestart. In my case, just the IE had to be restarted, instead of the whole operational system. Therefore, I use /qn /norestart
I am attempting to make an updater program, that when updates it writes a build number into the windows 7 registry which the main program reads when checking for updates. I've gone through the UAC virtualization kb at microsoft's page, and have found nothing. My app.manifest has
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
and yet, when i look in HKEY_Local_Machine\Software the build entry is not there, i dont even see it in HKEY_USERS\_Classes\VirtualStore\Machine\Software either.
the code i'm using to enter into registry is
Registry.LocalMachine.CreateSubKey("SOFTWARE\\build");
RegistryKey myKey = Registry.LocalMachine.OpenSubKey("SOFTWARE\\build", true);
myKey.SetValue("build", "3", RegistryValueKind.String);
any ideas/suggestions?
If your application is targetting x86 platforms, when running on an x64 system, it will use the corresponding registry node with the following names:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ or HKEY_CURRENT_USER\SOFTWARE\Wow6432Node.
So, if you set platform target to x86 for your build, on x86 systems it will go under HKEY_LOCAL_MACHINE\SOFTWARE whereas on x64 systems it will go under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node which is a reserved node for applications running on WOW64(Windows 32-bit on Windows 64-bit) mode.
For more information see Registry Reflection
Is there some way to create a custom (WoW64) shared registry key?
By default some registry keys are shared and others are redirected (see MSDN). But I want to create a custom registry key under HKLM\Software which should be shared. I'm looking for a solution in C# (maybe P/Invoke) and WIX.
If you add the KEY_WOW64_32KEY flag to RegCreateKeyEx (or RegOpenKeyEx) you will always access the 32 bit registry.
I couldn't find this flag (nor KEY_WOW64_64KEY which is the same but for 64bit access) in the Wix source code, so you might need to use pinvoke.