I have created a small vb6 application which edits the registry in HKLM hive. It makes use of function RegSetValueEx. But when run the exe file in windows 7 and windows 8 pc it does not edit the registry even if run it in administrator user.
In windows XP it works fine.If i run same application as "run as administrator"(by right clicking exe and then run as) in windows 7 and 8 then it works properly.I think the windows 7 and 8 id designed to work like this only. But is there any method i can edit it without running as administrator? Or is there any code in vb6 which does the same.
Here is my small code
Important:
When checking the code create exe and then run the exe and click on button(HKEY_LOCAL_MACHINE\SOFTWARE\Demo registry gets added in wow32 node because vb6 is a 32 bit appliaction).Running the code directly by opening code allows the registry to change.But creating the exe and then running it gives the problem which is the real time scenario in any application.
Microsoft has been warning developers since Windows 2000 that access to the HKLM branch of the registry should not be performed as normal user, as it will sooner or later be restricted to administrators. They also said you should not write to Program Files.
They didn't enforce that rule until Windows Vista, so nobody felt the need to change anything.
Now you have it: don't write to HKLM as normal user - it doesn't work. Don't write your settings to Program Files. It doesn't work.
Application run by the normal user may write their data to user folders and user hives in the registry, nowhere else.
If your application's sole purpose is to write to that value in the HKLM hive then you will need to add a "requiresAdministrator` manifest to the executable, causing Windows to prompt the user for admin access every time it's run.
If this is a small part of a larger project, then you should use COM elevation or just run a small stub executable with the manifest above, allowing windows to only prompt when it's required.
If your application doesn't require admin access at all then you should stop it trying to write to admin restricted locations, and instead use the user's own HKCU hive.
Related
I'm a programmer not an admin. I significantly modified an old program written in 1997 to run under Windows XP ~7 years ago. At that time, I rewrote in VC++ 2005. The local production network has been updated to Win7. Program updated to VC++ 2010.
Problem: Program runs in new environment but only if user has admin privileges. Without, needed files cannot be accessed. Attempted Fix has been to give user group access to the needed files. Users can access the files "by hand" but program still fails.
Is there a way to give the application admin privileges so that it can access the files?
Not acceptable is allowing users to run as admin. We have to operate under DoD constraints. Is there something I as the guy working on the application can do? If not, what is the solution?
Recap: problem was a large number of scratch files which, in the original application, were being written to the C:\ root directory. The solution was to use "getenv_s" to obtain the user's directory via an environment variable. The pathname was modified such that the string returned from "getenv_s" was concatenated with the scratch file name. Laborious but problem solved.
The huge difference between XP and Windows 7 is the access system (user access control entered with Vista and was further refined in 7). In theory you could run the application as an admin user, or provide a service that would access the necessary system components and files as an admin user. But there isn't a way of giving an application itself extra permissions.
Your other option is to find out what specifically is causing the problem and correct that in your application. Chances are this is a system file or the like.
I have a puzzling situation with the Inno Setup FileExists function.
Here's the situation. I have three networked computers with like WORKGROUP names.
1) Windows 7 32-bit
2) Windows 7 64-bit
3) Window XP Service Pack 3
1) and 3) have been setup as servers with read-write shares, ex. ShareExe and ShareData
The problematic Inno Setup creates shortcuts to the executable in the ShareExe folder. It asks the user for the ComputerName of the server and then uses FileExists to verify correct input.
Running this setup on the XP (3) machine and specifying 1)'s computername works just fine, however when running the setup on the Win7 64-bit PC and specifying the same ComputerName as with XP, causes the FileExtsts test to fail.
Strangely, I can go to Network Places and open the ShareExe folder and successfully run the executable. My question is, "why does Inno FileExists fail only on the Win 7 64-bit machine?" I cannot find anything in the reference materials that suggest any version differences with FileExists. (I also tried FileSearch with the same results).
TIA
In Windows 7 (and Vista) with UAC enabled, by default network credentials and drive mappings are not shared between admin and non-admin contexts, even for the same user.
By default, Inno elevates to admin permissions (via PrivilegesRequired=admin), since most installations must (and should) be performed per-machine by an admin user. However this means that any credentials prompted for or saved by Explorer when browsing for the desktop are not available to it.
When files are accessed directly by APIs (as with FileExists), Windows will typically try to silently connect to the server using the same username/password as was used to log into the PC; if this fails then it just reports an error since it has no way to prompt for alternate credentials at that point. So if you can ensure that the login details on both PCs are the same, then it should work. (You usually get this for free on computers connected to a domain, but not a workgroup.)
If that isn't possible, then something else you could try would be to force the access via a shell dialog -- if the FileExists fails, then use GetOpenFileName to prompt the user to find a specific file in that folder, using the same initial path. I haven't tested this, but I think this should result in Windows displaying a credential prompt and then you should be ok after that.
(If this is for an internal app, then another option is to disable the separation of credentials [via a security policy setting] or UAC entirely, though the latter isn't really a good idea. Of course this isn't tolerable for a general-release app, and it's cleaner if you solve it one of the other ways anyway.)
We have an application that is part standard EXE and part WinService EXE. The standard EXE is spawned by the Run section of the registry and comes to life at login under the credentials of the user who just logged in. The WinService EXE is set to Auto Run and therefore is always running and is running as LocalSystem (essentially administrator).
We need these two programs to share data by writing information to XML files.
The app works fine when the logged in user has access to the installed folder (C:\Program Files\ourApp). The Standard EXE writes the data and the WinService EXE reads it without issue, all is well.
However, when the logged in user does not have access to write to the installed folder, the data gets caught up in UAC Virtualization and Data Redirection and ends up somewhere else and the WinService does not find nor cannot read it from the installed folder.
To circumvent this, we tried having both the standard EXE and the WinService EXE write to and read from %ProgramData%. This would work fine except that standard users do not have permissions to write to %ProgramData%.
We cannot use %LocalAppData% because for the logged in user that would be C:\Users\LoggedInUser\AppData\Local and for the winservice it would be C:\Users\Administrator\AppData\Local.
Is there any place left in Vista and Win7 with UAC Virtualization enabled that will allow both a Standard EXE running with only user priveleges and a WinService running as LocalSystem to talk to each other. We tried the registry but the problems are even worse. Also last but not least. We need this to work with XP without any differences in code. Meaning XP also has environment variables for %ProgramData%, %LocalAppData% etc, can it work in both.
Two ideas:
Have each app expose a WCF endpoint using the named pipe
transport, and have them talk to each other over a simple interface
of your choosing.
Use Memory Mapped Files to communicate like
you were with disk files.
I have a console application written in c#, which downloads a file to program files. So of course it needs to run as admin. This program gets called from a Win32 C++ application which almost certainly is not running as administrator
What are my options. How can I get this to work on UAC and non UAC enabled boxes ( I don't know if there needs to be separate solution in each case )
Oh and the console app is in .NET 2.0
On a machine with UAC you need to include a manifest resource to specify that you want the process to run as administrator.
On a machine without UAC you will simply have to instruct your users that they need to run it as a user in the administrators group. Almost all users of XP (the version that you will most commonly encounter without UAC) are in the administrators group so you won't encounter many problems.
I never tried it, but this can probably be done using the
CreateProcessAsUser Function.
I have made an application that copy the vb components to the system32 folder of the windows and register those components with “regsvr32”. It works well in Window XP, but in Windows Vista and Windows7 it can’t perform its task without right clicking the application .exe file and selecting “Run as administrator”. Is there any code in vb that automatically allows the application .exe file to run as administrator?
To do precisely what you ask you can add an application manifest that specifies an execution level of "requireAdministrator" within it. However this means the application will always run elevated, and the user will also have to provide admin credentials or approve elevated execution for every run (UAC prompt).
Please just do things the right way.
I'm going to second Bob's excellent comment above and suggest that you use a tool like Inno Setup http://www.jrsoftware.org (it's free) to build a proper installer. One of the benefits of using a proper setup tool is that the setup application can request to the OS to run with administrative privileges without using external files and manifests to make that happen. The setup.exe that you build will have the necessary code built in to ask the OS for elevated privilege.
In windows 7, we can go to the properties of the file or an application exe file and then "Compatibility" tab. Then check the "Run this program as an administrator".
It will force the application to be executed under the administrator privilege.
I used this and my problem was solved.