Search code examples
powershellreportvieweruninstallationwindows-installer

Powershell Silent Uninstall "Microsoft Report Viewer Runtime 2012"

I have tried many of the common approaches(MSI, PowerShell) to silently uninstalling the following application:

enter image description here

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?

Solution

  • 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:

    1. 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.
    2. 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.
    3. 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:

    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: