Bad, bad VirtualStore

I encountered an unusual error with Windows 7 recently. I had to install a business software that has some legacy-ish traits. One of them is using old-fashioned ini-configuration files. After installation the software was working. Then I needed to change the configuration of the program via the ini-file and so I did -- but it didn't affect the program in any way! Actually, whatever I did to the config file, it didn't seem to have any effect.

Example path of the configuration:
C:\Program Files (x86)\Software\software.ini

I had the exactly same setup on other machines too, but they didn't display any of this behaviour.

I thought every aspect I could. Reinstalling the software several times with several methods; booting the system countless times; searching the registry for any offending keys; googling with every kind of query I could come up with; even suspecting the UAC doing something (not really) funny. All to no avail.

Well, except the UAC.

A bit shamefully, as I hadn't heard from it until this, it turned out that Windows has a hidden VirtualStore folder for programs that want to open files for writing from secured locations. It is a part of some Vista-introduced (para-) virtualization technology and one such protected location is of course the Windows Program Files folder. So because of the User Account Control the software couldn't really write to the location it so badly wanted.

Windows first checks the VirtualStore and after that the real path the program was asking for. For whatever reason there was a copy of software.ini in the VirtualStore folder. And that was my problem.

So sure, all I had to do was to remove all files concerning the software from C:\Users\username\AppData\Local\VirtualStore\ and voilá – the program started using new settings. Duh.

There's a quite detailed explanation about the UAC and associated virtualization in a Microsoft TechNet article.

{{ message }}

{{ 'Comments are closed.' | trans }}