We help IT Professionals succeed at work.

Embedding a manifest in a Delphi 7 app. to elevate Vista priveleges

RetroRocker asked
Last Modified: 2012-06-27
  I have been trying to embed a manifest into a Delphi 7 application which elevates the priveleges to "administrator" without the user having to right click and 'Run As Administrator' on Windows Vista. The program has to have access to particular folders and the registry to operate correctly ( as do most :).
The manifest is :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <requestedExecutionLevel level="requireAdministrator"/>

My .RC file for this is simply :

1 24 "UAC.manifest"

... and the whole basis of this is the excellent article by Aleksander Oven at :


Unfortunately it fails to elevate. Can anybody help me with a reason why ? Perhaps I have to use RT_MANIFEST instead of "24" ? Maybe the manifest is incorrect ? (should 'UACAwareApplication' be replaced by the name of the application executable) ... don't think so but ...

thanks and best wishes

Watch Question

How exactly is it failing to activate? When a user runs the app does it ask for Admin credentials?



Johnjces : OK, this app. on running requires that it can write a configuration file to the user's appdata folder which is restricted by Vista unless the app. is 'run as administrator'. In actual fact the file in question is none other than pdoxusrs.net (the BDE network config file). The program implements this location because ordinarily this file would be in C: root which is Vista restricted (OK in that case maybe I could just let it write to C: root in any case but that's another story ;-). There is also access required to the HKLM registry branch, another Vista restriction.
  Simply starting the app. in an admin account does not allow any of these requirements so an exception is thrown. If 'Run As Administrator' is used, then all is well and it runs fine. Using RAA is a bit like a sledgehammer to crack a nut in this case but for now it has to suffice.
  My contention was that embedding the manifest as above would 'emulate' the RunAsAdministrator option as I concluded (perhaps incorrectly ?) from Aleks Oven's article.
  Embedding the manifest and not using RAA throws the exceptions, then using RAA results in the app. again running fine - it's as though the embedded manifest has no effect.
  I am embedding the manifest in the app's. main form immediately after the {$R *.DFM} directive which is logical to me and the resource is definitely being linked ... but does not work as expected.
  Any ideas as to why this is will be genuinely appreciated ... thanks


I should probably add, to make it absolutely clear, that when the app. is not RAA the app. throws the exception because it is not being allowed to write. There is not a UAC window in this case. When RAA is used then I get one of the 'aggresive' style UAC prompts 'an unidentified program requires access ...' and the app. has to be allowed. The app. is currently not digitally code signed, hence the aggressive prompt, but it will be soon which will improve the UAC prompting to be a little more pleasant. I don't think that not being signed though affects the core issue of 'Run As Administrator' in this case ... unless of course anyone know better ...
This one is on us!
(Get your first solution completely free - no credit card required)


Johnjces : I definitely do not feel abandoned, quite the opposite in fact, your detailed response is certain testimony to this ! Understandably I have been working on this while you were away and I came up with an exact same set of solutions. I researched the privilege levels and indeed as you typed my app. was already deployed (BTW I use InstallAware) with the combined XP/Elevation manifest embedded because I needed both. To be honest, but I can assure you in no way disrespectfully, your reply at this point has not imparted anything new to me. However,  a bare few days ago it would have been virtually all I needed to know, so for that reason it is accepted as the solution.
  I say virtually, for this reason : This original app. committed (in Vista terms at least) a 'sin' in that it tried to write to HKLM during startup. As we know this is a no no, so the program throws an exception. That situation is for 'normal' ops. ie. admin account but NO RAA. RAA allows the HKLM write to happen. My contention is that a manifest containing "requireAdministrator" would be the same as RAA selected by the user but this does not appear to be the case and I have not unearthed why this is. Bottom line here is that I removed the HKLM dependency from the program (it was something of a legacy item which really didn't ought to be there anyhow) and of course the problem ceased. Now, I know the manifest works because the XP portion is visibly functional but I'm not over confident that the UAC/elevation is operational as well ... but there is not really a problem now so I'm going to leave the issue. It's just that academically a "requireAdministrator" manifest, IMHO should have taken care of the HKLM issue mentioned above, just like RAA does, but it never did ...
  Thanks for all the time and effort, genuinely appreciated !

No problem! Sorry it was late!

Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.