1
One of the apps I work on stores the database connection string in the registry. I changed the value (via regedit) to point to a different DB. My application was still picking up the old value. Pretty sure I did something wrong, so checked the code, rebooted, searched the registry to verify there wasn't another key with the same name. No joy. I even deleted the key, rebooted, and my app was still reading the value fine.
Then I used PowerShell to list the values (via Get-ItemProperty) and that showed the old value as well. Used Set-ItemProperty to update the value, and then my code picked that up fine. However, regedit is still showing the old data. Even got another developer and a system engineer to take a look as a sanity check. No ideas.
Any idea why regedit doesn't seem to be showing the same information as Get-ItemProperty?
Does regedit still show the wrong value? 32-bit or 64-bit operating system? Provide the location within the registry. This might turn into a Stackoverflow question based on my intial thoughts on the problem. – Ramhound – 2013-08-15T17:32:09.163
Yes regedit is still showing the wrong value.It's 64 bit. Location is HKLM\Software\LivingNaturally\AppConnectionString - which is a custom key. – Mike Hildner – 2013-08-15T17:39:34.717
1I would bet a lot of money that regedit is fine. You are either reading the wrong key, or your app is not behaving how you would expect – Keltari – 2013-08-15T17:43:29.740
@MikeHildner - I assume your software specifically reads the 64-bit
HKLM\Software
location and is a 64-bit application? If its a 32-bit application then it will automatically attempt to read the 32-bit registryHKLM\Software
. If the problem is what I think it is then Powershell more then likely handled this automatically and was hidden to you? Load up a 32-bit version of the operating system in a virtual machine, repeat what you did, I get on Keltari's bet that you won't be able to replicate the problem. – Ramhound – 2013-08-15T17:43:53.667Even though the registry key is custom the location will be transparent to Windows depending if we are talking about 32-bit or 64-bit process. – Ramhound – 2013-08-15T17:47:00.633
@Keltari - that could be the case, which is why I searched the registry for "AppConnectionString" and found only one entry. So I'm assuming the code is ok. Plus it picked it up just fine when changed from PS> – Mike Hildner – 2013-08-15T17:47:28.927
@Ramhound - yes, the code checks if the machine is 32 or 64 bit, then reads either the 32 or 64 bit view. – Mike Hildner – 2013-08-15T17:50:57.293
Why are you not using the configuration xml file that handles application settings? Modify your code and read the 32-bit and 64-bit registry key. See if you get different values. – Ramhound – 2013-08-15T17:56:28.787
@Ramhound - Not using the config files at the moment because this is an existing code base I inherited a couple days ago. You're right though, if I change the code to read the 32 bit values, I get what I see in regedit. That all makes sense, but what I don't understand is why I don't see both 64 and 32 bit values in regedit - I only see the 32 bit ones. Again, I did search the registry for that key and only one showed up. – Mike Hildner – 2013-08-15T18:04:13.463
@MikeHildner - A 32-bit process can only read the 32-bit registry hive entry on a 64-bit version of Windows. A 64-bit process will default to the 64-bit registry hive location but I believe can if forced read/write to the Wow6432Node hive if forced to do so. Its still a good idea to have a 32-bit and 64-bit version of the application and allow windows decide which hive it will read. – Ramhound – 2013-08-15T18:38:51.467