Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
A few weeks ago, my wife mentioned that she sometimes saw files in her desktop folder that didn’t appear on the actual desktop. She brought it up not only because she was confused by the discrepancy, but because she wanted to move some of these phantom files to other folders and wanted to delete others. I had no idea what she was talking about (which was usually the case when she described her computer troubles), so I told her that the next time she saw these mysterious files, to call me to look at it.
A few days later I got home from work and she greeted me excitedly at the door and explained that the problem reoccurred and that she had left a window open showing the elusive files. I rushed to the kitchen computer with anticipation, not even bothering to greet the dogs on the way, and surveyed the situation. She had a maximized IE window open with a full row of tabs for her open emails (I don’t think she ever closes an email window). An IE “Choose a File” dialog box was in the foreground listing the files in her desktop folder, which she had opened by clicking the attachment button in the email editor. The dialog looked like this:
I minimized IE to view the desktop background and sure enough, several of the files visible in the dialog, such as the “Maui Feb. 08” folder and the CIMG13xx JPG files, were missing. I opened an Explorer window and navigated to her desktop folder to see if the files would show up there, but they were missing there as well:
I’d never seen that behavior before. I knew this was a job for Process Monitor. Since my wife doesn’t keep the Sysinternals tools on her system (sad, but true), I ran it directly from the network using the Sysinternals Live address, \\live.sysinternals.com\tools\procmon.exe. With Process Monitor recording activity, I closed and reopened the Choose File dialog from the email editor and then I search for “CIMG”, a portion of the file name for many of the files present in the Choose File dialog, but not in the Explorer view of the desktop. The first hit was a directory enumeration operation with the file names showing as results in the Details column on the far right:
The files were located in her profile under \Appdata\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\Daryl\Desktop. This Virtualized is directory created by IE7 when run in Protected Mode (PMIE), which is the default mode on Windows Vista and Windows Server 2008.
PMIE uses Integrity Levels, introduced in Vista and Server 2008, to limit the file system and registry locations to which code running in IE can modify to a subset of those writeable by the user account in which IE executes. As I described in an earlier blog post, the sandbox defined by locations labeled with Low Integrity, the level at which PMIE executes and of the objects that PMIE can modify, allow PMIE to save favorites and temporary files, like the IE cache and browsing history. However, PMIE cannot modify other locations in a user’s account, like documents folders and per-user autostart locations in the registry and file system, because they have an integrity level of Medium. That prevents drive-by-download malware that might infect the IE process from establishing a persistent presence.
In order to preserve backward compatibility with legacy code, such as ActiveX controls and Browser Helper Objects, that might be coded to write to locations outside of the sandbox, PMIE implements shims that intercepts file and registry operations and redirects ones that got outside the sandbox to the Virtualized directory within it.
To see if that was what was happening here, I examined the stack trace of the virtualized operation highlighted above by right-clicking on the line and choosing Stack. The stack showed that Acredir.dll was intercepting the operation and executing redirection functions:
Double-clicking on the line in the stack trace opens the module properties dialog, which shows that the DLL is the “Windows Compatibility DLL”, thus confirming this was part of PMIE’s sandbox implementation:
I had been familiar with PMIE’s virtualization, but I’d never seen files virtualized on the desktop, so it had not been obvious to me that was what was causing the discrepancy. Process Monitor revealed the cause, so now all I was left with was cleaning up the virtualized files. Most users don’t realize that you can move and delete files from within a file browse dialog, so I took the opportunity to show my wife how she can manage virtualized files from the email editor’s attachment dialog if she came across them again. We deleted the files she didn’t want and moved the pictures out to her photo library folders.
The case was closed. As a bonus, my wife was impressed at the ease with which I’d figured out the source of the phantom files and even more impressed that I wrote the tool I used to solve it. She’d also gotten an in depth look at PMIE’s virtualization and integrity levels, but I think in the end my lecturing on those subjects actually subtracted points.
Incidentally, you’ll almost certainly see files and directories if you look at the PMIE Virtualized folder in your profile, because even routine operations within IE result in redirection. Here you can see thumbnail cache files that the shell’s file browsing dialog creates when you use it from within IE. Normally, the shell stores thumbnail cache files in your profile, but PMIE can’t write to that location so the shim virtualizes it:
<p>> As a bonus, my wife was impressed at the ease with which I’d figured out the source of the phantom files and even more impressed that I wrote the tool I used to solve it.</p>
<p>Yeah, but what about the dogs?</p>
<p>So here's the obvious, unasked question: why is Microsoft spewing temporary files all over the desktop in the first place? If you have to create a virtualized directory to maintain backward compatibility with unsecure ActiveX controls, then why isn't that directory somewhere that won't bother the user? Something comfortable under the "temp" directory comes most immediately to mind. I can't fathom the sort of thinking that would allow said files to be created in a location where the user has a right to expect things to be consistent.</p>
<p>Phileosophos has clearly misunderstood the situation. The files do not show up in the Desktop because they are NOT located in the desktop. They're located in the virtualized directory, somewhere hidden so that the user won't be bothered by them.</p>
<p>Only to IE do the files appear to be in the Desktop. This is the whole point of having the backwards compatibility shim in the first place. The files must appear to the ActiveX control as though they were in the Desktop, so that the control will be able to find the file.</p>
<p>The general problem with almost-but-not-quite-seamless compatibility shims in Windows is that some vendors end up relying on them for years. I vote with my money by avoiding these types of programs (Quicken being the classic example), but most users don't know and don't care. Sometimes even Microsoft programs fall into this category.</p>
<p>Frankly, I think the only way to deal with this is to have a place to see every shim applied for every program on your system. But then, Microsoft has always treated partners and OEMs with kid gloves (especially after the antitrust suit). And so the ecosystem continues to be a quality jungle ...</p>
<p>Actually my Mom had this same issue (though I hadn't been able to sort it out). If I recall from my mom's case it wasn't that it spewed files all over the desktop, the desktop itself was clean. But what happened is (almost same scenario as Mark's wife). When she went to email a photo she could "see the photo on her desktop" in the file browser window even though it wasn't there on the "real" desktop. So she'd click it and try to send it and it wouldn't work, the email would send without the attachment. </p>
<p>I finally re-saved the picture to her My Documents/My pictures and everything worked fine. But it's nice to know what the real root cause was. Interesting as usual Mark.</p>
<p>Interesting reading as always.</p>
<p>I'm thinking the "phantom" files might have come from some webmail attachment downloads or similar, but just guessing. Maybe an ActiveX helper control for doing just that.</p>
<p>I think you forgot to add in a link: "As I described in an earlier blog post [link]"</p>
<p>Presumably it is a 3rd party ActiveX control spewing files on the desktop and not Microsoft (hopefully). This solution won't normally bother the user as the files only show up in the Choose File dialog. My guess is that Low Integrety processes (or perhaps just Internet Explorer) get a merged view of the real location (C:\Users\Me\Desktop) and the virtualized location (C:\Users\Me\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\Me\Desktop). But what happens if you are running IE in protected mode and save a file to your desktop? I don't run Vista, so I honestly don't know the answer to this question.</p>
<p>They weren't temporary files. From the names it looks like they were saved files, his wife had tried to save them to the desktop from within IE and they had been redirected to the virtualised desktop since IE was running with lower integrity.</p>
<p>Secondly, it wasn't spewing them all over the desktop, it had obviously redirected writes to the desktop to the virtualised directory.</p>
<p>"I had no idea what she was talking about (which was usually the case when she described her computer troubles)..."</p>
<p>"...I think in the end my lecturing on those subjects actually subtracted points."</p>
<p>Join the club, Mark. We have a secret handshake and discounts with local retailers.</p>
<p>Awesome post as always.</p>
<p>Ahh! Well there you go. I have this exact behaviour on my work lap-top when looking at the directory structure through SharePoint's multiple-file-upload interface. I've never really been bothered trying to fix it (as I'm usually in the middle of something when I notice it).</p>
<p>This is the reason why I don't like Vista. It tries to be easy, but finally has so much complexity, that it's mostly annoying. I really don't like the "I-see-a-file-but-it-is-not-where-it-is-supposed-to-be"-virtualization-thing. Conclusion: I am going to switch to Mac soon.</p>
<p>"my wife was impressed at the ease with which I’d figured out the source of the phantom files and even more impressed that I wrote the tool I used to solve it."</p>
<p>....Does your wife not realise just how much of a big deal you are? Or what you actually do? We all love your tools and your posts are always enlightening, highlighting just how little *some* of us actually know!</p>
<p>Awesome as always and I can't wait for Amazon to deliver your latest book to me!</p>
<p>Actually, the case isn't closed, I don't think users have to see this issue show up... Will this be fixed in the future?</p>
<p>Don't use IE. Problem solved. That "Virtualized" directory does not exist on my Vista machine (on which I use Firefox).</p>
<p>"She’d also gotten an in depth look at PMIE’s virtualization and integrity levels, but I think in the end my lecturing on those subjects actually subtracted points."</p>
<p>If it makes you feel any better, you can come to our office and lecture on any topic to your heart's content.</p>
<p>Great piece...and for the very first time, I knew what the problem was before reading your analysis. Actually, I attended your TechNet lecture on UAC and integrity levels which touched on PMIE. Is that cheating?</p>
<p>I've had the opposite problem that's extremely frustrating. I used a third-party PDF printer. It would put PDFs in a virtualized folder for My Documents.</p>
<p>Imagine the fun when you go to your "real" documents folder and then NOT find the pdfs you printed! </p>
<p>I switched to another pdf driver that doesn't do that.</p>