2

I'm having a problem, apparently specific to a single PC (running Windows 10 Enterprise), where the WiX installer I am developing fails to uninstall correctly.

The installer is a bundle including two of our own MSIs, SQL Server Express 2019, and .NET Framework 4.7.2 (the latter of which, in this case, does not get installed as it is already present). The bundle installs correctly, but when uninstalling, fails to remove our two MSIs, reporting the following in the log:

Will not uninstall package: XYZ, found dependents: 1
Found dependent: {0aab0314-39c3-435d-8fc7-747b0db56cc4}, name: Unknown

Looking in the registry (HKEY_CLASSES_ROOT\Installer\Dependencies) immediately after installation, there are three entries (not counting SQL Server) - one for our bundle, and one each for our two MSIs. The bundle has one dependent - itself - and the two MSIs each have two dependents - the bundle, and the mystery GUID (0aab0314-...). The mystery GUID remains constant across multiple install-uninstall cycles.

I've searched the registry top to bottom and have not found any other reference to that GUID; I've also tried looking in C:\ProgramData\Package Cache but not found it there either. I've used dark.exe to decompile the bundle and the two MSIs and then used grepWin to search all 400-odd files but to no avail. I can only successfully completely uninstall our software on this machine using Microsoft's cleanup tool (https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed), and I'm at a loss to know how to completely resolve the issue.

Any ideas what might cause this or other places I could search to try to work it out? Unfortunately my knowledge of MSI and WiX is slight and has been gained almost entirely in the course of this particular project.

Dan Parsonson
  • 1,010
  • 9
  • 13
  • 1
    Can't look at this right now, but a link: [Uninstall by product code](https://stackoverflow.com/a/29937569/129130). This might be the PC where you have developed the bundle? Try to use the VBScript in the link above to generate a list of product codes and see if you get a match with that GUID you report. Probably not, but give it a go. The Bundle itself has GUIDs (not just the MSIs), and I am not too well-versed in that aspect of them. Will look later, or Chris Painter probably knows this outright. – Stein Åsmul Jan 30 '20 at 15:24
  • 1
    You will not necessarily find GUIDs in the registry by searching for them. They are packed or compressed in there - generally. Packed and compressed GUIDs: [1](https://stackoverflow.com/a/54698365/129130), [2](https://stackoverflow.com/a/50727546/129130). – Stein Åsmul Jan 30 '20 at 15:28
  • Please be sure to test on a virtual if the system in question is where you developed the package. Development systems are frequently in a "dirty state" from development "mishaps" and experiments - as you no doubt know. It could be such problems are not "real" in the sense that they will not occur in the wild, but only on that box. Focus on testing real world use and look for problems. Many modes to test: `fresh install`, `repair`, `modify`, `uninstall`, `major upgrade`, `minor upgrade`. More involved modes: `patch`, `rollback`, `self-repair`. – Stein Åsmul Jan 30 '20 at 17:21
  • Thanks for all your helpful comments @SteinÅsmul - this has been occurring on a (relatively) clean machine that we use only for testing deployment. However during the course of attempting to troubleshoot the problem, it has now stopped happening and the installer once again performs exactly as expected. I'm hoping that the machine ended up in a weird state somehow, and I accidentally fixed it during repeated install/uninstall cycles, but we'll see :-/ – Dan Parsonson Jan 31 '20 at 09:06

0 Answers0