Application will not behave under UAC even though it requires no privileges

Question

We have been having serious trouble getting an application we devlop running with UAC enabled for long.

Once installed (the installer fails almost immediately with UAC) it appears that UAC can be turned on and have the application work. However, after a while, it will stop working with strange errors about cannot find a file that it just created.

Just to get this straight:

XP as admin:          Fine  
XP as limited user:   Fine
Vista no UAC admin:   Fine
Vista no UAC limited: Fine
Vista UAC admin:      FAIL
Vista UAC limited:    FAIL

The software contains no privilege checks anywhere. If I understand the documentation correctly, anything working as a limited user should work with UAC; however this is proving not to be the case.

EDIT: I must apologize for asking a problem much harder than it originally appeared. We have in fact found at least one bug in folder virtualization and think there are more out there. At this point, the only reasonable hope to get it running is to find an API call that can be executed as a limited user that disables folder virtualization for the calling process and any process it spawns (recursively). The reason we cannot just add a manifest is that the software calls into third-party software that actaully can vary per machine.

Answer 1

Where is the application trying to write the file? If it is trying to write to it's install location under Program Files you may get strange errors since writing here is not allowed under Vista and any files created here are actually created in a virtual folder elsewhere - though to the application they (usually) appear to be where it expects them.

You may want to try running the application in XP compatibility mode.

Answer 2

Look up virtualization of the filesystem and registry on Windows Vista. If your app uses certain parts of the filesystem and/or registry you will find that your app "works" - that is, the APIs succeed with no errors - but that data isn't stored where you expect. In particular, many areas that would have been shared between multiple users on one machine are now out-of-bounds, and the data actually goes into some storage that is specific to the current user. You'll only find out some time later that users aren't actually sharing the same data.

There is a way to stop this Virtualization from happening. Provide a manifest file for your application to say that it knows about UAC, as described here... http://msdn.microsoft.com/en-us/library/bb756929.aspx.

It doesn't matter specifically what level of privilege you ask for in the manifest file. The mere presence of it says that your app understands UAC and the OS won't try to be clever and virtualize access to "privileged" areas of the filesystem or registry. API calls will simply fail if you don't have the necessary privilege to access those things, and that will be a lot easier for you to debug.

Answer 3

After all this time I found a solution that works.

1. Install somewhere else besides Program Files. This neatly sidesteps the filesystem virtualization that seems to be causing all the problems.

2. Disable virtualization on the application's HLKM registry key. this fixes the one remaining glitch involving system updates.

Reference material: http://msdn.microsoft.com/en-us/library/aa965884%28VS.85%29.aspx