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:
No, not the problem -- there is an actual folder that IE Protected Mode makes with the files in it visible to users on-purpose. It has the a similar path from a C FOLDER that the actual path from the C DRIVE.
Nasty. Disturbing. Annoying.
i agree - the user should never be aware of this.
and nobodys wife should ever be forced to use process monitor ;)
This isn't an IE bug or a Windows bug. This is a security breach in an add-on to IE, which IE & Vista are handling fairly gracefully. Windows 7 won't solve it, because it's not Microsoft's error. On IE and Windows end, it is a feature, it is not a bug.
The ActiveX control or BHO that saved these to the desktop need to be fixed. If they want write permissions to the desktop, then they should install a user-rights broker.
I good an great and you saved the day. Buthow do you keep all these files purged? since moving to vista unless I write an elaboatre script I can't use robocopy to basic backups of the user directory because of the virtualization directory. Robocopy gets stuck on this with a never ending diectory structure. Any better ideas.
I can't stand that endless recursion of dirs, it really plays havoc when searching for something through a command window, as the name gets too long for Windows to process. As for the strange desktop behavior, I noticed early on that sometimes files that WERE on the desktop are mysteriously gone next time I log on. I've also had other weird things happen in Vista, like my desktop is arranged way differently than I left it. I put it back, and then sometimes it does the same thing. Sometimes not.. My wife has noticed the same occurences a few times as well. That's Microsoft for you!
"This isn't an IE bug or a Windows bug."
Of course this is a windows bug! No one knows what the hell happens and where are the files!
They should either block low integrity operations altogether informing users why they do it or they should add mechanism to inform users where are the files.
MS solution is completely unacceptable yet at the same time typical, it showcases their usual contempt for end users.
If they really had to have virtualization each time a file is virtualized a dummy file should be created in the actual folder, this dummy file should upon mouse over or opening inform users in non technical terms what happened to their files and how to get desired behavior.
Is this all so hard to understand or are people just too accustomed to the way MS treats users to even notice the absurdity of their approach?
I appreciate that the legacy ActiveX controls and helper applications need somewhere to store their data but couldn't a less obvious, and visible location have been chosen?
Obviously, for the time being low integrity files will continue to be written here. To head off end user confusion a nice, simple, method or retrieving attachments, etc, needs to be implemented, at least as a stop gap!?
I haven't tested it, but I assume the same happens under Windows 7?
As to losing points with your dear wife, look out for the moment at which her eyes start to glaze over, works a treat for me.
Finally, great article, as ever.
Now that Mr. Russinovich works at Redmond at least it can inform the guys who designed such a mechanism how they are just baffling users.
That's a perfect example of a bad techie solution that doesn't work in the real world.
I too agree that MS should stop to put too much emphasis on "compatibility". Windows should be compatible with well written applications, and should begin to stop those written without following the rules.
Mark, great article. And great utilities - I have been using them for some time now.
I find it remarkable the number of comments that evidence users who are now, and are content to remain, ignorant of how Windows works. If every application, add-in, or activex object out there were 100% Windows-compatible, there would be no problem, and no need for PMIE. But the fact remains that many programs are written on non-Windows systems, and many more are written by malicious programmers, so there is a problem, and that is why the virtualized folders exist.
Why don't you all complain about truly annoying things like your wife's cooking, or the neighbour's dog crapping on your front porch? Be glad you even have computers. With all your whining, you'd never have survived 30 years ago when personal computers were in their infancy.
To Ollie and anyone else foolish enough to think by switching to Mac, or any other operating system for that matter, that you will magically become immune to malicious software, think again.
And to Luigi, Windows IS compatible with well written applications, that are written to be Windows compatible. It is the applications that are NOT well written, or are malicious, that created the need for Windows to impliment this security step. And what "rules" are you referring to? If there were a single set of rules that every application developer HAD to follow, then there would be no more viruses, and every application created would be compatible with every other application, and they could all be run seamlessly on every operating system in existence.
Well, someone once said that someday computers would be as easy to use as a telephone. I think that day has finally arrived. Whenever I am forced to use a phone that isn't my own cell, I usually don't have the slightest idea how to use it.
Related question: I am concerned that the concept of "libraries" in WIndows 7 is going to create similar confusion perhaps. Have you looked to see what is happening there?
People are used to files and folders (even novices to computers) and this may make the "location" of a picture or document become even more difficult to understand.
The Libraries feature of Windows 7 is there largely to facilitate sharing of individual files - the files can be shuffled between the personal and public documents folders without ever changing spots in the Library with a simple UI in the shell.
It's a logical feature with a pretty smooth implementation. The actual file locations are fairly easy to find as well, and don't have tons of junction points to throw off tree-walking utilities.
As for the virtualized folder issue, these files *should* be flushed when IE closes every single time, and the PMIE broker should pop up a warning whenever a virtualized file is created (with exceptions for the shell-generated junk like the thumbnail cache) with some straightforward actions the user can take. With some stern warnings for executable content (or even just ignoring it until the purge at quitting time), it shouldn't pose much of a security risk. Maybe for Windows 7 SP1, eh?
Is there a way to stop the desktop.ini file from showing up everywhere?
I have the same problem about desktop.ini file as well, it invades all my folders and desktop and most of files with "MY" words on it became inaccessible... So anyone for u can tell us this? And also why "Error 08x80070052 keeps popping up every time i want to copy a file to USB's? which it never happened before untildesktop.ini invades my files
Interesting. It looks like it's bug in a "Open Dialog" window. If you do drag&drop into this window, it asks for the UAC confirmation. But if you copy a file with ctrl+c/ctrl+v - it will be just dropped there and appears then in a "virtualized" folder.