UAC Prompt / Installer Detection / Filename Cached? RRS feed

  • Question

  • Hi All...  We have a legacy c++ 32 bit application.  We found that when we ran it on Vista (UAC enabled) as a standard user the UAC prompted us for an administrator password.  Furthermore, we found that this was happening because Vista (wrongfully) determined this application to be an installer and therefore required Admin rights to run it.  We corrected this by embedding an appropriate manifest in the executable.  This is fine.


    However...  We now find that in order to get around that prompt, we also have to change the name of the executable.  It appears that our Vista test machine has cached the name of the executable - from when it didnt have a manifest... - so that now even if it has a manifest, it still prompts.  If we change its name, it runs fine.  How can I clear the name of this executable with Vista?




    Saturday, December 6, 2008 3:41 PM

All replies

  • If it's an embedded manifest, there sholdn't be an issue with caching; did you embed the manifest incorrectly?


    You used a requestedExecutionLevel of asInvoker, correct?

    Monday, December 8, 2008 7:25 PM

    Thanks, David.  Yes, I believe the manifest is properly embedded and yes, I'm using asInvoker.


    The problem I'm having is only on the one Vista machine - the one where I had the original problem.  If I put my executable on any other Vista machine, it works fine.  If I put it on this one machine, it prompts for an admin.  But if I simply change the filename, it works fine.


    So Vista somehow remembered the original filename and is going to prompt for an admin even though the manifest is present.


    Monday, December 8, 2008 7:30 PM
  • This is a common problem with 'side by side' manifests (asdf.exe + asdf.exe.manifest) but doesn't usually happen with embedded manifests (the act of embedding the manifest means you changed the file, and thus the time stamp on the file must have been changed).


    Did you tweak some 'compatability settings', by chance?

    Monday, December 8, 2008 11:19 PM

    Yes, we embedded the  manifest.  This particular application is built with Visual Studio 2003 - which does not automatically embed a manifest.  After it builds, we use VS to open the EXE and import an RT_MANIFEST resource.  The content of the manifest we embed looks like:


    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urnTongue Tiedchemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <v3:trustInfo xmlns:v3="urnTongue Tiedchemas-microsoft-com:asm.v3">
        <v3Tongue Tiedecurity>
            <v3:requestedExecutionLevel level="asInvoker" uiAccess="false" />
        </v3Tongue Tiedecurity>

    Interestingly however, today it looks like the problem cured itself.  : (  It no longer shows the shield.


    You mentioned it's more common with side-by-side manifests - what do you do to fix it in that case?


    Regarding tweaking...  I'm told we did fiddle with a couple of propeties on the file including XPSP2 compatibility and Run as administrator.


    Thanks again for your help David.  Even though the problem is solved, we'd sure like to have a better understanding.


    Tuesday, December 9, 2008 3:05 PM
  • I've also found out that this machine had a third party product, RegCure run, though it's not clear when it was run wrt this problem disappearing.  It's quite possible, this product cleaned something up in the registry that affected this issue.




    Tuesday, December 9, 2008 4:34 PM
  • What I should have said is, I don't think it's a caching issue. (for the stated reason - the act of embedding the manifest updates the executable, and thus the modification time, which seems to be the work-around for side-by-side manifest caching issues.)


    Assuming the manifest was embedded correctly, I think something else was probably causing your problems, like that 'run as administrator' compatability setting.  I'm not sure which takes precedence (probably the setting).

    Tuesday, December 9, 2008 11:50 PM