I saved some files into the Program Files directory, and now they’re gone!

A customer reported that they saved some files in the Program Files directory, but when they went back to check, the files were gone! What happened?

What most likely happened is UAC Virtualization.

UAC Virtualization kicks in for applications which were designed for versions of Windows prior to Windows Vista. These applications often assume that they are running with administrative privileges, and when they try to write to file or registry locations that are normally restricted to administrators, they expect them to succeed. So UAC Virtualization lets those writes succeed by secretly redirecting them to another location inside the user profile. The reverse happens when the application later tries to read the file or registry key: If the file or key exists in the redirected location, it is used instead of the one in the administrative location.

You can read the above-linked TechNet article for details. The short version is that you can find the files in the %LOCAL­APP­DATA%\Virtual­Store directory and the keys under the HKEY_CURRENT_USER\Software\Classes\Virtual­Store key.

Bonus chatter: There used to be a button in Explorer called Compatibility Files that appears if you are looking at a directory that has a corresponding Virtual Store, and clicking it takes you to that Virtual Store. The button was removed in Windows 8 based on telemetry feedback that showed that very nearly nobody ever clicked on it or even cared about it. Furthermore, in the years since UAC was originally introduced, the number of applications which require UAC Virtualization has dropped significantly, so the need to access items in the Virtual Store dropped correspondingly.

Comments (33)
  1. Anon says:


    "…applications which were designed for versions of Windows prior to Windows Vista."

    I read:

    "…applications which were not written properly, according to published Windows XP security guidelines, which repeatedly advised against storing user-modified data in system directories."

  2. Chris B says:

    @Anon – is an unenforced rule actually a rule?

  3. Antonio 'Grijan' says:

    @Chris B: It was enforced. Sort of. If you run a limited user account, you wouldn't be granted write permissions on system directories (Program Files, Windows) or registry keys (LOCAL_MACHINE, etc). Problem was nearly nobody used limited accounts, so almost no developers cared too support them.

  4. Kevin says:

    Based on the situation Raymond describes, I imagine the user manually navigated to C:Program Files through the Save As window.  So a "properly written Windows XP program" would exhibit exactly this behavior (unless it's supposed to check the directory the user provides for sanity?).

  5. Joshua says:

    Why did it have to be a policy switch to disable this incredibly bad idea? It should have been a switch to be set on each subdirectory of Program Files. The registry got it right.

  6. Max says:

    @Chris B: That's the point of quite a few of Raymond's articles – even if a rule isn't enforced now, you still need to follow it, because a later version of Windows may begin to enforce it. There is often a sizable period between when a rule is made and when it is enforced, specifically to give developers plenty of time to adjust to the new rules so that they won't be caught off-guard and have their programs broken when enforcement begins. If a rule exists, it should be followed, because Windows development will proceed based on the assumption that everyone follows those rules, and anyone who doesn't follow them is liable to have their programs broken at any time.

  7. Dan Bugglin says:

    @Kevin I believe UAC Virtualization will only happen for legacy applications… either they will have an app shim in place or will have Compatibility Mode applies for XP or earlier (that is my guess). For example if I do stuff in Program Files using an unelevated Command Prompt, UAC Virtualization will NOT kick in and I just get error messages.

  8. Tomashu says:

    I was wondering why pasting %LOCALAPPDATA%/VirtualStore in explorer cause %LOCAL-­APP-­DATA%Virtual-­Store until I looked into source.

  9. JM says:

    Reading that article really hammers home just how many hoops the MS engineers had to jump through to transition from the "software assumes everyone is running as an admin" world to the "let's actually start caring about security" world. When people today complain about how Vista sucked, they probably don't appreciate that a certain level of suck was almost unavoidable to get to Windows 7 (disregarding for a moment how much exactly was unavoidable).

    @Kevin, The MAZZter: the linked article explains exactly when virtualization happens: "for the purposes of this virtualization, Windows Vista treats a process as legacy if it’s 32-bit (versus 64-bit), is not running with administrative rights, and does not have a manifest file indicating that it was written for Windows Vista". No shims are necessary, all 32 bit pre-Vista apps are assumed to require this redirection. So yes, if "the customer" was an end user who saved from an XP application while not elevated, this could happen, but I interpreted the story with "the customer" as an app developer who was saving files automatically. If an end user was the one affected, see "unavoidable suckiness" above.

  10. Jason says:

    > I read:


    > "…applications which were not written properly, according to published Windows XP security guidelines, which repeatedly advised against storing user-modified data in system directories."

    Besides user-modified data, programs would write to those locations to update components of themselves.

    I'm curious what Windows would do if the file in the real location became updated or replaced? Would it serve up the virtualized, old copy, or the newer real copy?

  11. AndyCadley says:


    UAC virtualization is disabled automatically for executables and dlls, so Windows will fail attempts to update them. For other types of file, such as config files, Windows will read the virtualized copy instead.

  12. Mark Y says:

    Does the button still exist in Win7?  I just tried to go to such a directory and I see no button.

  13. Sean says:

    @Mark Y:

    It's there, but only if there are files in the virtual store version of the directory.

  14. foo says:

    > There used to be a button in Explorer called Compatibility Files

    <Mind blown> I've been using Win 7 for I don't know how long and never noticed that button (and yes it is in Win 7 as Sean says). Such a great feature I missed, since Win 10 will probably be happening for me in less than a month. For apps that used the virtual store (or ones I suspected of using it) I would always just navigate manually to the directory and see what was what. But in truth that was very rarely done. Still, me noticing the button up there would have been nice. But that area always held other buttons I scanned at once from right to left on some random folder (probably C root) and proceeded to not care about.

  15. Cesar says:

    @JM: "for the purposes of this virtualization, Windows Vista treats a process as legacy if it’s 32-bit (versus 64-bit), is not running with administrative rights, and does not have a manifest file indicating that it was written for Windows Vista"

    …and is not called something like update.exe. At work, we had a problem because one executable had one of these "magic" names, which disabled that virtualization (no, it was not a setup-type program, it did something like connecting to the database and updating its data). The rest of the system had the virtualized view, that one executable didn't, and it broke things. I forgot the exact details, since it was a long time ago, but it was something like it trying to read files written by another executable – writes which got redirected to a hidden place, which update.exe couldn't see because the virtualization got disabled for it.

    That executable was from before I arrived at that project; I fixed it by using a non-magic name for all executables, manifesting them to "never elevate" just to be sure, and by making things use the Application Data directory like they should have in the first place.

  16. Mark Y says:

    I can't find the button.  Any pointers?  What part of the screen?  What color?

  17. Neil says:

    Same here; if you start x86 WinDbg on x64 Windows 7 and use .symfix+ without specifying a download store, it will try to use C:Program Files (x86)Debugging Tools For Windows (x86)sym which promptly gets redirected to the virtual store, but there's no sign of a "Compatibility Files" button when you browse in Explorer.

  18. Dennis says:

    @Mark Y:

    In the second "menu bar" besides "Organize", "New folder" etc.

  19. metz2000 says:

    @Kevin If the user navigates somewhere explicitly it's not a badly behaving program but  badly behaving user.

    However, if this is the default folder in Save as or Open dialogs then the program is bad. Many programs default to current directory and some even override the last used directory every time Save as or Open dialogs are used.

    A good program would go with system default and wouldn't override last used folder. Or would default to My Document.

  20. Macrosofter says:

    >There used to be a button in Explorer called Compatibility Files that appears if you are looking at a directory that has a corresponding Virtual Store, and clicking it takes you to that Virtual Store. The button was removed in Windows 8 based on telemetry feedback that showed that very nearly nobody ever clicked on it or even cared about it.

    You imply that if people don't use the feature they don't need it. Alternate explanation can be that people don't know about it. The solution to this uncertainty would be to ask focus group to find files in virtual store and check percent of people who would use the dedicated button, then apply Bayes' theorem to find percent of people who use the feature while they know about it. The solution to interface problem if it really exist can be an introduction of some indicator of existence of files in virtual store right in the address bar, combined with such button.

  21. Deanna says:

    @Joshua regarding the policy switch. It is available per folder. Remove security on that folder, and access to that folder will no longer be virtualised.

  22. Max says:

    @Macrosofter: It's more that if people don't use the feature, they aren't likely to miss it if it's removed. In addition, the feature's usefulness has declined significantly now that UAC has been in place for over 8 years. Dropping rarely-used features, regardless of why they're rarely-used, means dropping the significant support and maintenance cost associated with those features.

  23. John Doe says:

    @Anon, legacy here means 32-bit applications without a manifest, or without a valid supportedOS manifest element.

    I agree the assumption is a bit too generalizing, there were lots of well behaved applications since Windows NT and Windows 2000, and quite a few ever since Windows 9x/ME gave place to Windows XP that did update themselves, all of which are considered legacy.

    The thing is, probably the majority or the most used ones still stored things in the application's folder, usualy INI files and even documents (the open and save dialogs would be initialized with the application's folder instead of the user's documents folder or whatever was the most recently used one).

  24. John Doe says:

    @JM, this has been discussed before.  It's not so much of a problem running as administrator if you're the single user of your machine.

    In fact, if you get infected at user level, what really matters is still compromised and possibly lost: "all your data are belong to us."  The operating system itself, however, will be intact until some administrator logs on and gets inadvertently infected (e.g. a kernel font exploit or some Explorer preview exploit when viewing the folder that contains the malware), how good is that?

    Much like a nuclear war would reap most of humanity off the face of the earth, but earth itself would probably even thank the disaster happened (those pesky parasitical humans!), even though other animals would be gone too, and lots of slowly decaying radiation would remain.

  25. skSdnW says:

    @John Doe: The supportedOS element is not used on Vista, it probably checks for the requested execution level…

  26. JM says:

    @John Doe: I couldn't disagree more.

    If I hadn't been running as administrator, the PC I owned 10 years ago might still work — who knows? Sadly back then it was customary to run everything as administrator and restricted user accounts were something fancy you only used on servers, so the virus that flashed my BIOS into unusability had no trouble doing its work.

    It's true that malware now focuses on screwing over your personal data more directly, ever since "pwn the entire machine completely" is no longer as simple as it was. (It's also true that the BIOS/UEFI in modern machines is no longer vulnerable in this way.) Does that mean defense in depth is not a valid concept? No, it doesn't.

  27. mikeb says:

    I understand that there are various reasons (probably good and bad ones) for this behavior and how the Windows world got to the state where this was a problem, but as a user who encountered this scenario, it's very frustrating trying to find your files even if you have an inkling that they might have been 'virtualized' to another location. This has only happened a handful of times tome, and I can't remember when the most recent was. But I do remember being quite irritated trying to find the damned things.

    I don't recall ever seeing a "Compatibility Files" button. It may have showed up in Explorer (unless they removed it in Win7), but I probably just never noticed it because it would have never dawned on me what a "compatibility file" was. On the other hand, it's just as likely that I was using some other file manager than Explorer.

    What I think would have been nice is if Explorer showed those virtualized files in a manner similar to how it shows files about to be written to a CD or files in different locations of the same "Library".  Then it would have been obvious that the file existed and was logically where it was supposed to be even if it was in a different actual location. But it sounds like there's little reason to make these UAC virtualized files easy to find since they don't seem to get created very much anymore.

  28. cheong00 says:

    Antonio 'Grijan': Agreed. And for those who actually required to care, they attempt to solve it in the wrong way.

    I've lose count on how many times I seen questions in MSDN forum asking how to run something as administrator without invoking UAC, and often what they're trying to do is something that do not require administrative access to complete if done correctly (say, write to correct directory, alter ACL of service to allow it be started by normal users, etc.)

  29. Joshua says:

    @Deanna: Unfortunately we discovered in testing that works most of the time but not quite all of the time. It resisted bisection. Having learned that Windows checks for the virtualized file on open even if the folder has wide open permissions, I suspect that file locking was the issue, or perhaps something more insidious to track down.

    (We have an application controlled temp directory with programmed wipes. It's under the installation directory because that's where this kind of thing went when the program was new and for three years the edict from management was turn off UAC since we discovered early on it worked just fine with UAC off but couldn't explain the behavior since it didn't track permissions 100% of the time.)

  30. xpclient says:

    Another button "View Remote Printers" was removed in the move to the Ribbon. Was it removed due to telemetry again or forgotten?

  31. John Doe says:

    @JM, we agree, then.

    It's just that, to me, data is a priority.  When you have to start somewhere, first deal with protecting confidential data and ensuring regular backups of crucial data.  If that means you have to harden a server's security from top to bottom, so be it, but I'd first start with data protection (e.g. PCI compliance, properly hashed passwords), access control, authentication, forced encrypted communications, logging, etc. and only them go down the rabbit's hole: firewall, IDS, throttling, antivirus, etc.

    In terms of single-worker workstations, no matter how your machine is hardened, you should have a plan to protect your data: encrypted storage and/or scheduled backups.

    I'm not advocating anyone to run everything as administrator or to disable UAC, or to not have protection at every layer.  It's just that most people get the wrong impression that they're protected relying solely on these lower-level measures.  Yes, you're more protected, but never really, completely protected.  Have your own measures on top of the low-level ones, one thing that is not easily restoreable is data.  You may consider configurations and active directory as data too.

    Hell, think about ̶s̶m̶u̶g̶ ̶a̶f̶i̶c̶i̶o̶n̶a̶d̶o Mac users who say it doesn't have viruses and it's totally safe.  I say it's mostly due to the lack of popularity and interest.  Several 0-day exploits for two popular browser plug-ins (say, one with the same name as a comic book hero, and one named after a coffee origin island) have kind of proven that it's not safer at all.

    It happens to their own software too, but Apple's secrecy policy and/or shame on their bugs (yes, even ones not related to security) results in not being able to detect duplicate bugs or track existing ones.

    Look at how recent these news are, it's not last year's news.  ASLR, pseudo-UAC and a few other things don't protect you from any of this, just about the same kind of exploits targeting Windows.  My dark side (do I have any other?) just keeps hoping OS X gets more popular so it gets more malware too.

    But I digress.  Just to show that relying on the library or OS or below alone is relying on quick-sand.

    TL;DR: (I think this is hip, right?  Oh, it's not hip to say something is hip, so I just de-hipped this)

    Don't forget to protect your data.

    Protect your data above all.

    You never know in which layer the next hole will be, but wherever it'll be, data is always compromised.

    Defense in depth?  Yes.

    Defense in depth solely at AD/API/AV/OS/network level and below?  A delusion.

  32. John Doe says:

    A few links, as my previous comment was deemed spam with them:

    Regarding 0-day exploits: arstechnica.com/security/2015/07/two-new-flash-exploits-surface-from-hacking-team-combine-with-java-0-day/

    Regarding bug report secrecy: stackoverflow.com/questions/144873/can-i-browse-other-peoples-apple-bug-reports

    The promoted comments here are quite interesting:  arstechnica.com/security/2015/08/0-day-bug-in-fully-patched-os-x-comes-under-active-exploit-to-hijack-macs/

    Regarding pseudo-UAC: http://www.symantec.com/connect/blogs/mac-os-x-dialog-box-spoofing-believe-me-i-m-system-preferences

  33. JM says:

    @John Doe: Kudos for going above and beyond the call on this one. Consider posting it on your own blog, or starting one if you don't have one yet. I think it could pay off.

Comments are closed.

Skip to main content