We have a software which saves its connection info to the Windows registry, under HKLM\Software. It's only a 32bit application, not 64bit, and we're well aware of the different locations for that (WOW6432Node). We are 150% sure we are reading and writing the very same registry entries - our software is some 20+ years old.

In the past month, 3 computers, two of them Windows 7, and the third Windows 10, have been acting very strange. The only way we can describe it, is that it's as if the Windows Registry has been duplicated! We write connection info in the registry for our app to connect to the server. But it reads old entries which we've changed a long time ago!

It seems, if we run the app "As Administrator", then they want to play nice. Although the user logged in is a local admin of the PC. For example, we open Regedit and change one of these entries. Run our app, and it reads the old entries from before it was changed, but then we run the app as administrator, and suddenly it gets the correct entries.

Is this a known issue? What's going on here? Is it some Windows update that broke this? Anything I can do to fix it?

  • You may know this already, but many don't. After making any change in regedit, if you plan to use that setting, hit F5 refresh. I don't know exactly why, but I've come across a lot of cases where the F5 alone, allowed those changes to become effective immediately. YMMV, depending on the application. – DaaBoss Apr 20 '18 at 15:31
  • Under which registry key is your data? – harrymc Apr 20 '18 at 17:38
  • @harrymc As said in my question, HKLM\Software, specifically the WOW6432Node (since it's 32bit). – Jerry Dodge Apr 20 '18 at 22:25
  • @DaaBoss Well using Regedit is just a simple example, anyway. The same applies when these entries are modified from another application (a tool of ours dedicated for the sole purpose of changing these registry entries only). So it's as if some applications use one part of the registry, while others use another place. But they are coded to read/write the exact same place. The underlying implementation of the registry (in Delphi) automatically accommodates for 32bit/64bit differences. – Jerry Dodge Apr 20 '18 at 22:28
  • (1) Could you be more specific about the key? (2) Have you tried to use regedit to search for the old data to find where it's hiding and compare it to where you placed the new one? – harrymc Apr 21 '18 at 7:18

As a programmer, I've run into this situation often; a company will go 20+ years using an application that was written for an older version of Windows, and then be forced to upgrade, only to find out that either Windows security updates or the version of Windows itself has rendered their software obsolete under the hood instead of in practice.

What is likely to be happening here is that your application is slamming into a group policy problem. Group policy can be used to modify the registry or registry behavior based on which user is logged in. I would look there for the root cause of your problem, though if you add what it is you're doing in the registry to make your app work, there may be new information as to why this is happening.

An issue this brings up is that as of Windows working in this manner, it can put developers at the mercy of the network IT group, as they are usually who manage the group policies. Most modern developers try to stay out of the workings of the OS now when developing applications and store configuration information either in databases or in local config files. While tinkering with group policies might lead to a short-term fix, it's likely that the real solution is to change your software solution in such a way that whatever it's doing in the registry, it's now handling on its own. Anyone who says "no, we shouldn't upgrade our 20 year old software because it will cost too much" is just kicking a can down the road until a day where a minor IT change breaks the software completely and permanently and costs the organization a whole lot more.

  • Well actually, the registry entries in question are only the credentials to connect to a Microsoft SQL Server database, where all the rest of the work is done. We don't actually store "data" in the registry. Just how to access it. – Jerry Dodge Apr 20 '18 at 22:31

Since I cannot comment yet with my reputation, let me list some troubleshooting suggestions here, even though they're not actual "answers":

  • Run your program after starting ProcMon (Process Monitor from SysInternals). You can put a filter including only your program name (or PID), and it may give you some ideas where the program is reading from, and/or if something is failing along the way.
  • Yet another sysinternals tool Process Explorer (or Handle) could also give you the path of the registry (if you're keeping the key "open").
  • Any chance your program has some logic that it falls back to a previous value (stored on disk/config file, etc) when it fails reading from registry? It is otherwise strange that you're not ending up with a default fallback value but one that was written to registry at some point.

The problem may be related to Registry Virtualization.

Windows redirect registry writes to HKLM from software without administrative rights to a different, user specific, location in the registry. Have a look HKEY_USERS\<User-SID>_Classes\VirtualStore

From the Microsoft MSDN site Registry Virtualization

Prior to Windows Vista, applications were typically run by administrators. As a result, applications could freely access system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access rights. Windows Vista and later versions of Windows improve application compatibility for these applications by automatically redirecting these operations. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a per-user location within the user's profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software).


I asked the poster to use regedit to search for the old data in order to find where in the registry it is hiding. The answer was that the old data no longer exist in the registry, yet is used by the program.

In view of that, the only explanation I can think of for the program "reading" old values which no longer exist in the registry, is that it is not reading them at all. A matter of optical illusion.

I believe that the program must be caching the values that it reads, and uses its last-good values when it cannot manage to read the new values from the registry. (Or maybe it has some built-in defaults for them.)

The problem must be a matter of permissions. This would explain why when it is run as administrator, it does manage to read the new values from the registry, since with administrator permissions it cannot be blocked.

I suggest that you use regedit and Explorer to compare the permissions on the registry key to that of the .exe file of the program. You may use regedit to add the account under which the program runs, with Read permission, to the key in question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.