This post is a new episode in my attempt to take control of my new Windows 7 64-bit machine.
Windows 7 64 bit (but this is probably already the case in Vista 64-bit) has a concept of VirtualStore which may pose some problems surprising. I found two:
- the file I created with a 32-bit program (in this case Eclipse) in a directory (in this case a sub directory ProgramFiles) does not appear when I pass by explorer.
- since a 32-bit (or NS-DK NatStar in this case) the values I read in a file (in this case in a subfolder of ProgramFiles (x86)) are not the ones I read when I open the same file explorer.
- since a 32-bit (same as above) I can read a file (in this case in a subfolder of ProgramFiles (x86)) which is not visible in Explorer when I post hidden files (this is actually a duplicate of the first case)
The explanation for this phenomenon is the creation of a system by VirtualStore. The visual sign that you have a VirtualStore that corresponds to your directory has been created is the presence of a button "Compatibility Files" in the bar Explorer tool.
Notice in the example above, the presence of two files:
- DemoNatJetCompleted.war on 18/02/2010 at 11:20 AM on 30/05/2008
- NatJxt3DemoMultiPannel.war
We are in the directory "C: \\ Program Files \\ Apache Software Foundation \\ Tomcat 6.0 \\ webapps". Both these files have been copied by hand by the explorer. The process 64-bit Tomcat correctly detects both files.
If you press the button "Compatibility Files", it switches to the directory "C: \\ Users \\ jltho.NATSYSTEM \\ AppData \\ Local \\ VirtualStore \\ Program Files \\ Apache Software Foundation \\ Tomcat 6.0 \\ webapps" of VirtualStore.
We now have two files:
- DemoNatJetCompleted.war 17/02/2010 at 18:41: the date indicates it is older than the one we saw earlier.
- NatVie30WF
These two files have been created directly from a 32-bit Eclipse by the export function / War ... The Tomcat process does not see these two files. Eclipse he sees them.
In the case of my application NatStar / NS-DK (there is a 32-bit binary-based C), the problem was even more surprising: the VirtualStore file was created by another mechanism (my application consults the file read-only). My application reads this file VirtualStore yet. When I edit the file in the home directory via the browser, the changes I make are not visible by the application: it continues to read the old values. If I delete the file in the original directory (ProgramFiles (x86)), the application continues to be able to read data from the Explorer while I see nothing.
FYI, we detected the problem through the use of Process Monitor, which we found that the process did not read the directory ProgramFiles (x86) but in a different directory.
Once in the VirtualStore (with the button), you can surcharge files. In the case of my application NatStar / NS-DK, she began to read the correct file and did not re-created in VirtualStore. I modified this file by the explorer since, without the VirtualStore is recreated.
The rule that you can deduct is:
- if a process 32-bit writes in some directories (a priori ProgramFiles (x86) and ProgramFiles), the system redirects its writing in a different physical directory: the VirtualStore
- if a 32-bit application reads a file in a directory with a VirtualStore, she read in Firstly the file if it exists in the VirtualStore. If the file does not exist in VirtualStore and only in this case, it will read the file in the original directory.
We note that for a 32-bit process, the file in the VirtualStore prevails.
For a 64-bit process, it sees only the original directory.
Howknow why a file was virtualized?
This is possible by using Event Viewer in Windows 7. It begins by typing in the command area: Obs and selecting it from the list that appears.
Rubric interests us is: "Newspapers applications and services" then "Microsoft" then "Windows" then "UAC-FileVirtualization. Clicking on the operational nodes, a list appears. The events of 4000 show the ID creation file virtualization.
By clicking on tab detail, is possible to know who created the file in question:
Thus we see that a temporary war file was created by the VirtualStore javaw.exe process started from a C: \\ NatJet3.0.2 \\ thirdparty \\ jdk1.5.0_15 \\ bin.
It is through this that I realized how NatStar for my application, the files were created Virtualization: it was the installation of my application that launched a 32-bit process (switch.exe ) to make substitutions in the installed files in ProgramFiles (x86).
Conclusion
This virtualization mechanism is very surprising: the will of Microsoft seems to have been to increase the compatibility of many applications that do not respect the rights on directories ProgramFiles. This is to facilitate the migration during the transition to Vista: Vista before the applications had admin privileges, since they turn els with a simple user rights: they are no longer allowed to write anywhere .
You can find more information on the subject in the following two pages:
- http://support.microsoft.com/kb/927387 : it presents other problems associated with virtualization
- http://windowsteamblog.com/blogs/developers/archive/2009/08/04/user-account-control-data-redirection.aspx : one good article in English which explains how virtualization and why. It also describes the use of Proc Monitor to detect applications that triggers virtualization.
