MSI为什么要求原始.msi文件才能进行卸载?

本文介绍了MSI为什么要求原始.msi文件才能进行卸载?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

您可能已经注意到，大多数人在卸载MSI软件包时，Windows会要求提供原始的.msi文件.为什么会这样?

As most of you probably noticed, when uninstalling an MSI package Windows will ask for the original .msi file. Why is that?

我只能看到它的缺点:

不能适应网络变化.
不能适应本地磁盘更改.
用户意外.
通常要求用户离开办公桌并进行一次十字军东征以获取正确的CD.
种种证明安装不是独立的.
促进使用诸如msizap之类的不安全工具.
这反过来促进了下次我将只使用zip文件"的心态.

有人可以对此有所启发吗?

Could someone shed some light on this?

推荐答案

更新:

(现在也已不推荐使用此工具)，如果您拥有需要卸载的MSI软件包已卸载(而不是过时的，不推荐使用的，不受支持的版本)，则可以在最新的Windows版本上试用).

(this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall (rather than the outdated, deprecated, unsupported ).

有人建议使用saschabeaumont链接到此处的工具: 在没有MSI文件的情况下进行卸载 .如果您尝试并成功，请务必告知我们.该答案中的反馈表明它可以正常工作(到目前为止，我没有任何可测试的固定设置).

Some have suggested to use the tool linked to here by saschabeaumont: Uninstall without an MSI file. If you try it and it works, please be sure to let us know. Feedback in that answer indicates that it works (I don't have any stuck setups to test with as of now).

为什么要求提供原始安装介质? :

Why are you asked for the original installation media?:

除非原始MSI的设计不正确-或缺少缓存的MSI，否则不需要卸载原始MSI (请参见下面的详细信息).
所有已安装的MSI文件都使用随机十六进制名称缓存在％SystemRoot％\ Installer \ *.* 中.
缓存的MSI文件可用于任何维护，修复和卸载操作-足以在绝大多数情况下进行卸载案例.
在某些情况下该缓存文件可能会丢失，然后在某些情况下根本无法卸载(- MSI design errors ， anti-virus quarantining ， system restore ， tinkering ， developer system in erroneous state from development work ， ).请参阅下面的更多信息-以及用于强制卸载或注销产品的链接.
原始来源仅在以下情况下需要:文件需要复制到磁盘(用于维护安装)，或者MSI发出明确要求以解析原始来源通过标准操作 ResolveSource 或通过自定义操作(不应在正确编写的程序包中完成-我认为MS Office程序包中已包含此ResolveSource错误一天，导致每个人都去寻找他们的安装CD/DVD.
在Windows的早期版本中，此缓存的MSI被删除了所有驱动程序，因此仅包含安装程序结构，而没有文件.
从Windows 7( MSI版本5 )开始， MSI文件现在已全部缓存，以避免破坏文件签名，因为这会影响安装程序启动时的UAC提示(已知的Vista问题).这可能会导致磁盘空间消耗(某些系统为数GB)的巨大增加. 查看本文，尤其是底部的讨论以获取更多信息.
为防止缓存巨大的MSI文件，可以在安装前运行软件包的 admin-install .这是在受管网络中进行适当部署的公司的工作方式，它将去除cab文件，并使用较小的MSI文件和其他文件作为网络安装点. 请注意，在某些情况下，这可能会产生 UAC提示，因为提取的MSI文件已不再签名-必须使用您的SOE/桌面配置进行测试.
在此主题中阅读我的答案，以获取管理员安装的完整说明:使用msiexec/a发起的管理安装的目的是什么?或类似但更易访问的答案:
在极少数情况下，可能会错误地丢失缓存的MSI(具有随机名称)，然后卸载将要求原始MSI才能完成卸载.这种情况很少发生.过去，人们可以使用清理此类安装，但是此工具已过时，已弃用和不受支持.不要使用它-与较新的Windows版本存在太多不兼容，您会遇到新的问题.也许尝试(也已弃用).我现在建议的唯一选择是 saschabeaumont的此答案 . 如果您尝试使用此工具，请告诉我们它是否适用于您 u.如果您想找出是什么原因导致缺少缓存的MSI，请尝试在此处阅读第12节:(简而言之，其原因可能是干扰系统还原，防病毒和清理脚本，到繁琐的手动调整，磁盘空间不足，断电，开发人员调试错误，设计错误的MSI文件(带有重复的程序包代码，补丁程序失败等等).
作为最后的手段，您可以尝试 系统还原 (除非已被全部或部分禁用)，然后返回到先前的安装状态，看看是否能解决您的卸载问题(您可以在youtube或类似网站上找到此视频的演示).
请注意，系统还原可能会影响必须随后重新应用的Windows Update以及许多其他系统设置.我已经看到由于系统还原而导致的新的无法解决的安装问题，但是通常它可以正常运行.显然，请不要使用该功能，这是不得已的方法，最好用于回滚新驱动程序或刚刚安装并被发现会立即导致安装程序的设置.问题和此类问题.您返回的时间越长，您将为自己创建的返工就越多.很多不言而喻的东西，但我想有必要提及.
自从我提到系统还原以来，我想我应该提到最后一次正确的配置"功能.此功能与卸载或系统还原无关，但它是最后一个有效的引导配置，该引导配置可导致系统正常运行.如果它在引导过程中出现蓝屏或停止运行，则可用于使系统重新运行.安装驱动程序后通常会发生这种情况.但这并不能解决您无法卸载的问题(否则我会非常感到惊讶).

The original MSI is not needed for uninstall unless the MSI itself is badly designed - or the cached MSI is missing (see details below).
All installed MSI files are cached in %SystemRoot%\Installer\*.* using a random hex name.
The cached MSI file is used for any maintenance, repair and uninstall operations - and it is sufficient for uninstall in the vast majority of cases.
In some cases this cached file can be missing, and then uninstall is not possible at all in some cases (some theories as to why this can happen - MSI design errors, anti-virus quarantining, system restore, tinkering, developer system in erroneous state from development work, etc...). See more info below - and links to force uninstall or unregistration of the product.
The original source is only needed if files need to be copied to disk (for a maintenance install), or the MSI does an explicit request to resolve the original source via the standard action ResolveSource or via a custom action (which shouldn't be done in a properly authored package - I think the MS Office package contained this ResolveSource error back in the day, causing everyone to go looking for their installation CDs/DVDs).
In previous editions of Windows this cached MSI was stripped of all cabs, and hence contained the installer structure only, and no files.
Starting with Windows 7 (MSI version 5) the MSI files are now cached full size to avoid breaking the file signature which affects the UAC prompt on setup launch (a known Vista problem). This may cause a tremendous increase in disk space consumption (several gigabytes for some systems). Check this article and especially the discussion at the bottom for more intel.
To prevent caching a huge MSI file, you can run an admin-install of the package before installing. This is how a company with proper deployment in a managed network would do things, and it will strip out the cab files and make a network install point with a small MSI file and files besides it. Note that this may yield a UAC prompt is some cases since the extracted MSI file is no longer signed - this must be tested with your SOE / desktop configuration.
Read my answer in this thread for the full description of admin installs: What is the purpose of administrative installation initiated using msiexec /a? or this similar but perhaps more accessible answer: admin install and its uses
In some rare cases the cached MSI (with the random name) can be erroneously missing, and uninstall will then ask for the original MSI in order to complete the uninstall. This does not happen often. It used to be the case that one could use to clean out such an install, but this tool is outdated, deprecated and unsupported. Don't use it - there are too many incompatibilities with newer Windows versions and you create new problems. Perhaps try instead (also deprecated). The only option I can suggest now is this answer from saschabeaumont. If you try this tool, please let us know if it works for you. If you want to figure out what could have caused the cached MSI to be missing, try to read section 12 here: Uninstalling an MSI file from the command line without using msiexec (in short potential causes range from interference with system restore, anti virus and cleanup scripts, to erronous manual tweaking, low disk space, power outages, developer box debugging errors, badly designed MSI files with duplicate package codes, failed patches, etc... Many theories, few certainties I am afraid).
As a last resort you can try system restore (unless it has been disabled entirely or partly) to go back to a previous installation state and see if this solves your uninstall problem (you can find video demos of this on youtube or a similar site).
Be aware that system restore might affect Windows Update that must then be re-applied - as well as many other system settings. I have seen new, unsolvable installation problems resulting from a system restore, but normally it works OK. Obviously don't use the feature for fun, it's a last resort and is best used for rollback of new drivers or setups that have just been installed and are found to cause immediate problems and such issues. The longer you go back the more rework you will create for yourself. A lot of self-evident stuff, but I guess it needs to be mentioned.
Since I mentioned system restore I suppose I should mention the Last Known Good Configuration feature. This feature has nothing to do with uninstall or system restore, but is the last boot configuration that worked or resulted in a running system. It can be used to get your system running again if it bluescreens or halts during booting. This often happens after driver installs. This will do nothing to fix your failing uninstall though (or I would be very surprised).