I'm trying to use this Visual Studio extension for 2013, which recreates the built-in installer functionality from Visual Studio 2008/2010: http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx?CommentPosted=true&PageIndex=2#comments
It works, allowing me to edit the project as before. It has the install and uninstall commands when right-clicking the install project, too. It installs fine.
When I try to uninstall, though, I get the following error and then the uninstall rolls back:
Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Wow6432Node\Microsoft\
EAPSIMMethods\18\FastReauthContext. Verify that you have sufficient
access to that key, or contact your support personnel.
I am not doing anything with that registry key, and there don't seem to be any relevant results on google-- at least not in the normal top 5 pages. Does anyone know what causes this or how I can fix it?
While I am not able to uninstall, I am able to increment the version of the package and allow it to remove the previous install and install the new version (all at once) successfully.
I am using Windows 8.1 Pro 64 bit, the projects are compiled for <AnyCPU>, and the installer is configured for x86.
EDIT I am running Visual Studio as Admin. When uninstalling from the Control Panel, I am also clicking the 'allow' button in the UAC dialog window that pops up.
I know how to give myself access to a registry key (permissions). I want to know why this key is trying to be removed. I support this app on several machines and I don't want to have worry about remembering an uninstall hack in the future.
EDIT This only seems to be an issue for a 32x installer on a 64x OS or a Windows 8 issue. I was able to use the same 32x installer to successfully uninstall the app on a 32x Windows 7 machine.
This must be an environmental problem, that key doesn't have anything to do with installers. EAP-SIM is an authentication protocol for wireless networks. The FastReauthContext key almost surely was meant to avoid having to provide a username+password each time your machine reconnects to the network. Which makes the registry key content very sensitive of course, it can only be read by a service that runs with the System account.
So, something goofy going on with your networking setup. Verify that you can successfully reconnect to such a network. If you used a VPN before then make sure it is active again. Something like this. Update your question with anything that might be relevant to networking when you first installed the app.
I have had similar problem and what I found out this is caused by MSI attempting to delete whole "Software\Microsoft" section in the registry. Lucky you that it encounters this error and rolls everything back.
So the solution is the following:
Since you have installed your program whenever you try to uninstall it the system will run msi from cache that is usually located C:\Windows\Installer.
Find your package in the cache. Here is an article that may help you http://csi-windows.com/blog/all/27-csi-news-general/334-identifying-cached-msi-packages-in-cwindowsinstaller-without-opening-them
Open the package in Orca. You must do this as administrator.
Go to Registry table and find record with "Software\Microsoft" as a key. Most likely the Name column will contain either "-" or "*" value. This means that during uninstall MSI will try to delete whole "Software\Microsoft".
Either change the Name value to empty or "+" or try to change key to something like "Microsoft". The second option will cause that installer will not find the key to delete during uninstall, but it will skip this error and let you uninstall your program.
You installed an untested installer on your dev machine? Speaking from experience, don't do that! Snapshotted VM's are cheap and will save you from this sort of pain.
Visual Studio Deployment Projects (or VSI as it's now called ) is known for creating very poor quality installs. The combination of those two put you where you are today.
I would need to look at the full uninstall log and your MSI using ORCA to understand exactly what is going on. MSI Zap and a manual cleanup of resources is probably required at this point.
Related
My install fails on uninstall because of a bug in my CustomAction. I've fixed the bug, but I now have a test machine with that product installed and I can't get it to uninstall (keeps rolling back and staying).
In the past (years ago), I used msizap.exe that comes with the Windows SDK. But it doesn't seem to come with it anymore. I installed it and can't find it. My only guess is that it's no longer relevant in Windows 10.
Anyway, is there a best way to forcibly remove the product so that Windows no longer thinks it's installed?
msizap.exe: You are correct, msizap.exe has been deprecated long ago.
Broken Uninstall Workarounds: This problem is very common. You can find a list of approaches for these kind of uninstall problems here.
The easiest and fastest is probably to just use the Microsoft FixIt tool to remove the package. This basically "unregisters it" by the looks of it, and is similar to msizap.exe in that regard.
If this is just a single machine you can hack the cached installation database using Orca (how to find cached msi path, powershell version, using Windows Explorer - point 2) - if it involves many machines you should make a patch. Please see details in link above.
Virtual Machines: It is obvious, but just to mention that you should check setups on virtual machines so you can just revert the virtual machine when you encounter "development and QA bugs" like these.
Custom Action Flag: You can also add a condition to each custom action so that you can disable the whole custom action from running by a custom command line sent to msiexec.exe.
If your flag is a property RUNCA="1", then you can disable it by setting this flag property to 0 via the command line - this is sort of a little inoculation for the package's uninstall feature breaking - you can disable custom actions from running at all during install / uninstall - it might even be useful for your tech-support guys and real-world installations:
msiexec.exe /x {PRODUCT-CODE} RUNCA=0
I created a Windows installer for a Client-Server program by using VS 2013 and InstallShield LE 2015.
I log in to a computer as Admin and run the installer. All works fine.
Then I modify the registry for Local_Machine for some keys to define the database location etc. for the program (this was done by the installation initially as well, but due to certain issues discussed in At each login the program tries to configure installation parameters in the HKEY_LOCAL_MACHINE registry, I removed the registry modifying section from the installer).
I then run the program by double-clicking the shortcut placed by the installer on the desktop and test it. All works well.
Then I log off the computer.
Another user with admin rights logins and clicks on the shortcut, and the problem comes: the program starts to reinstall itself!
Then it fixes itself and runs fine.
But If the first user logins afterward, she experiences the same reinstall operation so does the first user afterward ad nauseam!
So, even though the installer does not create any registry items by itself, somehow, as soon as the program accesses the registry, or whatever it thinks broken, the Windows OS intervenes and tries to repair whatever needs fixing.
The InstallShield LE does not allow setting shortcuts to be "Advertised Shortcut", or
I delete the shortcut created by the installer and recreate it manually after the installation and yet experience the same problem. So the nature of the shortcut possibly is not the cause.
This problem only happens for multiple logins to the computer. If many people login by using the same credentials, it never happens.
So, what's wrong? I studied many StackOverflow answers to resolve this issue with no success. Any help would be highly appreciated.
Stein gives a good set of instructions on how to diagnose problems with MSI programs in this StackOverflow answer. When I followed his instructions, I was able to check which component of my MSI program has a problem. It turns out, the serial bus controller library, MScomm32.ocx could not register under Win 10 properly. Once, I implemented the solution in this link, the above problem resolved and I could log in as two different users without initiating a reinstall process whenever the program icon was double-clicked to run.
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.
it starts up windows installer with random applications on my machine . . after i click cancel a few times, it loads vb6 fine.
any ideas why this is happening?
To stop this behavior:
Start VB6
Open the Add-Ins dialog
Uncheck the "Visual Component Manager" Add-In
Source:
After VS2010, SP1, VB6 launches VS2010 installer
This is what a Windows Installer repair looks like. It means that something is broken in one of the installed products on your system. Ideally it's a one-off repair so you might be better off letting it runs its course and do the repair, except of course if it asks for a install CD that you don't have.
The Windows event log (Application) will have MsiInstaller entries saying what product and component has the problem.
It's possible a previous installation has not completed correctly.
Use the utility at the following link to remove any rogue installations files:
http://support.microsoft.com/kb/290301 (broken link Aug.2017, leaving URL for "historical purposes").
As PhilDW has pointed out this is a Windows Installer Self-Repair issue, and can often be resolved by allowing the self-repair to complete once. At other times the problem persists and it should be fixed by other means. Even when the self-repair completes and the problem goes away, it can still resurface once you launch the conflicting application. Windows Installer is not easy to deal with.
In your particular case you might be able to get away with a "workaround" rather than a fix. By locating the main VB6 EXE file on disk (in its main installation directory) and manually creating a shortcut to it on your desktop, you might be able to successfully launch VB6 via this new shortcut without the self-repair kicking in. It might be worth a try.
This shortcut trick will not remove the underlying problem, but might help to "bypass it". Just for the record: the reason this might work is that the new, manually created shortcut is not "advertised" and will not trigger a key-path check of the installed product when launched. This is Windows Installer's way to verify that a product is correctly installed. Note that even if the workaround works, self-repair might still result during application use because of faulty COM data being detected (which is very likely the cause of the whole problem you are seeing, but give the manually created shortcut a try).
There is a rather comprehensive "article" on self-repair here: How can I determine what causes repeated Windows Installer self-repair? which might help to track down the cause of the self-repair kicking off in the first place, but fixing it can be a rather complicated process (so try the workaround first). It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop. The last application to launch will overwrite the registry or file system with its own setting.
This worked for me, for VS2010 RC:
"Please wait while windows configures Microsoft Visual studio 2010 Ultimate."
THe work around that fixes the issue for me was to run the following via the admin cmd prompt.
Md "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\common7\IDE\FromGAC"
from http://social.msdn.microsoft.com/Forums/en-SG/vsprereleaseannouncements/thread/572a0f8a-16b0-4e1d-b581-16be36a9b564
This was also happned to me.
Whenever i tried to open vb6, it started windows installer to configure "Autocad".
Autocad had not broken. and it was working fine.
I tried removing and reinstalling Windows Installer, But it did not solved the issue.
Then i installed Microsoft's "Windows Installer Clean Up Utility 2" from given link.
Using this utility i removed the autocad from "Windows Installers" Database.
After that VB6 never started installer again.
Keep in mind 'removing any entry from installer's database may be risky, but i had no choice. So do it on your own risk.
Download "Windows Installer Clean Up Utility 2" (this is a deprecated, unsupported and unsafe tool to use - Aug.2017. I will leave the link in for "historical purposes", don't use it).
I am creating windows installer project using Visual Studio 2005.
Is there an option make it so that my project does NOT have an uninstall option in Add/Remove programs?
One of my customers has asked me to do this.. Here's Why: Because the installer is a patch to an existing program. After uninstalling, the program no longer works because the patched files get uninstalled. Instead of figuring out a way to restore the replaced files (which we haven't been able to do with this installer), we're wondering if it is possible to disable the uninstall.
You just need to set ARPSYSTEMCOMPONENT=1 in the Property table of the installer using Orca (Can't be done directly in Visual Studio from what I know)
This is commonly used when a program installs dependencies and you don't want the user to uninstall dependencies by hand, they need to use a specific uninstall script you've provided or something.
Personally, I would author the patch as a patch and prevent the patch from being uninstalled.
Also I suggest picking up a copy of The Definitive Guide to Windows Installer which will give you some explanation on how, why and where you should use tricks such as this. As well as giving you a really good understanding of the windows installer fundementals and help you to design a better installer in the long run. All the examples in the book use Visual Studio + free tools from the Windows Installer SDK.
Edit: The user still has full control to uninstall via MSIEXEC, via a custom uninstall shortcut that you provide, all this does is hide the entry in Add/Remove Programs (ARP)
Edit2: Sample VBS to add the property (if you want to do so as part of an automated build process)
Dim installer, database, view
Set installer = CreateObject("WindowsInstaller.Installer")
Set database = installer.OpenDatabase ("test.msi", 1)
Set view = database.OpenView ("INSERT INTO Property(Property.Property, Property.Value) VALUES('ARPSYSTEMCOMPONENT', '1')")
view.Execute
Set database = Nothing
Set installer = Nothing
There might be, but to be honest, that's a horrible, horrible idea. It's not your call to tell a user what they can and cannot do with their machine.
And if the user shouldn't have the ability to do so, then that is usually determined by an administrator and the user is not given the right to uninstall anything by virtue of their account type, which again, is not something you should have influence on.
You don't know who his "users" are. This may not be for end-user software at all. We write a lot of custom software that's installed in a NOC; it doesn't put any uninstall info into add/remove. (We're using Nullsoft's NSIS and not the Visual Studio installer, btw...)
It's way too silly to say something like "This is always a horrible idea". There are many cases in modern software where uninstalling dependencies can true and thoroughly f--- the machine at hand up.
Open Source Software ideals are only useful for people who WANT to be able to break their machine.