Windows acting like there's two registries?

Question

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?

Answer 1

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.

Answer 2

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).

Answer 3

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.

Answer 4

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.