I'm using D2010 under Windows 7 to write an app that seems to require admin rights (I think because it uses COM to communicate with a third party .exe, which also requires admin rights).
I've added the manifest resource as required, but when I try to debug the app from the IDE, it reports
"Unable to create process. The
requested operation requires
elevation"
...and it won't run. If I run Delphi as administrator, then my app runs correctly, but this feels like a dangerous brute force approach, especially as most of the apps I develop don't need admin privileges.
Is there any way of getting Delphi to prompt for elevation just when I run my app, rather than having the whole IDE run elevated?
UAC also catches any application that has the words "setup", "update" or "install" in their name or in many of the Version Resource fields. (Company name, App Name, Description etc.
It considers any such application to be a potential "installer" application and therefore must be run with Admin privileges.
Sounds crazy, but it's true. See the "Installer Detection" section in this document.
You can get around this by including a manifest that says that it doesn't need admin privileges.
There is none, it also doesn't work for VS:
https://stackoverflow.com/questions/3265787/how-do-i-debug-an-process-as-elevated-with-visual-studio-2008-sp1-on-windows-7
I guess you could run the remote debugger elevated and attach the IDE using remote debugging though.
It doesn't work, because the process is running as another user (or using another user token).
The IDE is trying to run the debugging process using CreateProcess and that fails when the application requires elavation, more details can be found in this article:
http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx
RAD Studio could run the application using ShellExecute with the "runas" verb, but this still doesn't solve the "debugging process under other user context" issue.
In other words: An elevated process can only be debugged by an elavated debugger.
Edit:
The Delphi XE2 IDE is 32-Bit and can debug 64-Bit applications only through the remote debugger (which is cleverly hidden from the user).
I guess Embarcadero could make it possible to debug elevated applications in a similar fashion.
The only way I know to debug such an app is to run the IDE as administrator. I wouldn't recommend doing this routinely, just for debugging sessions.
Actually it may be possible to debug a process with "higher level access" from a process with "normal level access".
At least until Windows XP it is sufficient to add your user account to the Debugger Users group to debug processes running e.g. with Administrator privileges.
That doesn't solve Delphi 2010s problem to run the process at all, but may be useful if you try to attach the debugger to a already running process.
I don't think this works on UAC enabled Vista+, but I thought I'd mention it anyway. :)
To be exact the UAC split token concept disables the SeDebugPrivilege:
http://blogs.msdn.com/b/greggm/archive/2006/03/30/565303.aspx
http://blogs.msdn.com/b/mithuns/archive/2006/04/04/568291.aspx
Run Delphi (any version) as Administrator.
You can change Delphi shortcut properties also (to run it always as administrator).
Related
My Win32 Delphi application icon is receiving the "administrator shield" on a specific Windows 7 computer despite the fact that:
I'm not using the application manifest that requires administrator access
the application name doesn't include any words like "setup", "install", or "update"
the application doesn't have "run as administrator" selected in the shortcut properties for the user, "all users", or in the advanced properties.
Fortunately, this is a very rare situation. It, however, is experienced by a customer who is very far away.
this came to my attention because the runtime library TPath.GetTempFileName method is raising an exception "The directory name is invalid". when running a test application (not as administrator), the temp path is available and R/W access is available. don't know what happens if the test application is run as administrator.
I have mused that maybe it was installed by the administrator or that the UAC settings on that computer are very strict in some way.
It is an older version of my application but I don't like the fact that it is not understood what the problem is.
Being an old version of the application, I'm not inclined to dig deeply to solve this; in a way, it has been solved but I'd like to understand why.
Only looking for quick answers here--not an in-depth community effort.
thank you!
I have a single executable which, via InnoSetup, installs into Program Files\FolderName by default. The exe has a 3rd party component which goes online to check for new versions and downloads them, then does a bit of fiddling to replace the exe - simple stuff. The problem is, it can't do this in Program Files because of the necessary security there. I was reading Windows 7 - Can't update my program's files in C:\Program Files in which David Hefferman gives a solution but then seems to say it's a bad idea - but I don't know whether the bad idea bit refers to his solution or to the OP's comments!
So what is the preferred method by which a program can update itself? One that will work on XPSP3 to Win8. I can't seem to find the right phrase to enter into Google that gives me relevant results. Ignore digital signatures and suchlike for now, for simplicity.
(Please note, it may look like I worded that as an opinion question but it's not - there must be some MS-endorsed way of doing it that I can't find. FWIW this is a Delphi program but any Win32 notes will do)
That 3rd party update utility needs to be run with administrative privileges, you can achieve that programmatically.
There is nothing wrong with installing your application in Program Files, that is the designated purpose of this folder. However, user data that is used by the application should be stored in a different location.
However you run that 3rd party Utility, you should first check the Windows OS version to see if fiddling with UAC is really necessary(Vista+...) and then run the utility in the elevated state.
He says its "extremely bad practice" to fiddle with your system so that normal users can write in "Program Files".
If your program is in "Program Files" it's installed with System Admin rights. So updates need also be installed with System Admin rights.
You can configure InnoSetup to request admin-rights so you can write to "Program Files" but if the 3rd party component does not do this its best to install everything in an other directory.
i.e. C:\Your_Program
That way your 3rd party component can write there.
There are several options here:
The easiest: make updater as a separate program with manifest, which requires admin privileges. Also you can ask for admin privileges when you start your updater. Or you can move your updater into out-of-process COM object instead of separate exe.
You can create hidden user with admin rigths during installation of your program. Then you will run your updater with credentials of this user.
You can install system service during installation of your program and this service will run from system account. So your updater will be implemented as a service.
I have and application that is running as a windows service on Server 2008. When I run it as an application and send a print job, the print job gets processed sucessfully. However, if I send the print job to the windows service instead, it throws "The Handle is invalid" exception.
Here is the error:
Printing Thread error: The handle is invalid. StackTrace: at System.Drawing.Printing.StandardPrintController.OnStartPrint(PrintDocument document, PrintEventArgs e) at System.Drawing.Printing.PrintController.Print(PrintDocument document) at System.Drawing.Printing.PrintDocument.Print() at GrapeCity.ActiveReports.Viewer.Win.Printing.PrintImpl.DocumentPrinter.<Print>b__1e()
The service is running under an administrator account which has admin permissions.
Any help would be appreciated!
A coule things to check:
Make sure that the user account that the service is running under has the proper printer installed under his account and that it is set as the default printer.
Make sure you're using the Print method in ActiveReports that explicitly does not show any UI.
Try checking the "Allow service to interact with desktop" checkbox on the service's property page from the Services control panel applet. Although you may not be showing any UI, the printer driver may need that capability.
Finally, just keep in mind that in general printing from a Windows Service is kind of flaky. Even Microsoft's documentation for System.Drawing.Printing has the following disclaimer:
Classes within the System.Drawing.Printing namespace are not supported for use within a Windows service or ASP.NET application or service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.
That doesn't mean it won't work, but that it is error-prone enough that Microsoft doesn't want to help us printing in this case. I suspect this is because the printer drivers from the manufacturers are not necessarily designed for printing from non-UI processes like windows services.
Roussul
It could be a permission or printer access problem. To check whether it is related to ActiveReports or not, can you create a separate app, implement system.printing.drawing and run it as a service, just as you have it with ActiveReports and let us know.
I had this issue in a ASP.NET application. The root cause was that "Enable 32-bit applications" had been set in the IIS application pool that the website was running in.
It appears the print function tried to connect to a 32 bit driver rather than the 64 bit drivers that were installed.
Maybe in a .NET Windows app the "Target CPU" setting could also cause a similar issue? ie if you target x86 and try and run your app on x64 it will only connect to 32bit printer drivers?
I found interesting problem with Win7/X64 machine.
For this time I haven't got problem with Delphi 6 and UAC.
The exes are working in their's place, so I can use Delphi debugger with them.
But today I got error on run the project: "Unable to create process. For this operation you need higher user level".
How can I prevent this side-effect?
What causes this?
I don't understand why the older projects are running fine, but this new isn't...
Thanks for every idea, link, information!
Additional info:
Normally I using the Delphi 6 IDE with normal starting (without SysAdmin rigths).
So it is never asking me with "really?" kind UAC questions.
And every of the older projects are usable with Delphi 6 - I can build, run, debug everything.
This problem happened with only this project, so I try to find the differences if possible to solve the problem.
I using normal directory ("c:\dev\anyproject"), others are using "c:\dev\otherproject1..2..n").
Does your application request elevation when started from Windows Explorer?
Does it have a manifest?
The name of the exe, like setup.exe, could also trigger elevation. See an outline of the Installer detection technology.
Non-elevated process can't debug elevated process.
If your application requires elevation at the start, then you would need to run the IDE elevated to be able to debug it.
Starting your IDE as an administrator should solve the problem (option in the context menu).
If not, you could always disable UAC while developing.
There is a number of limitations that needs administrator's rights.
For example: you cannot write data directly into program files directory.
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".