My application installs some dynamic libraries in the {app} folder with uninsrestartdelete flag set upon installation. After uninstallation, these locked files are all written to the registry key PendingFileRenameOperations correctly. But on some Windows 10 machines, Windows just fails to delete these files and registry values on the next reboot. I have no idea what's going wrong. Even the OS itself doesn't have enough privileges to delete these files? Thanks!
Related
A few customers have an MSI installed on their system (servers and desktop's, winxp, win7, server2k8r2, server2012r2).
The MSI is created by a default VS2010 "Visual Studio Installer Setup Project".
There are 2 reg keys created with the installation.
HKLM\Software\Microsoft\Silverlight\AllowElevatedTrustAppsInBrowser = 1
HKLM\Software\Wow6432Node\Microsoft\Silverlight\AllowElevatedTrustAppsInBrowser = 1
When uninstalling, on some system's, the whole Software\*\Microsoft node gets deleted.
Anyone got an idea how I can solve this, without crashing the systems.
(This already happened a few times, but there are still a lot of installations.)
The zip contains an exe that install's requirements + certificates + MSI.
The MSI itself is in the IG folder.
There is also an install.log & uninstall.log (from windows 7 virtual box)
https://www.dropbox.com/sh/ku3vqoajfxbnluq/AACQ6evVw4pzRJ6WTzqCHR8Ba?dl=0
This reminds me of a similar incident ( using InstallShield instead of VS but both create MSIs )
InstallShield 2008 HOTFIX: COM Extraction Causes System Corruption during Uninstall
Your question isn't directly answerable given the information. I would need to evaluate the .MSI looking for custom actions, registry table entries and any self registering DLLs. An uninstall log file would help also. You might have to boot from recovery media to get to it but it should be there if you log the uninstall.
You should treat this as an emergency before many more clients are impacted. Investigate root cause and issue a patch so that customers can safely uninstall.
The only thing I can see obviously wrong is that you think you are changing the Silverlight registry entries in the native 64 bit registry and the 32 bit Wow registry. Your install is x86 and you can't do that. If you're going to alter that key in the 32 bit world you just use the normal registry path and an x86 install maps it to WoW6432. So you have got two different components uninstalling the same thing, one of them incorrectly addressing the WoW6432 location directly. I don't know if this could screw things up but it's plainly wrong. You need an x64 setup for x64 systems, and as a matter of customer security I would not change those policy settings without making it clear to the customer.
The only other odd thing is that you seem to be installing the uninstall.bat file twice. What's in it? If it uninstalls the app, what's wronmg with using Control Panel? And hopefully that's not got anything that might be responsibe, if users are running that to do the uninstall.
I have created a small exe and associated ini file that we use for diagnostics on customers sites. Customers can go to our website, run a configuration program which downloads the diagnostic exe and ini and sets the exe running.
We do not want to go through a full Windows installation for this as this is overkill for the customers who just want something that will load and start running in 10-15 seconds.
Where should we download this exe to and run according to Windows philosophy and where it is guaranteed to work? The following conditions are essential:
A customer doing this may be an administrator on the machine but may also be a basic user.
UAC may be switched on.
Also during the course of the procedure the user might change.
The exe also needs to be able to write to its ini when it first starts.
The OS could be XP, Vista, Win7 32-bit, Win7 64-bit
If there is one folder that covers all of the above then fantastic but I'd also be happy to use an appropriate different folder for each of the OS's named.
In the folder pointed by %APPDATA% environment variable which is inside the user profile directory (%USERPROFILE%), if it is supposed to be used by any user then %ALLUSERSAPPDATA% which is inside %ALLUSERSPROFILE%
Take a look at Recognized Environment Variables
I want to create a registry key in local machine hive in windows 7. I used the following code in order to do so:
RegistryKey regKey = Registry.LocalMachine.CreateSubKey(#"Software\Test", RegistryKeyPermissionCheck.ReadWriteSubTree);
the code runs fine without any error. but when I looked at my registy using regedit.exe I don't see the key that i've just created. can anyone help me please.
regards
Are you on a 64 bit machine?
If you are on a 64 bit machine, check your project Build settings (Project Properties > Build tab) and check the Platform target.
If the Platform target is set to x86, and you are on a 64 bit machine the key will be created under the 'Wow6432Node'
In regedit.exe look in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node and you should see your key there.
Change the Platform target to Any CPU and it will create the key in HKEY_LOCAL_MACHINE\SOFTWARE
In all likelihood your application is running without a manifest and is writing to the virtualized copy of HKLM. To test my theory, right click your exe and choose Run As Administrator. If it then writes to the correct area, this is what is happening.
If this is the issue, either change your mind about writing to HKLM (users don't like UAC prompts) or put a manifest on the exe that has requireAdministrator so that it will always request elevation and work properly.
What is the length of your key name? There is a known bug in regedit that wont let you see keys with names longer than 256 characters.
I'm probably just being very thick here, but it's not clear to me where I'm supposed to install 'new' user-specific programs on Windows 7 (and presumably Vista too, though I've not specifically looked at that scenario yet).
Under Windows XP (rightly or wrongly) we always installed our programs into folders under 'Program Files' and accepted that they'd be kind-of available to everyone. From what I can gather under Windows 7 I'm supposed to install my software under the user's AppData folder (possibly AppData\Local\MyApp). That makes a degree of sense, but the fact that this folder is 'hidden' by default means that we're going to have 'fun' talking our users through support stuff.
I want to install our software so that it's user specific (the Users bit in Windows 7 makes perfect sense) but I do want the user to be able to access it if required. Our program also includes a 'data' subdirectory which it needs to write into while it's running (embedded database), but as the program is intended to be single-user/standalone, the data folder being inside a user-specific folder isn't going to be a problem.
My problem is just that whole 'hidden folder' aspect of AppData. As much as I've trawled the MSDN, I can't work out where else I'm supposed to install user-specific programs. Taken one way it would seem to be something like AppData\Local\MyApp, and another way it would seem to be just as valid under the user's My Documents\MyApp equivalent.
Has anyone got a clear guide for where all this stuff goes? I found the MSDN docs confusing. :-)
Not really.
The directory that serves as a common
repository for application-specific
data for the current roaming user.
AppData is, surprisingly, for application data, not for installation (Click Once/Silverlight applications aside). You can, and should still install into Program Files, just don't expect to write into that folder.
You can install software into AppData if you want it to follow a user about in an Active Directory environment, which happens if you put it in AppData\Roaming (the SpecialFolder.ApplicationData location).
You can also install into AppData if you want the software to be available to just the user that installs it. This can be useful if, for example, you have multiple users on the same machine, who all want to run different versions of the software in complete isolation.
If you want settings to only apply on the local machine then you use AppData\Local, which is SpecialFolders.LocalApplicationData - this will make AD administrators very happy as the roaming profile size won't suddenly jump up 50Mb or whatever the size of your software is.
If you wanted to create settings which apply to all users then you're looking at SpecialFolders.CommonApplicationData
You should remember never to rely on the actual name of the directory - localisation issues mean this can change and the location does change with OS versions two. You should be using the special folder enumeration in your software, or the equivalent in your installer.
Could you not install into Program Files, but use AppData as it's supposed to be used, and store your database in there?
Windows 7 added the FOLDERID_UserProgramFiles known folder and by default this maps to %LOCALAPPDATA%\Programs. This is used by MSI when ALLUSERS=2 & MSIINSTALLPERUSER=1.
On Vista and earlier there is no canonical per-user application folder but just using %LOCALAPPDATA% is pretty common. Sadly MSI will just use %ProgramFiles% on these systems.
It's 2019, and I just installed Visual Studio Code (a Microsoft product) in the default folder of
%userprofile%\AppData\Local\Programs\Microsoft VS Code
This is probably for getting around the requirement to have an administrator or UAC prompt authorise the installation
Windows 7 folder structure is deeply inspired on Unix structure:
/usr/ -> C:\Program Files\ -> binaries: executables and dynamically linked
/etc/ -> C:\ProgramData\ -> global settings
/home/ -> C:\Users\ -> a folder for each user
~/.* -> C:\Users\Hikari\AppData\Roaming\ -> settings for each user
Windows has more folder, like My Documents for files with content produced by user, AppData Local and Roaming (which Unix usually handles with NFS).
It's about time for us developers to start using these structures. We must separate at least binary files that don't need to be replicated, global and user settings.
When a setup is installing an app, this setup should expect to have permission to write on Program Files. Once the setup is finished, Program Files should be writable only for other setups aiming to update binaries to other versions.
Please install executable files to the %programfiles% folder in Windows - a simple MSI based install package can perform an active setup for any new user who logs onto the machine to create the user specific files and folders in their profiles %appdata% folder. You see this behaviour for Internet Explorer, Adobe reader, etc. - It's the little MSI installer window that pops up the first time you log onto a machine which has those applications installed. - Thanks - a system admin :)
My opinion, for what it's worth, is that user-specific program files is just asking for trouble and is a damn stupid thing to do.
A much more sensible approach is to install different versions of your program to:
\Program Files\Your Program\Program_v0.1\Program.exe
\Program Files\Your Program\Program_v0.2\Program.exe
\Program Files\Your Program\Program_v0.3\Program.exe
\Program Files\Your Program\Program_v0.4\Program.exe
I would then place a bootstrapping launcher at:
\Program Files\Your Program\ProgramLauncher.exe
Then, the user application data folder will only contain data, including an INI/XML/Settings file that indicates the version of the program that this user is working with.
Such an approach satisfies the core tenant of keeping data and executing code separate, allows every user to run a specific version of the code, and offers a small amount of de-duplication by ensuring the same executable code is not copied multiple times across user folders.
Otherwise, go right ahead with installing programs to AppData and undoing the years it has taken us to achieve clean separation of code and data. I found this thread because I noticed that Chromium and DropBox are installing code to AppData. I'm going to uninstall those program, and change the permissions on my AppData folder to exclude execution to ensure I can easily spot other programs attempting the same BS.
I have an app modified to take into account the UAC in VISTA.
So, now, the .mdb (JET or Access file) is located in ProgramData\MyApp\
I realized that when my app reads the database for the first time it is doing it from that location... but when my app is writting to the database... the file is virtualized and goes to Users\MyUser\AppData\Local\VirtualStore\ProgramData\MyApp. From this moment on my app always go to the Virtualized location in disk.
My app is working, but if I continue this way, the database would be in a per-user basis, and we really need sharing the database with all the users in the PC.
I thought that writting under ProgramData folder would't trigger the virtualization mechanism.
What I'm missing?
I need to set the permissions for MyApp folder under ProgramData??
How can I do that on Install time?
Thanks people...
More info:
Developed with VS2003 VB.NET using the VS Setup Project.
Most likely you'll need to set write permissions for all users during installation.
To test, delete the virtualized folder, manually set the permissions on the ProgramData\MyApp folder and files and see if that works.
As for how to do that pragmatically during installation, that really depends on what technology you're using.
I have had trouble here as well, it seems vista once is decides to virtualize the file, the only way to stop it is to delete the virtual file.
The next time you use it, it will use the ProgramData folder.