I have an MSI package I maintain with Installshield 2012 Pro.
The package was created a few years again and requires periodic maintenance as new versions of the application is installs are released by our development team. This MSI has been used in many locations, on many machines without issue.
At one customer location, they've install about 20 copies of the application on 20 machines. Each machine is built exactly the same.
Periodically, for an unknown reason registry entries relating to that application go missing. Not all of them, a select one or two... the same entries always go missing.
We so far have failed to track the exact root cause, however one of our support engineers noticed the MSI repair dialogue appearing when they opened the application shortcut. Following this, the registry entries went missing.
On each instance of the registry entries going missing we have removed the MSI from the c:\Windows\Installer directory. On machines we've made this change too, the registry changes so far have not disappeared again.
This leads me to think the MSI is somehow removing the selected registry entries during the repair, but I don't understand how.
There are at least 50 registry entries under the same key as the entries that get removed. (these are created by the application not the installer)
The MSI package doesn't insert any keys at all during install
There are no custom actions at all
I only have one key file set in the whole MSI, and this is for a component installed in Windows\system32
None of the shortcuts are 'Advertised'
There appears to be a clear link between removing the MSI from the Installer directory and no further occurrences, but I fail to see what in my MSI could cause specific registry keys to disappear.
I realize the exact reason this this is subjective to my MSI or the customers systems, so as generally as possible I ask:
Why would Windows launch the MSI repair function, considering the above
Can an MSI alter the registry, considering the above
Is there anyway post installation of an MSI to disable the auto repair function for this MSI?
How should I alter the MSI to ensure auto repair doesn't occur?
Thanks
Start by proving whether the auto repair is related to your product. Check the application event logs for the component id that caused Windows Installer to kick off the auto repair. Then, if it's part of your installer, figure out why.
It seems unlikely that your MSI would alter the registry. Although you do not specifically say there are no RemoveRegistry table entries, it's hard to imagine any snuck in accidentally.
There are only bad ways to disable auto repair (some global, some involving not registering your installer). Avoid them.
First figure out what's wrong. Then figure out how to fix it. For instance if in step 1 you determine the component triggering auto repair is part of your install, perhaps set the logging policy on a machine where this occurs so you can get a verbose MSI log.
Related
I am trying to uninstall Crystal Report for Visual Studio 2011, and install Crystal Report for Visual Studio 2019. I got the error message of "Error applying transforms. Verify that the specified transform path are valid." when uninstalling the program. Therefore, the newer version of Crystal Report for VS 2019 can't be installed.
I searched around and some posts says about windows registry entries caused the problem. I can't find out a solution on what to do.
Highly appreciate your response.
Crystal Reports: I am wondering if you have installed from a network share that is no longer available, or one where the UNC path specified to your transform is blocked or in other ways incorrect. What you need is a proper log file. Please see below. And have a quick peek here: https://apps.support.sap.com/sap/support/knowledge/en/1220433
There are also some issues with secure transforms and complications arising from this and newer Windows settings and security features. Maybe have a quick look here. Just a few links on the topic.
How many machines do you see this on? Just your own?
Preparation: A couple of things first:
Reboot: Do a reboot before attempting the next uninstall. Just to have a clean slate. Allow system to settle after reboot (give it a couple of minutes to settle down).
Corrupt installation files: Re-download your new setup to make sure its installation file is not corrupted. Try to malware scan it too. And finally set it unblocked as shown here.
Admin Rights: Second, make sure you run with proper admin rights? Run the msiexec.exe command from an elevated command prompt. Please launch an elevated cmd.exe (right click => run as administrator).
Anti-Virus: Disable your anti-virus first to prevent any locks from failing your uninstall.
Debugging "Ideas Lists": Common causes of setup runtime issues
Logging: Now the most important. You must also ensure proper logging for the uninstall effort. You can either use logging by policy
or define it at the command line level. It would be best to enable the
logging policy so the log file is automatically created in the tmp
folder. Please see this answer for more on logging.
When you have done the "Preparation" above, please run the
uninstall and create a proper log file. Here is the command line
(prefer the policy):
msiexec.exe /x "mysetup.msi" /L*V "C:\Temp\msilog.log"
Please open the log you created (or get the log from the temp folder
if you have logging policy enabled). Then inspect the log and match
against this sample log here:
https://www.itninja.com/question/transform-issues
What do you see? Just read line by line and don't be intimidated by
all the "line noise".
Common Technical Issues: If you have problems with all other MSI packages and their operation, you could have a bigger problem. Then you should rule out some runtime issues. Note that some issues are commonly caused by malware (or just technicalities that occur randomly sometimes):
Visual C++ Runtime - reinstall it. There are many versions. See what your package needs. The latest supported Visual C++ downloads.
Unregister / re-register msiexec.exe (can be necessary because of malware or normal technical glitches).
Run chkdsk.exe and sfc.exe to check for file corruptions and corrupt OS files.
Microsoft FixIt: You can use the Microsoft FixIt method as a last resort to clean out your existing installation. This generally works (unless you have hacked too much already), but is not ideal: http://support.microsoft.com/mats/Program_Install_and_Uninstall/ - this approach does not clean up or uninstall, it just unregisters the installed package and leaves all its files and registry settings in place. You can try to install the new version, but some interference issues are likely with the garbage left behind. Yes, you can try to clean up manually, but I would just try to overwrite first.
Links:
What is the root cause of "Error Applying Transforms. Verify that the specified transform paths valid"?
All About the Four Types of MSI Transforms
"Error applying transforms. Verify that the specified transform paths are valid."
I see that there are way to Get Get-AppxPackage or Remove Remove-AppxPackage UWP app from windows 10 using PowerShell.
I am wondering if there is a way to reset a UWP app? I require it for automated testing, I would rather reset the UWP app than uninstall and install again, as that would slow down the testing.
If you're looking to clear your package's ApplicationData then you want
appdata = Windows.Management.Core.ApplicationDataManager.CreateForPackageFamily(pkgfamilyname)
appdata.ClearAsync()
See MSDN for ApplicationDataManager.CreateForPackageFamily() and .ClearAsync()
Powershell has no 'await' affordance last time I looked (though it's been a while) so not so viable. If you're looking to muck with applicationdata you may find APPDATA.EXE handy. You can probably guess why I wrote it... :P For instance
APPDATA.EXE Clear foo.bar_1234567890abc
If you're looking to reset a package to its initially installed state, then no, there is no API other than uninstall + install
Remove-AppxPackage foo.bar_1.2.3.4_x86__1234567890abc
Add-AppxPackage foobar.msix
Settings' Reset option for an installed package essentially does that just slightly more efficiently. You're still going thru the full deregister and uninstall the package and then install and register it for the user so it may not be instantaneous. But that's the only way to truly reset a package to its initial state. Windows has various forms of user data associated with a package (ApplicationData, IndexDB, more) as well as system state cribbed and wired up when a package is installed for a user (what is the package, where's it live, that the user has it, that it's status is not tampered or otherwise unhealthy, more). The only way to truly 'reset' that to the initial state is a full remove then add.
If you just need to wipe appdata then .ClearAsync is the ticket.
I am not aware of any command that would do that for you (except for the UI available in Settings app). However, you may write a PowerShell script that would clear up the application data files in the app's folder (this is not an official solution, but seems to work based on my trials).
Go to
C:\Users\{your_username}\AppData\Local\Packages\
And find your app's folder there. There are several folders containing the application state.
The nuclear option is to just delete all the folders. Then the app will crash once on startup, then the system will automatically reset it and restore the folders.
The less invasive option I have now tried seems to be to keep the folders and just delete their content, except for the AC folder, which seems to be system protected. When I tried this with my app, it launched successfully without crashing and system recreated the state files anew on its own.
The rest of application files lives in C:\Program Files\WindowsApps, but those are just application DLLs and content files and are read-only, so they should not affect the app state at all.
You may want to perform additional deletion if you use a shared publisher folder.
For windows 10 build 2004+ there seems to be a powershell command Reset-AppxPackage now.
UPDATE
My mistake, it is available from version 20175 onward. So, should be available in 20H2.
I have tried many of the common approaches(MSI, PowerShell) to silently uninstalling the following application:
MSI
$ReportViewer2012 = Get-WmiObject -Class Win32_Product -Filter "Name = 'Microsoft Report Viewer 2012 Runtime'" | Select-Object -Expand IdentifyingNumber
if ($ReportViewer2012)
{
echo "Unistalling: Microsoft Report Viewer 2012 Runtime"
msiexec /passive /x $ReportViewer2012 | Out-Null
}
Powershell
(Get-WMIObject Win32_Product -Filter 'name="Microsoft Report Viewer 2012 Runtime"').Uninstall()
Without any effect, I did however get a verbose log for the output(/L*V):
MSI (s) (20:84) [14:42:57:903]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1706 2: -2147483647 3: ReportViewer.msi
MSI (s) (20:84) [14:42:57:903]: SOURCEMGMT: Processing URL source list.
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1706 2: -2147483647 3: ReportViewer.msi
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1706 2: 3: ReportViewer.msi
MSI (s) (20:84) [14:42:57:903]: SOURCEMGMT: Failed to resolve source
MSI (s) (20:84) [14:42:57:903]: MainEngineThread is returning 1612
MSI (s) (20:5C) [14:42:57:904]: User policy value 'DisableRollback' is 0
MSI (s) (20:5C) [14:42:57:904]: Machine policy value 'DisableRollback' is 0
MSI (s) (20:5C) [14:42:57:904]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (20:5C) [14:42:57:905]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (20:5C) [14:42:57:905]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (20:5C) [14:42:57:905]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (E8:EC) [14:42:57:906]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (E8:EC) [14:42:57:906]: MainEngineThread is returning 1612
This subject is discussed here but with no conclusion. I'm wondering what is causing the issue and how to resolve it?
Missing / Inaccessible Source
Just so it is clear, it is not normal behavior for Windows Installer to ask for the installation source for an installed product to allow uninstall.
Quick Fix? Maybe look under "Uninstall MSI" below for the Microsoft Install / Uninstall Tool
which you can use to try to resolve the situation with your un-uninstallable MSI package in a quick, automatic and - I believe - reliable fashion.
UPDATED: The Microsoft tool, should be able to resolve your problem. The rest of this answer is written in the spirit of "let's obsess over this" :-) and tries to explain potential causes as well as some other fixes.
Also see below for how to do verbose, debug logging to gather more "intel" for your particular uninstall / install problem (could pinpoint the exact culprit in the MSI - for example a specific custom action).
The likely, potential causes of your problem are:
Missing Cache MSI: The cached MSI that is supposed to be created in a protected, system folder during intial installation is missing - for some reason. Details explained below.
Missing Source Resource: It could also be that the uninstall process requires a resource that is missing on disk and prevents the uninstall from running.
The uninstall process will then try to resolve the source for the original installation media in order to get hold of the resource that is needed (binary?), and it then fails to do so because the original source MSI has been deleted and is nowhere to be found.
This generally indicates MSI design problems. The uninstall breaks and you are stuck with a catch 22 (can't uninstall, can't upgrade). See the Microsoft tool linked to below for a potential way to resolve this.
If an MSI design issue is indeed the cause (and certifiably so), you must try to work with the vendor for a reliable, future fix for their package - or it will obviously affect your own product's success and reliability. Goes without saying I guess.
Other Causes: A number of other, potential external causes are listed below ranging from anti-virus blocking, disk space issues, user / admin tinkering, system restore, etc...
The following log entry makes me suspect an anti-virus blocking issue, however a missing resource requiring original source resolution is just as likely:
SOURCEMGMT: Source is invalid due to missing/inaccessible package.
Since the anti-virus does not seem to block the full, downloaded MSI of yours from running, I am led to believe that the issue is a missing resource that the MSI is trying to erronously resolve and retrieve from the source media during uninstall. Likely a MSI design issue - will check more tomorrow.
Full, verbose, debug logging might provide further clues:
msiexec.exe /x {ProductCode} /L*vx! C:\Your.log (logging details from installsite.org).
The text below was written before deciding to suggest the above three primary candidate causes. Leaving in the content for reference.
Uninstall MSI
Microsoft Install / Uninstall Tool: there is a tool from Microsoft available for the case
where unresolvable install / uninstall problems occur: Fix problems that block
programs from being installed or removed.
The normal approach to uninstall an existing installation, is generally to use the product GUID of the product in question and kick off the uninstall as follows - silent uninstall with verbose logging:
msiexec.exe /x {00000000-0000-0000-0000-00000000000C} /QN /L*V "C:\My.log" REBOOT=ReallySuppress
Quick Parameter Explanation:
/X = run uninstall sequence
{00000000-0000-0000-0000-00000000000C} = product code for product to uninstall
/QN = run completely silently
/L*V "C:\My.log"= verbose logging at specified path
REBOOT=ReallySuppress = avoid unexpected, sudden reboot
You already have the list of other uninstall approaches (my favorite is section 3).
I am no good at Powershell, but here is an answer from earlier on its use to install / uninstall products: How can I use powershell to run through an installer? Maybe check that new Windows Installer PowerShell Module linked to at the top.
Potential Source Prompt Causes
The below is partially explained in the answer you link to above (section 12), but I will contextualize it here:
Cached MSI: Windows Installer caches MSI files in %SystemRoot%\Installer during original installation. This folder is super-hidden, you may need to show operating system files to see it in Windows Explorer. Windows Key + R + paste %SystemRoot%\Installer + hit ENTER. Read next bullet point before searching for your MSI.
Ranom, Hex Name: This cached MSI is assigned a random hex name and is used during maintenance and uninstall operations, and there should be no need to point to the original source MSI that was used to install from for any such operations. More details on this caching (Microsoft keeps changing how this caching works). Whatever you do, do not make any changes whatsoever inside this OS folder!
To find your MSI, hover over the random MSI names in sequence with the cursor, and a yellow pop-up should show you what product the MSI is for. Repeat until you find your MSI. Or...
You can also add the subject column to the Windows Explorer view to see a full list of product names. See this article for how to do this. Note that for localized systems it can be hard to find the right attribute to show, but if your system is English this is a great approach - full overview in seconds, no tedious "wait for hover pop-up".
In the olden days the Windows Explorer status bar also showed the MSI's product name - I am not sure it does anymore (View => Status Bar).
ResolveSource or Custom Actions: It is possible for this cache file to be missing for many, external reasons, but beyond external causes it is possible that the MSI in question is badly designed and specifically tries to resolve the original source by calling the standard action ResolveSource. I believe this could trigger the problem you describe. I suppose the MSI could also contain custom actions that could trigger the problem as well - I am not sure.
UPDATE: I downloaded the MSI in question, and I do not see any ResolveSource issues - frankly I am not even sure if this standard action can be used anymore. There are many custom actions though - several of which look suspicious. I can not install the MSI to test (lacking pre-reqs).
Missing Cached MSI: In some cases the cached MSI is missing in %SystemRoot%\Installer - either because it was never cached there during installation, or because it was removed or blocked by some later process or mechanism. Some possible causes (just theories):
Your anti-virus or security software could have quarantined the whole, cached MSI file. I have seen this problem of late. This could become a major problem as malware gets worse and security is tightened.
If you are low on disk space, I suppose weird problems such as this missing cache file could result. I would think you would be properly warned about the space issues though, but could the low disk space in turn cause file / disk corruption?
Beyond lacking disk space, disk corruption could also happen on its own for other, technicial reasons than disk space - obviously - and this would in turn certainly cause the missing / inaccessible cache-MSI. Malware is one culprit for disk corruption. Faulty I/O drivers another. Disk surface problems / flash wear as well. Bad security software intervening everywhere with faulty blocking. And the big one: power outage and new NVMe disks with massive cache capacity and no onboard capacitor power to ensure cache is committed if the power goes out. Disk corruption is inevitable. The list goes on.
In a related issue to disk corruption and disk space, some users try to redirect the MSI OS-protected cache folder %SystemRoot%\Installer to network locations or other partitions because their SSD system disk is out of space. Perfectly understandable, but this can cause complete failure for MSI operations. See this answer for the problem and some suggested workarounds.
Related to the previous bullet point, overzealous computer tinkerers sometimes delete system folder files that should never be touched (despite the folder being "super hidden" and difficult to access, it is still found). Some custom, third-party cleanup apps may also delete cached MSIs accidentally, as can custom, administrator cleanup scripts.
I have long suspected system restore to be a culprit when it comes to deleting cached MSIs, but I have not been able to catch the delinquent in the act yet!
I've got summary judgement ready, with system restore's name on it, should there be the slightest forthcoming evidence ("...burnt child, smells burnt").
Could system restore in combination with other problems be the cause? (file / disk / registry corruption?). It might have been previously, and the problem might have been secretly fixed?
Be careful with system restore - it is a source of mystery and weirdness. I have seen it delete my data files from the desktop. Why? Maybe use it against blue screens of death (driver failures) and malware only.
As mentioned above, I suppose a crash or bug towards the end of the product installation could cause the cached MSI to never make it properly into the cache folder, as could a power outage (for desktops).
Seeing as the caching would likely happen before the install process starts, this cause seems less likely, but I'll mention it. One would think the install would be incomplete, not the caching.
There could be complications when temporary files / rollback files are removed? And again: could system restore get confused about the file status? (a cache file present with a corrupted product registration? Remove it?)
For your own setups, repetitive installation and testing of your MSI can trigger weird edge cases (unlikely to occur "in the wild") where you see this lacking MSI caching phenomenon rear its ugly head. I have seen complications where identical package codes have been reused. Very technical - should not affect anyone but setup developers and / or their QA people.
And highly technical causes relating to the configuration of your system and network could potentially be involved triggering this problem - maybe particularly on (terminal) servers: custom group policy, custom privileges, custom ACL, impersonation contexts for scripts, etc...), but then you should generally see it for all packages. You need a real server expert to talk with sense about these issues - they may have very good reason to lock things down.
Some Links:
https://www.advancedinstaller.com/forums/viewtopic.php?t=34318
It appears as thought when you do a silent uninstall error's are suppressed as well, when I attempted to uninstall the package in the UI, I was presented with a dialog asking me to located the MSI file for the application. Not sure how it got this way but I fixed it by re-downloading the package and uninstalling it from there. Would be nice not to have to package a MSI with my powershell script just to uninstall an application, but right now I don't have a better resolution.
I have a setup project with InstallShield 2010. I'm deploying a configuration file during installation. However, when uninstalled, InstallShield decides to delete it (which is normal).
The question is, is there a way to keep the file on the hard disk even after the application in uninstalled? I don't want to reconfigure the application every time the user uninstalls/installs.
Edit: I'm using MSI project.
You don't say what project type you are using. Either way, put the config file in it's own component. For MSI projects, set the Permanent attribute to true. For InstallScript projects, set the Uninstall attribute to false.
Are there any tools for completely removing an Interbase 2009 SMP installation? I found an article describing how to remove IB6 (http://edn.embarcadero.com/article/28131), but I'm reluctant to delete anything in the registry according to a document which applies to another version of IB. Are there any equivalent descriptions for IB2009?
I guess you've run the uninstall and just want to clean up the registry.
You could try CCleaner. select registry and scan for Issues.
If its the first time you've run it there will probably be many unused entries.
If you're worried about changes then unselect all and just choose the ones related to IB.
Make sure you choose "Back up changes to registry"
Try RevoInstaller. A very good program to cleanup register and files after an uninstall. Note that you should run this program directly when uninstalling. It calls the applications uninstall routines and the cleanup afterwards.