In Win7, an old version of Acrobat XI is still showing, but there is no matching MSI file for it to execute, so it can't "uninstall" and I can't delete the entry because MS makes it intentionally difficult.
Normally such things just pile up over time. But Acrobat insists on uninstalling the previous version and will not install until the old one is gone.
How can I remove the entry from the database that "Programs and Features" uses?
The cached MSI file that is supposed to run the uninstall might be missing from the super-hidden MSI cache folder normally found at C:\windows\installer (formally at %SystemRoot%\Installer), or there is a crash in the uninstall sequence. Creating an uninstall log file could help (replace the truncated paths):
msiexec.exe /X "C:\Test.msi" /L*V! "C:\msilog.log"
Uninstall by product code (sample guid):
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /L*V! "C:\msilog.log"
Please see sections 3, 4 and 12 here for details on how MSI's uninstall works: Uninstalling an MSI file from the command line without using msiexec. This will also tell you how to find the product GUID for Adobe Acrobat XI Pro (use the Powershell command found in section 3, or find the same information and a screenshot here: How can I find the product GUID of an installed MSI setup?).
Before trying anything else, I suppose you can try this uninstall fix tool (fixed broken link, September 2017). It would be interesting with feedback on whether it actually works.
I had similar issues in the past and used ccleaner to clean up entires from "Programs and Features" after an uninstall went wrong. Hope it works for you.
This question is technically off topic as you are a user of the product not a developer of the product setup. Your cached MSI is missing and that's blocking their uninstall (bad design on their part) which occurs during upgrade to the new version. There are several things you can try:
1) Reinstall / Repair the old version and then try to uninstall it.
2) Contact the vendor for support.
3) Reinstall Windows.
4) Use the Windows Installer Cleanup Utility (no longer supported but can be found online ) to whack MSI's knowledge of the product. Note this doesn't actually uninstall the product and can cause all sorts of difficulties that may lead you to back to option 3.
Related
On a Windows workstation after a recent update of VSCode I'm prompted (recommended) to install a "User Setup Distribution of VSCode for Windows"
The link for more info leads to:
Download User Setup
If you are a current user of the system-wide Windows setup, you will be prompted to switch to the user setup, which we recommend using from now on. Don't worry, all your settings and extensions will be kept during the transition.
I don't see anything that explains what changes this distribution makes or how it's different from a distribution for other platforms, like X11/linux.
Code is a great editor, so I use it on various platforms depending where I am. Where is the explanation of what is included in this updated "Distribution"?
https://code.visualstudio.com/updates/v1_26#_user-setup-for-windows
Famous Question Badge Celebration! : love to VSCodium https://vscodium.com/ ... and highly recommend to anyone interested in this Q.
VSCode User Setup is a new installer, with a new install strategy, which installs the whole executable for VSCode and its dependencies in directories which don't require system-level / administrator permissions to modify. This allows a few things:
Users who don't have admin privileges to their workstation can still install and use VS Code
VS Code can perform its updates with fewer prompts (basically without the system-level privilege escalation prompts)
One tip: If you already had VSCode installed as a system-wide installation and you switch to the new installer as prompted/recommended, the User Setup installer will suggest that you uninstall the system-wide install first. I was a little nervous that I might lose my extensions doing this, but I went ahead and tried it and am happy to report that my extensions, recent projects, and other data regarding my VSCode use remained intact between uninstalling the "old" version and then proceeding with install of the new User Setup version.
(I'm a first time responder after many years.)
Note there is another useful discussion on this subject at: (What is the migration procedure for moving from Windows system-wide Visual Studio Code to user setup?). I too got worried when I got unexpected messages from the install informing me that the version was already installed and asking me if I wanted to continue? I clicked NO, why continue if it is already installed. However, in the process I became aware of the distinction between 'distribution' and 'version'. It turns out that the install works pretty much flawlessly no matter how you go about it. You can delete the system-wide distribution or not. If you do delete, you can delete before the new install, (which I did). You can also delete after the new install. (I didn't read too closely but there might be an extra step if you want to use both distributions.) In hindsight, since all approaches work nearly flawlessly, a minimal amount of instruction is all that was required. But in foresight, a little extra information on what to expect would have expedited the process for several people, including me. P.S. I found the answers in this thread useful. Thanks.
From the page you link to:
This setup does not require Administrator privileges to install. It also provides a smoother background update experience.
I am trying to install a piece of software that when done manually has configuration options you can choose from when going through the process. I am trying to figure out a way to automate this using powershell but am stuck as to how I can set those configuration options. I believe I would need to run the start-process command on the installer .exe but I don't know where to go from there. Can I use the parameters on the start-process command to pass in the configurations I want?
UPDATE: Several links towards the bottom with information on how to handle installation, configuration and file extraction for setup.exe files.
UPDATE: See Windows Installer PowerShell Module on github.com (scroll down for description, use releases tab for download). I haven't really tested it much, but it is from Heath Stewart - Microsoft Senior Software Engineer (github).
I had a quick look for that installer, but didn't find it easily. Essentially the installer is either a Windows Installer database (MSI) or something else - generally a setup.exe of some kind. An MSI database can also be wrapped in a setup.exe.
You should be aware that for legacy style installers a common practice for large scale deployment is to capture the legacy install with an application repackager tool, and then compile an MSI file to use for installation (effectively converting an installer from an old format to modern MSI format). This is a specialist task requiring good understanding of Windows and setups. It is generally done in large corporations for very large software distributions. If you are in a large company there might be a team dedicated to packaging software like the one you mention. Maybe check with your management. If the setup is an MSI the same team can also modify that for you according to your specifications.
With regards to your installer EXE. Try to run setup.exe /a from the command line and see if you get an option to extract files to a "network install point" (administrative install). Then you are dealing with an MSI file wrapped in a setup.exe. If that doesn't work you can try setup.exe /x or setup.exe /extract as well.
Windows Installer has built-in features to allow you to customize the install via PUBLIC properties (uppercase) set at the command line or applied via a transform (Windows Installer's mechanism to apply substantial changes to the vendor file - it is a partial database that gets applied to the installation database from the vendor at runtime).
Non-MSI, legacy installer technologies generally have fewer reliable ways to customize the installation settings, and they tend to be rather ad hoc when they are there. In particular the silent running and uninstall may be features that are missing or poorly executed. These installs are generally all wrapped in EXE format, and there are many tools used to generate them - each with their own quirks and features.
In other words, it all depends on what the installer is implemented as. Give that setup.exe /a a go, and update your answer with new information for us (don't add too many comments - we will check back).
With regards to using PowerShell. I haven't used PowerShell for deployment so far to be perfectly honest. Here is a basic description of how to install using PowerShell: https://kevinmarquette.github.io/2016-10-21-powershell-installing-msi-files/
You can also invoke automation for MSI files from PowerShell, I don't think this is relevant for what you asked, but here is a quick link for modifying a transform file: http://www.itninja.com/question/ps-how-to-edit-a-mst-file.
The normal way to install MSI files is via Window's built-in msiexec.exe command line. The basic msiexec.exe command line to install software is:
msiexec.exe /I "C:\Your.msi" /QN /L*V "C:\msilog.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Quick Parameter Explanation:
/I = run install sequence
/QN = run completely silently
/L*V "C:\msilog.log" = verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst (see below).
What is a transform? Explained here: How to make better use of MSI files.
Advanced Installer has a general page on msiexec.exe command lines. And here is Microsoft's msiexec.exe documentation on MSDN.
Some links:
Perhaps see Michael Urman's answer here: Programmatically extract contents of InstallShield setup.exe. This is for Installshield packaged EXE files only.
Installshield setup.exe commands (general reference with some sample command lines - towards the end of the document it looks like the command lines are not correct, but the first ones look ok. The later ones are pretty obscure anyway - just thought I'd let you know since I link to it). Here is the official Installshield help documentation.
Wise setup.exe commands - Wise is no longer available, but if the setup is older it can still be packaged with Wise.
Advanced Installer standard command line. For this tool setups can apparently be extracted with setup.exe /x or setup.exe /extract. See the link for full list.
There was also a "silent switch finder" tool used to find hidden switches in exe files (for deployment), but it failed a virustotal.com scan so I won't link to it. Maybe it is using something exotic, such as scanning a file's header at a bit level or something weird that is flagged as malware by mistake? Either way, not a tool I would use.
And finally: http://unattended.sourceforge.net/installers.php. This link isn't bad, it presents some of the tools above and a few others - and the most common switches used. Untested by me, but looks ok.
And there are other deployment tools that have their own way of packaging and delivering EXE files - it can be a jungle. I can provide a list of such tools with more links, but maybe that's just confusing. Please try what is provided above first.
Here is a generic answer that might be helpful as well: Extract MSI from EXE
We have a VSTO Application that is installed on many machines. If the Add-In is already installed, there is no issue. If you try to uninstall or install, you get the following error message:
The following Microsoft Office solution cannot be installed due to a general installer error: App_Name.vsto
0x80070002
This application has been working without hiccups for almost a year now. Our Sys Admin and I believe we've narrowed it down to a mandatory Windows 10 update as our base Windows 10 image has it working fine and it works on Windows 7 no issue. However, the update is already pushed out and nothing is showing up in the logs.
I know the VSTOInstaller.exe.Config file has been the cause for several of these installer issues, however I cannot find that file on any of our machines even though I KNOW I modified one machine and changed the name to VSTOInstaller.exe.Config.Old for the Business.fba error some have gotten. I assume an update somehow packaged the config file into the .exe.
The Windows 7 machines also don't have the Config file as well...
What we've tried:
Searching for an older .Config file to place in the folder
Rolling back to a previous version
Recompiling
Changing the publish destination folder and setting version back to version 1.0.0.0
Update: Placing a VSTOInstaller.Exe.Config then a VSTOInstaller.Config in the C:\Program Files\Common Files\microsoft shared\VSTO\10.0 folder
Update: Running repair then doing an uninstall/reinstall on Visual Studio Tools for Office Runtime (x64) program from Control Panel.
Update: Cleared Application Event Log
Update: Stopped Windows Update service, Renamed C:\Windows\SoftwareDistribution folder to C:\Windows\SoftwareDistributionOld, then restarted the Windows Update service.
I'm at a loss. Any help is GREATLY appreciated.
If anyone has the VSTOInstaller.exe.Config file, I'd love to try and place that in the folder to see if it works.
Version:
Word Version - 16.0.6769.2040
VS Version - 14.0.25420.1
OS Version - 1511 (OS Build 10586.494)
Turns out the error was part of a Microsoft Office update. Unsure if somehow the update listed in the question updated Office 2016 in the background somewhere.
The steps to resolution were as follows:
Uninstall O365 from the Control Panel
Download the a full removal tool and run it from https://support.office.com/en-us/article/Uninstall-Office-2016-Office-2013-or-Office-365-from-a-PC-9dd49b83-264a-477a-8fcc-2fdf5dbf61d8
At this point after those have ran, uninstall the add-in if it was installed.
Reinstall O365
Reinstall/Install the VSTO Add-In
Easier resolution than I thought and really appreciate all the assistance.
Windows 10 Update error 0x80070002 or 0x80070003
Step 1: Windows Service Checklist:
Open Windows services.msc, check the following services status (If it is different set it to the recommended settings)
[enter image description here][1]
Disable any third party antivirus applications, as it may block the Windows 10 upgrade process.
Step 2: Reset Windows updates:
Resetting windows updates, in this step we will clean up old failed updates that have been saved in the computer, let start by first disabling the windows update service.
Service Status(Start/Stop/Blank) Automatic/manual/Disabled
Background Intelligent file Transfer Started Automatic
Crytographic Service Started Automatic
DCOM service Started Automatic
RPC Started Automatic
Windows Modules Installer Started Automatic
Windows Update Started Automatic
Windows defender Blank Disabled
Windows firewall Blank Disabled
Disable Windows update service and stop the service
Now open Run command and type %windir%
Check for Software distribution folder delete the folder. (If it fails restart the computer, then try deleting it)
In Run command window type “cleanmgr” to launch disc cleanup to clean old junk files.
Restart the windows update service set it Automatic. Once completed, the windows upgrade error code 80070002 should be resolved. Try the upgrade now. Still unlucky, get in touch with us or proceed to next step
Step 3: Dism/Readiness Tool
This step is to fix core Operating system files that are corrupted and is affecting the Windows 10 upgrade and causing the error. Most of the cases running the tool or the command will fix the corrupted files, there are cases where some stubborn files remain. We can assist you in repairing them manually, post the log to us so we can check and revert back to you.
Depending on the OS, you have to choose proper tools,
For Windows 8 and higher use the following command in elevated command prompt.
Dism /Online /Cleanup-Image /ScanHealth
For windows 7: Download and run windows update readiness tool
microsoft.com/en-in/download/details.aspx?id=20858 –X64
microsoft.com/en-in/download/details.aspx?id=3132 – X86
Check the logs for the above tools in the following location
%windir%/logs/cbs
Post the log for further steps.
Please refer to this link for more info :
http://www.msofficelivesupport.com/windows-update/windows-10-update-error-0x80070002-or-0x80070003/
I use WiX 3.7 to write an installer, and I will install a c# system service will try to reinstall the software, using msiexec -x {product_code} -quiet. My OS is Win8
I first install the software through UI, and after a while, the service will create a new process and start to call msiexec, but it failed.
Could you help me on this? I have been struggling for a long time!
Thanks very much!
I have logs as follows:
MSI (s) (7C:80) [00:22:01:708]: Warning: The package code in the cached package 'C:\windows\Installer\134f7d5.msi' does not match the registered package code. Cached
MSI (s) (7C:80) [00:22:01:724]: SOURCEMGMT: Source is invalid due to client source out of sync (product code is the same).
What account is the service and thus the new process running under? Default accounts (e.g. LocalSystem) might not have rights to access the msi information.
That message means that a package is installed with the same ProductCode (set via the Product/#Id attribute) but is not the same package. This usually happens if you install a package, rebuild it (so the new package gets a new "package code") then try to uninstall with the rebuilt package. It can also happen if something is causing source resolution during uninstall and the Windows Installer finds the newly rebuilt package in the place where it expects the old package.
To get unstuck, try re-cache/reinstalling with the newer package then uninstalling:
msiexec /fv path\to\your.msi /l*v install.txt /qb
msiexec /x path\to\your.msi /l*v uninstall.txt /qb
After that, test your scenarios again without changing the MSI in between the updates. You'll slowly be able to track down what is changing in your system that is getting the Windows Installer confused and unhappy.
Good luck!
I have an InstallShield 12 installscript. I want to uninstall the old version before installing the new version. I will keep the name of the package unchanged. How can I do this?
Assuming this is not an MSI project and youve kept the same Project GUID, you could simply call ComponentUninstall() in the OnMaintUIBefore function.
If the Project GUID is not the same you can look at the uninstall string in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{PROJECT_GUID} and then do a LaunchApp with that.
Hope it helps.
With an MSI-based project, this would be accomplished by configuring a Major Upgrade for your project. Upgrades don't exist for InstallScript projects, but there are no Windows Installer restrictions to keep you from running multiple installations simultaneously. You should be able to simply run the uninstallation of the previous version manually in your InstallScript code (maybe in the OnFirstUIBefore function).