Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, November 16, 2010 9:53 PM
I have a windows service written in c#. When I install the service I want to remove a registry entry. So I Microsoft.Win32.Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows\CurrentVersion\Run", true)) and then do a get Value for the application I want to remove from running at startup. I can never find the registry value.
So I did a print out and low and behold the values in that are returned are nothing like what I see in regedit????
So can someone please explain why I am getting different values from HKEY_LOCAL_MACHINE than I see in my service install. Just to clarify this is in the Install part of the service in the event onbeforeinstall, and I run the install as admin.
I should mention this is on a 64bit Windows 7 build.
All replies (12)
Wednesday, December 1, 2010 10:59 AM ✅Answered | 1 vote
Hi jbuzz,
Welcome to MSDN Forums!
You can use the RegOpenKeyExW function to open the regsitrykey in the 64 bit part of the registry. And then use the RegEnumKeyW method to enumerate the key value opened above.
And there's also a sample code for this function, so you can reference it.
How to read the 64 bit (x64) part of the registry from a 32 bits (x86) C# application
And if you're using the .net framework 4.0 then you can use RegistryKey.OpenBaseKey method to read the 64bit key value through a 32bit application in the 64bit system.
RegistryKey rb = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey rb2 = rb.OpenSubKey(@"SOFTWARE\Microsoft\Windows\CurrentVersion\Run");
foreach (string vName in rb2.GetValueNames())
{
Console.WriteLine(vName+"||"+rb2.GetValue(vName));
}
If there's anything unclear, please feel free to let me know.
Best wishes,
Mike
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [email protected]
If(helpful) -> Mark
*****************************************************
Welcome to the new world! [All-In-One Code Framework]
=================================================
Third party disclaimer
This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information is found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.
Tuesday, November 16, 2010 11:16 PM | 1 vote
The issue is with accessing the registry on a 64-bit machine with the Microsoft.Win32.Registry API.
On a 64-bit machine, 32 bit HKLM\SOFTWARE registry entries are virtualised in the HKLM\SOFTWARE\Wow6432Node subkey. There's a pretty good summary of the issues in this thread.
--pogo (pat)
Wednesday, November 17, 2010 1:16 PM
Thanks for the reply, that sheds some light on the problem. But it does not matter what cpu I target it always pulls from that wow5432node on my 64bit machine. I can never get the value that are in the SOFTWARE\Microsoft\Windows\CurrentVersion\Run key.
Looks like I will have to write the registry api's and try that.
Saturday, November 20, 2010 12:57 PM
Hi jbuzz,
Welcome to MSDN Forums!
You can use the following test codes in your methods to test if that method can be execute without any issue. If there’s any exception message, then you can open our log file to read them.
By your post, you said that, “I can never find the registry value”.
And because of there’s no 64bit windows 7 now, so I only can work with a 32bit windows 7. I don’t know if there’s anything different in the following test in 64bit system. So if there’s anything I had not tested out, please let me know.
RegistryKey regkey = null;
using(StreamWriter sw = new StreamWriter("D:\\abc.log",true))
{
sw.WriteLine(DateTime.Now + "OnStart");
try
{
regkey = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows\CurrentVersion\Run", true);
foreach (string name in regkey.GetValueNames())
{
sw.WriteLine(name + "[" + regkey.GetValue(name) + "][" + regkey.GetValueKind(name) + "]");
}
}
catch (Exception se)
{
sw.WriteLine(se.InnerException);
sw.WriteLine(se.StackTrace);
}
}
I had tested it in my service sample code, and I put the test code in the following methods:
serviceProcessInstaller1_BeforeInstall
serviceInstaller1_BeforeInstall
Service1.OnStart
Only the OnStart method has no right to access the registry, and the others can retrieve out all the value from that registry key. And the following exception is raised by the OnStart method, you can find out this information in the D:\abc.log file:
System.ThrowHelper.ThrowSecurityException(ExceptionResource resource)
Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
WindowsService1.Service1.OnStart(String[] args)
D:\workspace\VS2010\WinForm\ConsoleApplication1\WindowsService1\Service1.cs: line 29
So I think you would need to test your project to see if there’s anything else is not suitable for this function in this project.
You can check your project first by my post, and then we would use the WIN API to instead of the .net methods if it is necessary in your project.
If there’s anything unclear or I had misunderstood you, please feel free to let me know.
Have a nice weekend!
Mike
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [email protected]
If(helpful) -> Mark
*****************************************************
Welcome to the new world! [All-In-One Code Framework]
Wednesday, November 24, 2010 4:59 AM
Hi jbuzz,
Have you solved this problem? And have the information above helpful for you to solve this problem?
If there's anything unclear, please feel free to let me know.
Have a nice day!
Mike
*****************************************************
Sample world! You will get more from this world!
Welcome to the new world!
Monday, November 29, 2010 2:16 PM
Hi Mike
Thanks for the info, but I was doing what you suggested in my attempts to debug this issue. What I found was on my 64 bit machine I always get the values that are in HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run. The value that I was wanting to remove was in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. No matter what key I used the values printed out are always the one in HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run.
If I used regedit I could see that the values are in fact different between the keys, but no matter what key I read I always got the values in the WOW6432node....??
However my code worked on 32bit machines, and 99% of the machines are 32bit so I rolled it and fixed the other 1% manually so I kindof have a solution, but would like to understand why I could not get the values out of the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key on a 64bit machine.
J
Tuesday, November 30, 2010 5:18 AM | 1 vote
Hi jbuzz,
When a 32bit application run in a 64bit system, the read registry call will read the key under the Wow6432Node registry key.
http://msdn.microsoft.com/en-us/library/aa384232(v=VS.85).aspx
Redirected keys are mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node.
You will know this if you read this document.
If there's anything unclear or anything is not right in my post, please feel free to let me know.
Have a nice day!
Mike
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to the other community members reading the thread.
*****************************************************
Sample world! You will get more from this world!
Welcome to the new world!
Tuesday, November 30, 2010 1:30 PM
Mike
I understand that...however it does not solve my problem. Here is a little background... We have some older apps that were installed via a vbscript. Basically the script copied the files, and performed all the registry operations. Not the way I would have done it but its done.
Now we are starting to see some mixed platforms 32bit/64bit installed in the organization. So we are creating MSI's to perform the installs. However during the installation we need to remove these old applications and the registry values.
So heres the rub...the vbscript did not distinguish between 32bit and 64bit os's. It just plopped our registry entry in the HKEY_LOCAL_MACHINE\Software .... Did not matter if it was 32bit or 64bit os. Now when I am on a 64bit os and try to remove that registry key it does not find it...it continually looks in the wow6432node. I have been unable to read the HKEY_LOCAL_MACHINE\Software registry. Everytime I dump the keys its from the wow6432node.
How can I force it to read HKEY_LOCAL_MACHINE\Software that is what I need to know...otherwise I have to manually remove the 64 bit apps.
Although I do see in the document your provided that there appears to be a way to force it via API calls....I will investiage that further when I have a chance.
J
Wednesday, December 1, 2010 1:32 PM
Thats what I was looking for...
I need to use the API, as my app is 3.5. But good to know about the 4.0 methods.
Thursday, December 2, 2010 6:02 AM
Hi jbuzz,
If you have any response on this question, please feel free to let me know.
Have a nice day!
Mike
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [email protected]
If(helpful) -> Mark
*****************************************************
Welcome to the new world! [All-In-One Code Framework]
Tuesday, May 17, 2011 9:47 AM
I have same kind problem but I can't use .NET 4.0 I have to use .NET 3.5 (because I have to use huge library writen in .NET 3.5)
is there any solution in .NET 3.5
Friday, September 7, 2012 7:51 PM
thanks for help it fixed it
he issue is with accessing the registry on a 64-bit machine with the Microsoft.Win32.Registry API.
On a 64-bit machine, 32 bit HKLM\SOFTWARE registry entries are virtualised in the HKLM\SOFTWARE\Wow6432Node subkey.