Before I begin: this section is not related to Virtual PC, Virtual Server, Hyper-V, App-V or any 3rd party virtualization product.

On Windows XP a process running as a regular user that attempts to write to %systemroot% (due to assumptions made by the programmer) would most likely crash, or at least throw an error due to a permission problem - "run as Administrator" was a workaround, but this is overkill (and potentially a security risk) as now the process has a lot more privilege than it needs.

The same program running on Windows Vista (or Server 2008) may actually be able to run as a regular user without elevation or errors, through virtualizing file access in %systemroot%.

Basically, attempts to make I/O in some system-protected areas are redirected without the program being aware - they end up in the user's personal folder or registry hive; so any changes they make are committed, but do not affect other users.

 

Example:

Launch cmd.exe as a regular user and go into the %systemroot% folder, then try to create a dummy file - you should get 'access denied' as below:

C:\Users\padams>cd /d %systemroot%
C:\Windows>echo test > test.dat
Access is denied.

 

Now start Task Manager, right-click on the cmd.exe process and enable the "Virtualization" option, then go back to your Command Prompt window and repeat the last command - now it works:

TaskManager-Virtualization

C:\Windows>echo test > test.dat
C:\Windows>dir test.*
Volume in drive C is Windows
Volume Serial Number is 7206-4628

Directory of C:\Windows

2008-10-25  14:34                 7 test.dat
               1 File(s)              7 bytes
               0 Dir(s)  69 726 556 160 bytes free

 

Back in Task Manager, disable Virtualization again and see if the file can be found:

C:\Windows>dir test.*
Volume in drive C is Windows
Volume Serial Number is 7206-4628

Directory of C:\Windows

File Not Found

 

So where is the test.dat file really? In %userprofile%\AppData\Local\VirtualStore\Windows...

C:\Windows>cd %userprofile%

C:\Users\padams>cd AppData\Local\VirtualStore

C:\Users\padams\AppData\Local\VirtualStore>dir Windows
Volume in drive C is Windows
Volume Serial Number is 7206-4628

Directory of C:\Users\padams\AppData\Local\VirtualStore\Windows

2008-10-25  14:34    <DIR>          .
2008-10-25  14:34    <DIR>          ..
2008-06-29  13:09               109 Cm106.ini.imi
2008-04-19  13:15    <DIR>          Debug
2008-08-05  18:45                16 popcinfo.dat
2008-06-19  18:34    <DIR>          system
2008-10-25  14:34                 7
test.dat
2008-05-10  13:53            82 830 War3Unin.dat
               4 File(s)         82 962 bytes
               4 Dir(s)  69 726 089 216 bytes free

 

Virtualization is done for the user, not on a per-process basis - above you can see other files created by virtualized processes previously, which would similarly be accessible by other virtualized processes.

Where potential "gotchas" can lie is where virtualized processes create files in the VirtualStore, then spawn new processes to handle the files, but those new processes are not launched virtualized - "file not found" would occur.