We've got a VB6 application that reads a simple text file with a .LIC file extension. When everything is working correctly, if the file exists in the same directory as the executable, it reads it. If not, it does other stuff.
I've got a customer with Windows 7 machines, and if he right-clicks the EXE and "Runs as Administrator" it "sees" the LIC file. If he runs the EXE as a basic user, the LIC file cannot be seen.
I've had enough issues with UAC to guess that UAC is running the application from a virtual directory of some sort and that's why the LIC file isn't seen. My customer swears he's turned UAC off.
Anyone have any pointers for me? It would be great if there was a way to tell UAC "let this app do what it wants in this directory". That's out of my expertise. I've been Googling till my fingers fall off, and I can't find the right answer.
Thanks!
If you think virtualization is happening (which would cause it to look somewhere other than Program Files), give him a manifest file called foo.exe.manifest where foo is your executable name and have him put it in the same folder as the exe and the .lic file. This manifest should set the required execution level to asInvoker. This will suppress virtualization and so you can rule that out as part of the problem. He may then get access denied errors but that will help you sort out the problem.
It could also be permissions? If the user is not logged on as administrator, then your program may not have permissions to read the ".lic" file. Have you checked whether the user can open it in Notepad? Is it possible your code might be trying to open it with read/write permissions, which is even more likely to fail?
You may need to change your install so that it lowers the permissions on your apps installation directory.
Related
I've written a Win32 program that at regular intervals retrieves content from a dedicated server on the internet.
Sometimes the Win32 program itself needs to be updated. What I do is exit the said program and run a download-program which replaces the main exe I need to uopdate. This works for users running in Administrator mode but not other mode that has sufficent rights for most tasks. The program runs on it own directory which is not under "c:\Windows\program files\".
I've set a manifest file to no avail.
Is there a workable workaround solution for this (any)?
For security reasons you cannot place files in Program Files without admin rights. If you would be able to this you could in theory change Windows files and place malware as well.
Same goes for Linux and OSX systems.
However you could prompt the user for an Administrator password and gain the admin rights in that way.
You need your updater program to have admin rights. You achieve that by adding the requireAdministrator option in the requestedExecutionLevel section of the application manifest. You said that you have tried this to no avail. Well, you must have got something wrong because this is the solution. You just need to persevere until you get the manifest correct.
I presume that when you say that the [program is not under the Program Files directory you refer to the updater. If the program being updated is not under the Program Files directory then there would seem to be no obvious reason that the updater needs admin rights. If that is so then you need to investigate further.
I ran into a problem after creating a screensaver that requires writing to a file located in Program Files. When the screensaver becomes active it can successfully read a file from there but fails to write to a file.
I noticed that when I use and elevated command prompt to run the screensaver, with /s, the screensaver successfully writes the file. So I assumed this was a permission problem.
To see if it was a permission problem I went in and changed Program Files and the subfolders permissions so that anyone and system could read and write, but it still didn't help.
Any idea what I should do? Is there a way to force a screensaver to run as admin? Or did I miss some important permissions?
You can't get the system to start screensavers with elevated rights. If that were possible then it would be a truly bone-headed security and design flaw. Screensavers should simply not be writing to Program Files or other restricted areas. You will have to find a different location to write this file.
We have a program that the installer checks for the existence of a config file, and if it exists, it doesn't copy that file over (it assumes the user has modified their config file and wants to keep those modifications). Unfortunately, this is a pre-Vista application and it keeps the config file in Program Files. The problem is, if you manually wipe out the directory when it re-installs certain API still thinks that there is a directory there. VB6, for example, and its browse for file dialog sees the folder, however explorer, cmd shell, etc cannot see folder. Writing over the file still leaves the old file there (to some API's, but not to explorer) which cannot be removed except form within the Browse for File dialog.
What is going on with these Phantom folders, and how do we delete the file so that all API's see the same thing? Maybe it has something to do with TxF, or the indexer for search, but both the installer we use (InnoSetup) and parts of the application (the parts written in VB6) are seeing the old version of the file, and everything else sees the current version.
As Oskar Duveborn said, it's very likely that what you're seeing is Vista's virtualization behaviour.
When a machine has User Account Control (UAC) enabled, standard users and non-elevated programs aren't allowed to write to the Programs folder. Windows instead silently redirects files to the appropriate subfolder of %AppData%\Local\VirtualStore (for example, C:\Users\MyUser\AppData\Local\VirtualStore).
If you browse the real folder in Explorer, you'll see the 'Compatibility Files' toolbar button, which you can use to browse the virtual store instead.
Note that this is only compatibility behaviour from Windows - your program should write to its own subfolder of %AppData%.
For more information, see this TechNet Magazine article.
Dunno if I'm on the right track, but doesn't Vista virtualize %programfiles% for applications that tries to write to it or otherwise are flagged as "not going about this the right way"? (and hence moves it somewhere into the user part of the filesystem instead, without telling the legacy app about it - making it kinda transparent)..?
Virtual Store Redirected files are stored somewhere in %appdata% - you can also find out the location by checking the "Compability Files" option in Explorer when at the aliased location. You need to stop writing to %programfiles% to get rid of this behaviour as far as I know.
Do you mean the AppData folder (C:\Documents and Settings\UserName\AppData)? I'm not on my vista machine, but I think that's the path, and afaik it's not wiped after an uninstall.
The TechNet link by Ant above (accepted answer) is no longer valid. The new link is:
http://support.microsoft.com/kb/927387 - Common file and registry virtualization issues in Windows Vista
This is a strange one to me. Let me list the setup:
Application with a manifest (ie: wont get pushed to virtual store)
UAC is turned on (can't write to other program files directories, or other areas, and uac prompt appears)
Can write to "c:\program files\%app_name%\%directory%\" both from within my application (not run as admin) as well as a non admin command prompt
Can not write to "c:\program files\%app_name%\%directory%\%subdirectory%\".
Any ideas? Are there hidden permissions or registry settings somewhere? Could it be that this directory was created when UAC was off, so now its fair game? Could it be that this directory was created in a time of XP, and its fair game?
It makes sense to me why i can't write to the other program files directories and the subdirectory. However I have no idea why i am actually allowed to write to the %directory%?
Side note: If I move the %directory% to another area (appdata), I still can not write to the subdirectory (confused).
Let me know any ideas you may have or anything I can check.
Thanks
EDIT: Arr, sorry, I skimmed your post a little too fast, looks like this is a non-issue!
Have you looked where the written files are actually going?
Vista has a feature where files written into Program Files folders by applications get redirected to a local per user store. This store is located at %userprofile%\AppData\Local\VirtualStore
This is to allow legacy applications which wrote per user settings to Program Files to still operate correctly, also allowing multiple users to use the program without conflict.
There's a button in explorer called 'Compatibility Files' which will take you to this user store.. perhaps your writes are ending up there?
I'm not sure why you cant write to the subdirectory though. Security permissions?
I have a vb6 application. I am unable to carry out the following on a Windows Vista machine:
Register a .DLL from the Users directory
Start another .EXE
Write to a file in the Users directory.
How can I overcome these issues?
This is by design. Software is supposed to require admin rights for installation (including update/upgrades). You got away with it in XP because so many people ran as administrator. If you're registering a dll after installation, you're doing something wrong.
You should be able to do this without issue, but only with the same rights as the user that the current app is running under. What is this exe trying to do, and would a standard user normally have those permissions?
What specific folder in the user's directory? Again: a user should have write access to most of the their own profile, but not necessarily as much outside of that as you think.
You have access to write to the c:\users\ directory. Going to another users directory is a bit of a security problem that you're not going to work around.
As far as registering an assembly from a users directory... There is a directory under c:\users\\AppData\Local\assembly which you should have access to for temporary assemblies
Starting another exe is trivial... As long as it's installed in the normal \program files.. path.
It really sounds like maybe you need to reevaluate how your application works.
Some suggestions:
Move to Reg-Free COM where it can handle things (i.e. not for ActiveX EXEs, DCOM).
We'd need more information. This should be no problem unless there are permissions issues.
Users are not supposed to be creating files outside of their own profiles, CommonAppData, and application-defined locations (often on non-system drives). More information is required to give any really useful answer.