I have a program that was written on XP. What I've found out is that it doesn't work properly on Win7 because HLKM is no longer writable by non-admins.
Essentially, when you register the program, the licensing information is supposed to go into the registry. That information is valid for everyone on the computer, not just the one user, so I don't want to put it in HKCU. But any copy of the program needs to be able to edit that registry (even if it's a non-admin running it), because there are certain situations when it's going to go get updated license information from my web server (for example, if the registry data is lost or damaged, or if your current license is expired and it needs to see if we've applied an extension).
It's not horrible if it goes out to the web server for every unique user who starts up the program, but it causes some annoying issues, so I'd rather it continue to work the way it did in XP. Is there a way to store data in the registry and still have it shared under Win7, or am I going to have to start looking at storing an INI file on the drive?
Here is how I would architect it: your setup runs elevated and sets up the key. Then if their licensing gets corrupted or whatnot, you enable a button or menu item that has text like "fix license" or "update license". You put a shield on that button or menu item. When they click it, you launch a separate exe using ShellExecute. That exe has a manifest that requires elevation. It can then write to the protected area of the registry. The rest of the app can have a manifest with asInvoker.
If you want it to be completely invisible, either the whole app must always run elevated (annoying) or sometimes the app will just launch another exe that asks for elevation without warning - in which case the smart users will say no. A little less invisibility is a good thing imo.
Could you get the installer to make your particular area of the registry to be writeable by everyone? The installer will need to be run with elevated privileges anyway, I'd expect - so this would seem an ideal approach.
Related
Basically I either need to Click the UAC button with my program(which i don't believe is possible) or somehow make it so I don't need to click the button to install the software. I will also need to click buttons during the install with my program but I know how to do that. I am only concerned with the UAC things.
One way or the other, the user is going to have to click that button to give you permission to proceed. That's the whole point of UAC, if there were a way to work around it, it would serve absolutely no purpose.
You can either ask for permission sooner (at the beginning of your installation) or later (at the point in the installation when the privileges are first actually required), but you have to do it one of those times.
The standard course of action is to embed a manifest in your application that indicates you require administrative privileges. The applicable line looks like this:
<requestedExecutionLevel level="requireAdministrator" />
Alternatively, you could choose to rely on UAC's "Installer Detection" functionality:
The first application compatibility technology that is part of UAC is called Installer Detection. Because most installers write binaries to the Program Files directory, they overwhelmingly need administrator privileges. Installer Detection is designed to scan the name and the resources of the EXE to determine whether an application is an installer. For example, an executable would be marked as an installer if the executable name or description contained the strings "install" or "setup". So an application named setup.exe, without an application manifest, would trigger a UAC elevation if launched by a token without administrator privileges.
Clicking buttons during your install isn't a very good idea, either. If this is an installer that you're writing, code in some "silent install" flags that you can specify when executing the installer app. If this is a third-party installer that you're using, check the documentation; chances are such flags already exist. The point of these flags is that interactive UI is not displayed at all during setup, meaning that no one has to bother clicking any buttons (which is very hard to get right).
you can install your program in the user's home directory or any other directories which is writable without administrator privilege.
if you're writing an installer wrapper, you can ask for UAC on the wrapper and the wrapper can start the real installer(s) with administrator privilege. Most installers also provides command line options for unattended installations, so you might want to check those instead of scripting button clicks.
You can't click button on UAC consent dialog.
Your other options depend on what you really try to achieve. So give us more details on the your task: there could be better design choices than clicking installer buttons from an application.
To avoid UAC, you can install a service which will start the installation. But user has to consent when you install the service.
I use Inno Setup as my installer. The installer failed to register a DLL. It turned out that regsvr32 failed with error code 0x80070005, which stands for E_ACCESSDENIED. When I opened "C:\Program Files\MyProgram\" in Explorer it showed some sort of a UAC dialog asking for elevated priviledges to view it. I noticed that all the files have a padlock on their icons. This is the first time I've seen this padlock.
I checked in Process Explorer and the installer was started from the regular user account (with elevated priviledges).
Update
I want to add that this error has so far only happened once. When I closed the installer and started it again (the same exact executable, I haven't made any changes to it), everything went fine and the files in the program's directory had normal permissions. This is not a consistently reproducible bug, more like a one in a million times bug, but if it's happened once on my machine, it likely has happened on users' mahcines too.
As it's reporting you don't have access to that folder (and in turn those files). Check the permissions as this is NOT the default state and must have been explicitly changed.
In matlab, I used a windows standalone application. There is a line in this application that writes a file in C:\...\...\. When I run the output exe file produced from this windows standalone application, the exe doesn't write in C:\...\...\ neither tells me that there is a security issues in that partition. All the execution does is nothing. But, when I right-click and run the exe as administrator, it runs correctly.
I want to do it without right-click and run as administrator. Are there is a command in matlab that can do that?
If you create a shortcut to your application, you can go to the Properties of the shortcut, click on Advanced in the Shortcut tab, and select "Run as administrator". That way, whenever you start the application from the shortcut it will be run as an administrator.
(Disclaimer: applications really shouldn't "foul their own nest" by writing into Program Files. This is bad design.)
Starting from Vista, unprivileged processes are not allowed to write to protected folders such as Program Files, because Program Files is designed to store code and not data. However, since this limitation has not been enforced in XP, MS has provided a backward-compatibility hack in the form of Virtual Store. Now, when a program tries to write to protected folder, its output is being redirected into a dedicated folder. This way, the program still "thinks" it writes to its usual location, while in fact it writes to an unprotected location. However, when you later check the Program Files location, you might not see the file - because it's not really there.
You can find more details here: User Account Control Data Redirection.
If you are administrator, add full control permission for your username to the destination folder. You do that by right clicking on the folder, going to properties and then security tab. Then edit and add you username with Full Control rights. Then you don;t have to run the the program as an administrator.
There is no way you can elevate a process once it is started, so Matlab cannot possibly have a command for that. Just running Matlab elevated.
I am working on a Windows application which needs to be able to update itself. When a button is pressed it starts the installer and then the parent application exits. At some point during the installer, the installer attempts to rename the directory that the parent application was running from and fails with "Access Denied" If you run the installer from the desktop it works.
I am using CreateProcess to start the installer, is there some way of using this or another API to create the installer completely independantly from the parent application so that it doesn't retain some attachment to the directory.
I'm not convinced that launching the installer separately will solve your issue. It sounds more like a permissions problem that you might be able to solve using ACL manipulation. If the app doesn't already have permissions to mess with that folder, you might be able to write a custom action to remedy the problem by adding the necessary permissions to your process.
Another way of doing this is to make sure that the directory deletion is happening within a custom action that you control (as in, you own/maintain the code that performs the deletion, rather than rely on MsiExec to do it for you). Then, set that custom action to run in the System context so that it will have the same permissions as a service. That should provide your installer with sufficient rights to remove the folder.
You should use the normal update system within the windows installer.
your access denied message appears because file/directory is in use.
renaming directories isn't also not a good idea.
what happened if the user clicks "repair" or "uninstall" ?
you can start the msi with shellexec. after that terminate you app immediately.
you should check that in the msi that your app is NOT running anymore.
do the update. if a file is in use the installer automatically wants to reboot to replace the stuff.
CreateProcess should work if you are passing it the right parameters. Don't reference the parent process in any way and set most things to NULL. If that doesn't work, then you can try WinExec().
Does anybody know if there is a feasible way on Windows XP to programmatically create and configure a user account so that after logging in from the console (no terminal services) a specific app is launched and the user is "locked" to that app ?
The user should be prevented from doing anything else with the system (e.g.: no ctrl+alt+canc, no ctrl+shift+esc, no win+e, no nothing).
As an added optional bonus the user should be logged off when the launched app is closed and/or crashes.
Any existing free tool, language or any mixture of them that gets the job done would be fine (batch, VB-script, C, C++, whatever)
SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon has two values
UserInit points to the application that is executed upon successful logon. The default app there, userinit.exe processes domain logon scripts (if any) and then launches the specified Shell= application.
By creating or replacing those entries in HKEY_CURRENT_USER or in a HKEY_USERS hive you can replace the shell for a specific user.
Once you ahve your own shell in place, you have very little to worry about, unless the "kiosk user" has access to a keyboard and can press ctrl-alt-del. This seems to be hardcoded to launch taskmgr.exe - rather than replacing the exe, you can set the following registry key
[SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe]
Debugger="A path to an exe file that will be run instead of taskmgr.exe"
I guess you're building a windows kiosk?
Here's some background in replacing the windows login shell - http://blogs.msdn.com/embedded/archive/2005/03/30/403999.aspx
The above link talks about using IE as the replacement, but any program can be used.
Also check out Windows Steady State - http://www.microsoft.com/windows/products/winfamily/sharedaccess/default.mspx