Powershell 静默卸载“Microsoft Report Viewer Runtime 2012" [英] Powershell Silent Uninstall "Microsoft Report Viewer Runtime 2012"

问题描述

我尝试了许多

MSI

$ReportViewer2012 = Get-WmiObject -Class Win32_Product -Filter "Name = 'Microsoft Report Viewer 2012 Runtime'";|选择对象 - 展开标识号如果($ReportViewer2012){echo 卸载:Microsoft Report Viewer 2012 Runtime"msiexec/passive/x $ReportViewer2012 |出空}

Powershell

(Get-WMIObject Win32_Product -Filter 'name="Microsoft Report Viewer 2012 Runtime").Uninstall()

没有任何影响，但我确实得到了输出的详细日志(/L*V):

<块引用>

MSI (s) (20:84) [14:42:57:903]:SOURCEMGMT:由于缺少/无法访问包，源无效.

MSI (s) (20:84) [14:42:57:903]:注:1:1706 2:-2147483647 3:ReportViewer.msi

MSI (s) (20:84) [14:42:57:903]:SOURCEMGMT:正在处理 URL 源列表.

MSI (s) (20:84) [14:42:57:903]:注意:1:1402 2:UNKNOWN\URL 3:2

MSI (s) (20:84) [14:42:57:903]:注:1:1706 2:-2147483647 3:ReportViewer.msi

MSI (s) (20:84) [14:42:57:903]:注意:1:1706 2:3:ReportViewer.msi

MSI (s) (20:84) [14:42:57:903]:SOURCEMGMT:无法解析来源

MSI (s) (20:84) [14:42:57:903]:MainEngineThread 返回 1612

MSI (s) (20:5C) [14:42:57:904]:用户策略值DisableRollback"为 0

MSI (s) (20:5C) [14:42:57:904]:机器策略值DisableRollback"为 0

MSI (s) (20:5C) [14:42:57:904]:递增计数器以禁用关机.递增后的计数器: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]:递减计数器以禁用关机.如果 counter >= 0，则关闭将被拒绝.递减后的计数器:-1

MSI (c) (E8:EC) [14:42:57:906]:递减计数器以禁用关机.如果 counter >= 0，则关闭将被拒绝.递减后的计数器:-1

MSI (c) (E8:EC) [14:42:57:906]:MainEngineThread 返回 1612

这个主题是讨论这里但没有结论.我想知道是什么导致了问题以及如何解决?

解决方案

缺少/无法访问源

很明显，Windows Installer 要求提供已安装产品的安装源以允许卸载是不正常的行为.

<块引用>

快速修复? 也许在下面的卸载 MSI"下查看 Microsoft 安装/卸载工具您可以使用它来尝试以快速、自动且(我相信)可靠的方式解决无法卸载的 MSI 包的情况.

更新:Microsoft 工具应该能够解决您的问题.本答案的其余部分本着让我们专注于此"的精神:-) 并试图解释潜在的原因以及其他一些修复方法.

另请参阅下文，了解如何执行详细、调试日志记录，以便为您的特定卸载/安装问题收集更多情报"(可以查明 MSI 中的确切罪魁祸首 - 例如特定的自定义操作).

问题可能的潜在原因是:

1. 缺少缓存 MSI:由于某种原因，应该在初始安装期间在受保护的系统文件夹中创建的缓存 MSI 丢失了.详情如下.
2. 缺少源资源:也可能是卸载过程需要磁盘上缺少的资源并阻止卸载运行.
   • 卸载过程随后将尝试解析原始安装媒体的源，以获取所需的资源(二进制?)，但由于原始源 MSI 已被删除和无处可寻.
   • 这通常表示 MSI 设计问题.卸载中断，您遇到了第 22 条问题(无法卸载，无法升级).请参阅下面链接的 Microsoft 工具，了解解决此问题的潜在方法.
   • 如果 MSI 设计问题确实是原因(并且确实如此)，您必须尝试与供应商合作，为他们的软件包提供可靠的、未来的修复 - 否则这显然会影响您自己产品的成功和可靠性.不用说，我猜.
3. 其他原因:下面列出了许多其他潜在的外部原因，包括防病毒阻止、磁盘空间问题、用户/管理员修补、系统恢复等...

以下日志条目让我怀疑防病毒阻止问题，但同样可能是缺少需要原始源解析的资源:

SOURCEMGMT:由于缺少/无法访问包，源无效.

由于防病毒软件似乎没有阻止您下载的完整 MSI 运行，因此我相信问题是缺少资源，MSI 试图在此期间错误地解决和从源媒体检索卸载.可能是 MSI 设计问题 - 明天会检查更多.

完整、详细、调试日志可能会提供进一步的线索:

• msiexec.exe/x {ProductCode}/L*vx!C:\Your.log(日志详细信息来自 installsite.org).

以下文字是在决定提出上述三个主要候选原因之前编写的.内容留作参考.

<小时>

卸载 MSI

<块引用>

Microsoft 安装/卸载工具:Microsoft 提供了适用于此案例的工具出现无法解决的安装/卸载问题:修复阻塞的问题安装或删除程序.

卸载现有安装的正常方法通常是使用相关产品的产品 G​​UID 并开始卸载，如下所示 - 带有详细日志记录的静默卸载:

msiexec.exe/x {00000000-0000-0000-0000-00000000000C}/QN/L*V "C:\My.log" REBOOT=ReallySuppress

参数快速说明:

/X = 运行卸载序列{00000000-0000-0000-0000-00000000000C} = 要卸载的产品的产品代码/QN = 完全静默运行/L*V "C:\My.log"= 指定路径的详细日志记录REBOOT=ReallySuppress = 避免意外的突然重启

您已经拥有其他卸载方法的列表(我最喜欢的是第 3 部分).

我不擅长 Powershell，但这里是之前关于它用于安装/卸载产品的答案:我如何使用 powershell 运行安装程序? 也许检查一下新 Windows Installer PowerShell 模块链接到顶部.

<小时>

潜在的源提示原因

您链接到上面的答案(第 12 节) 中部分解释了以下内容，但我将在此处将其上下文化:

• 缓存的 MSI:Windows Installer 在原始安装期间将 MSI 文件缓存在 %SystemRoot%\Installer 中.此文件夹是超级隐藏的，您可能需要显示操作系统文件才能在 Windows 资源管理器中看到它.Windows 键 + R + 粘贴 %SystemRoot%\Installer + 点击 ENTER.在搜索您的 MSI 之前阅读下一个要点.
• Ranom，十六进制名称:这个缓存的 MSI 被分配了一个随机十六进制名称，在维护和卸载操作期间使用，并且应该有无需指向用于安装任何此类操作的原始源 MSI.更多详情关于这个缓存(微软一直在改变这个缓存的工作方式).无论您做什么，都不要在此操作系统文件夹中进行任何更改！
  • 要查找您的 MSI，请将光标悬停在随机的 MSI 名称上，黄色弹出窗口应显示该 MSI 适用于何种产品.重复直到找到您的 MSI.或者...
  • 您还可以将主题列添加到 Windows 资源管理器视图中，以查看产品名称的完整列表.有关如何执行此操作的信息，请参阅本文.请注意，对于本地化系统，可能很难找到要显示的正确属性，但如果您的系统是英文系统，这是一个很好的方法 - 以秒为单位的完整概述，没有繁琐的等待悬停弹出".
  • 在过去，Windows 资源管理器状态栏 还显示 MSI 的产品名称 - 我不确定现在是否还能显示(View => Status Bar).
• ResolveSource 或自定义操作:许多外部缓存文​​件可能会丢失原因，但除了外部原因之外，有问题的 MSI 可能设计得很糟糕，并且专门尝试通过调用标准操作 ResolveSource 来解析原始源.我相信这可能会引发您描述的问题.我想 MSI 还可以包含也可能触发问题的自定义操作 - 我不确定.
  • 更新:我下载了有问题的 MSI，但我没有看到任何 ResolveSource 问题 - 坦率地说，我什至不确定是否可以再使用此标准操作.但是有许多自定义操作 - 其中一些看起来很可疑.我无法安装 MSI 进行测试(缺少先决条件).
• 缺少缓存的 MSI:在某些情况下，%SystemRoot%\Installer 中缺少缓存的 MSI - 要么是因为它从未缓存在那里在安装过程中，或者因为它被一些后来的过程或机制移除或阻止.一些可能的原因(只是理论):
  • 您的防病毒软件或安全软件本可以隔离整个缓存的 MSI 文件.我最近看到了这个问题.随着恶意软件的恶化和安全性的加强，这可能会成为一个主要问题.
  • 如果您磁盘空间不足，我想可能会导致奇怪的问题，例如缺少缓存文件.我认为您会收到有关空间问题的适当警告，但磁盘空间不足是否会导致文件/磁盘损坏?
  • 除了缺少磁盘空间之外，磁盘损坏还可能由于磁盘空间以外的其他技术原因自行发生 - 显然 - 这反过来肯定会导致缓存 MSI 丢失/无法访问.恶意软件是磁盘损坏的罪魁祸首之一.错误的 I/O 驱动程序 另一个.磁盘表面问题/闪存磨损.糟糕的安全软件以错误的阻止方式到处干预.最重要的是:断电和具有大量缓存容量且没有板载电容器电源的新 NVMe 磁盘，以确保在断电时提交缓存.磁盘损坏是不可避免的.名单还在继续.
  • 在与磁盘损坏和磁盘空间相关的问题中，一些用户尝试将受 MSI 操作系统保护的缓存文件夹重定向 %SystemRoot%\Installer 到网络位置或其他分区，因为他们的 SSD 系统盘空间不足.完全可以理解，但这可能导致 MSI 操作完全失败.请参阅此问题的答案和一些建议的解决方法.
  • 与上一个要点相关，过度热心的计算机修补匠有时会删除不应该触及的系统文件夹文件(尽管该文件夹超级隐藏"且难以访问，但仍然可以找到).某些自定义的第三方清理应用也可能会意外删除缓存的 MSI，自定义的管理员清理脚本也是如此.
  • 长期以来，我一直怀疑系统还原是删除缓存的 MSI 的罪魁祸首，但我还没有发现行为中的违法者！
    • 如果有最轻微的证据(...烧焦的孩子，闻起来有烧焦的气味")，我已经准备好了简易判断，上面写着系统还原的名字.
    • 系统还原与其他问题一起可能是原因吗?(文件/磁盘/注册表损坏?).可能以前是这样，问题可能已经秘密解决了?
    • 小心系统还原 - 它是神秘和怪异的来源.我已经看到它从桌面上删除了我的数据文件.为什么?也许仅将其用于蓝屏死机(驱动程序故障)和恶意软件.
  • 如上所述，我认为产品安装结束时的崩溃或错误可能会导致缓存的 MSI 永远无法正确放入缓存文件夹中，断电也可能如此(适用于台式机).
    • 鉴于缓存可能会在安装过程开始之前发生，这个原因似乎不太可能，但我会提到它.有人会认为安装不完整，而不是缓存.
    • 删除临时文件/回滚文件时可能会出现并发症吗?再说一遍:系统还原会不会对文件状态感到困惑?(存在产品注册损坏的缓存文件?删除它?)
  • 对于您自己的设置，重复安装和测试您的 MSI 可能会触发奇怪的边缘情况(不太可能在野外"发生)，您会看到缺少 MSI 的情况缓存现象背后的丑陋的头.我见过重复使用相同包代码的复杂情况.技术性很强 - 除了设置开发人员和/或他们的质量检查人员外，不会影响任何人.
  • 与您的系统和网络配置相关的高度技术性原因可能会触发此问题 - 尤其是在(终端)服务器上:自定义组策略，自定义权限、自定义 ACL、脚本的模拟上下文等...)，但是您通常应该为所有包看到它.您需要一位真正的服务器专家来讨论这些问题 - 他们可能有很好的理由锁定问题.

<小时>

部分链接:

• https://www.advancedinstaller.com/forums/viewtopic.php?t=34318

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:

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:

• 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

这篇关于Powershell 静默卸载“Microsoft Report Viewer Runtime 2012"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！