Access denied on C:, even though you have given the user Full Control


One of my customer was in the process of migrating away from Windows XP. As a part of this work, the customer was verifying application compatibility. During the testing of applications, they discovered that 2 applications that are business critical for the customer were having issues with file creations. These issues are counted as showstoppers for the roll out of Windows 7. The purpose of this blog is to describe the technical reasons of this issue and its resolution.

The customer´s technical issue with creating files via a web based tool with an ActiveX Component that will save information locally and Scanning Application on the client machine, focusing two specific error messages:

Error message “unable to create file” in the Scanning application

Error message “Internet explorer has had a fatal error” in the ActiveX component application

Both these application are working in Windows XP without any issues. The customer is doing a 1:1 migration of the application when they move the applications to Windows 7.


Security settings

The will give the users the same NTFS permissions as they had on Windows XP.

Based on the documentation on the applications there is a need to save temporary files in C:\. Based on this configuration shown in the Picture above, the application user will have all the necessary NTFS permission to write the application files to %systemroot%, in this case C:\.

Even though when the user is having Full Control in C:\, the user will get the access denied message.


Something strange magic is at Work here. There are more things going on than meets the eye.


The customer has high security requirements and has enabled User Account Control. One of the setting that are set is the following:


User Account Control: Virtualize file and registry write failures to per-user locations


When this policy setting is enabled, application write failures are redirected at run time to defined user locations. Enable this policy setting in environments where legacy applications need to run as if they were running in Windows XP.

When this policy setting is disabled, applications that attempt to write in privileged resources, such as the Program Files folder, fail. Disable this policy setting in environments where file and registry virtualization is not required.

This UAC setting must be enabled for Virtual Store to be functional.

More information about this setting is available here:

This means that they have enabled Virtual Stores, which means that information from the application should be written to Virtual Store directory (%LOCALAPPDATA%\VirtualStore, C:\Users\user\AppData\Local\VirtualStore).

After verifying the application we are seeing that Virtual Store is not being used.

Based on this information, we realized that we are not getting access denied when we are trying to write to C:\

As mention above in the UAC policy we should have a write failure to start the virtualization of file and registry. Without having a write failure on C:\ the Virtual Store functionality will not work.

So we have given Full Control to the user on C:\ and we have verified that the Virtual store will not be used as the user has write access to C:\.

This would mean that the user can write the temp files to C:\, but still we get Access Denied from the application.

There is another security feature at work here:

As we are trying to write to %systemroot%, the operating system will protect itself, by implementing Windows Integrity Mechanism.

Windows Integrity Mechanism is a functionality to ensure that a lower privileged process can´t alter system configuration that are critical for the operating systems.

Integrity level assignment

Integrity Level

Example Processes

Low Mandatory Level

Protected Mode Internet Explorer and processes launched by Protected Mode Internet Explorer

Medium Mandatory Level

Standard user and non-elevated AAM processes

High Mandatory Level

Processes running with administrative rights

System Mandatory Level

Local System, Local Service, and Network Service processes

Based on this information we came to the conclusion that we had two processes, the ActiveX Component running in a Low Mandatory Level and the scanning application running at a Medium Mandatory Level. These applications are trying to write their temporary files to C:\, which is %systemroot%. %Systemroot% is containing several system critical files that is needed for the operating system. This means that you will need High Mandatory Level Integrity Level permission to be able to write to C:\

More information about Integrity level can be found here:

So the actual issue is that the operating system is protecting itself from having critical operating system files being altered.

Based on this information we realized that the NTFS file and folder permission are evaluated first in the perspective if the UAC configuration about Virtual Store should be used and then the Windows Integrity Level will verify if it should allow a write to %systemroot%.

This is the actual issue on why we get Access Denied even though we have given the user Full Control on C:\. The operating system is trying to protect itself from being compromised by a low privileged process!



So how did we get the application to Work?

By giving the user Read Only to C:\ we get the expected Access Denied on the write attempt on the expected C:\ folder that the application wants to do. Hence the Virtual Store will be used and the temp files are written to C:\Users\user\AppData\Local\VirtualStore, where the user has write access.

So the correct NTFS Permission for these application would be

So by giving less permission on %Systemroot% the user will get the permission to write the temporary files to the Virtual Store and the application will work again.