Welcome to the QA Tech-Tips blog!

Some see things as they are, and ask "Why?"   I dream things that never were, and ask "Why Not".  
Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.  
Old Chinese Proverb

Wednesday, January 20, 2010

Windows 7 / Windows Vista Virtual Store Bug

In previous blog postings here I have talked about Windows 7 - as compared to Vista and XP - and all-in-all, (IMHO), Windows 7 is a pretty slick operating system.

Not unlike other "new" operating system releases, there are - and will be - teething problems that will eventually be worked out.

There IS one issue that - though probably "by design" - is sufficiently evil that it borders on being a really nasty bug: Neither Vista nor Windows 7 refresh the Virtual Store's image of a file when the target file changes.

At this point you may be saying "Virtual Store"??! What the. . . .!!!

A little bit of an explanation is in order:

Vista was Microsoft's first real serious attempt to tighten up their security model and they did this in several different ways . . .
  • They implemented the now infamous UAC - User Access Control, (or User Account Control depending on who you're listening to).
  • They designated several important areas within the operating system as "protected" areas - you are unable to write to these areas without specially elevated privilege levels.
  • However - to maintain backward compatibility with older programs written for XP - they allowed a special exception: If a non-privileged process attempted to access a privileged (protected) area, a write-enabled copy would be created that would be accessed as if it were the original.
  • They way they accomplished this is by using a special directory called the Virtual Store.
  • This directory is located at:
    C:\Users\[current user]\AppData\Local\VirtualStore
    and it contains an image (copy) of any protected items that were accessed by non-privileged processes.
The idea has merit. Older programs written for XP or before, that automatically assume that EVERYONE is an Administrator level user and write all over the system willy-nilly will be given access to the Virtual Store instead of the Real Application. Virii who wish to install themselves into the Program Files directory get side-tracked to the Virtual Store - or raise a UAC - instead of just sneaking in.

The Virtual Store operates according to some very simple rules:
  • If a non-privileged application attempts access to a privileged area (C:\Program Files\MyApp, for example), a copy of the thing they tried to access is copied to the Virtual Store.
    Viz. It would be copied to:
    C:\Users\[current user]\AppData\Local\VirtualStore\Program Files\MyApp
    . . .and the application would be given access to the Virtual Store instead of the real program path.
  • If a non-privileged application tries to access a protected area, AND there is already an image of the object requested in the Virtual Store - the application is automagically re-directed to the copy instead of the original. In other words, if C:\Users\[current user]\AppData\Local\VirtualStore\Program Files\MyApp already exists (in the Virtual Store), then any reference to C:\Program Files\MyApp will automatically be redirected to the copy in the Virtual Store - AND - as far as the executing process is concerned, it will actually appear to be executing out of the C:\Program Files\MyApp directory!
  • Pivileged applications - running as true administrator equivalents via the UAC or by inheriting elevated privilege - always get access to the real file, not the copy in the Virtual Store.
 This is all well-and-good, but if you're paying attention, you will have noticed a subtle issue has crept into the system:
  • If I publish a periodic (or bug fix) update to MyApp\. . . . the updater or .MSI file that does the updating will actually and truly write to the real Program Files folder.
  • However, once the update is done and the non-privileged application starts to run again, it only sees the cached version of the file in the Virtual Store's folders.

    - AND -

  • The presence of an updated version in the Real Folder does NOT trigger a refresh of the cached data in the Virtual Store! 
There's the problem. Stale data in the Virtual Store will cause your program to run amok, even after a patch or bug-fix has been installed.

The solution is simple:
  • Never store data or user-generated configuration files in a protected area, such as Program Files.
  • When the non-privileged application begins to run - before it does ANYTHING else - it should check the Virtual Store manually - via the explicit path - and see if there is a "MyApp" directory there.
    • If there is a virtualized copy there, delete it.
  • Installer software or .MSI updaters should follow the same rule when they begin running.
This will force Windows to update the Virtual Store so that when the non-privileged application runs - and accesses data in the Virtual Store - that it will always get the latest-and-greatest version.

Note that this workaround will also work on a legacy system running XP or earlier - since the path to the Virtual Store will NEVER exist on these earlier systems, the program's logic will simply skip past that and go on to launching the application.

What say ye?

Jim

1 comment:

  1. I wanted to let people have control under where their games, sets and decks are stored, but I am not so sure it was a good idea. The folder names are a bit cryptic anyway (based upong the game GUID). Moreover if a user chooses some restricted folder as “Program files” it may have errors when using limited accounts (by default under Vista and 7).

    ReplyDelete

Thanks for sharing your thoughts here at the QA Tech-Tips Blog!

Note:
This blog will not, repeat NOT, publish comments that contain ANY KIND OF HYPERLINK.

If your comment contains ANY KIND OF HYPERLINK it WILL BE DELETED.

Please read the article at How To Get Comments Approved On This Blog for additional information regarding this rule.

Thank you for understanding.

Jim (JR)