15

I have to replace it because of a bug that blocks the software uninstallation, but Windows can't find the MSI file if I use the file search utility, but I think the MSI is stored somewhere where the Add or Remove Programs utility can use it.

Jader Dias
  • 84,588
  • 150
  • 415
  • 615
  • The recommended / **correct way** to fix uninstall problems is to **use a minor upgrade to "hotfix" the installed product, and then trigger its fixed uninstall sequence** as indicated below by **saschabeaumont**. The minor upgrade can be delivered as a regular MSI or as a patch package (for huge products). – Stein Åsmul Feb 16 '18 at 13:28
  • [**Adding this answer as well**](https://stackoverflow.com/a/9709964/129130) for future reference. – Stein Åsmul Jun 29 '18 at 17:01

6 Answers6

17

Does it not go into %windir%\installer\

Though I think that the files may get renamed. Not sure where you get the name mapping from...

This directory gets very big so I move it to an external drive. This sometimes cause uninstalls or updates to fail with a missing msi error, but this can be fixed by putting the directory back

Random206
  • 39
  • 4
  • 13
Sam Holder
  • 31,788
  • 13
  • 99
  • 173
14

Installshield creates a copy of *.msi files at %windir%\installer\ path where %windir% is an environment variable which usually points to C:\Windows\. Before creating a copy of *.msi files it renames it using some random nomenclature e.g. I can see a file named 65ec5c99.msi in my C:\Windows\Installer directory.

Now to figure out the actual product name for the renamed MSI file there are two ways:

  1. Check LocalPackage attribute inside registry at path - [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersio‌​n\Installer\UserData‌​\<InternalUserId>\Pr‌​oducts\<ProductGUID>‌​\InstallProperties]. InternalUserId is something of sort S-1-5-18. ProductGUID is a GUID like 00058CD18F0BF523DA1072073D56715D embedded as a public property inside the MSI file itself. You can check this public property by opening your MSI file using any tool e.g. orca

  2. Open C:\Windows\Installer folder in explorer. Change the view of the directory to Details view. Add Subject column to the view. Now the product name can be seen in Subject column as shown in the screenshot below:

enter image description here

Note: C:\Windows\installer\ directory is not visible in explorer until we check Show hidden files, folders, and drives and uncheck Hide protected operating system files(Recommended) advanced settings under view folder options as shown in the screenshot below:

enter image description here

RBT
  • 21,293
  • 19
  • 144
  • 210
  • 1
    If anyone with windows setting to german is trying to display the 'Subject' column in explorer: activate 'Betreff' – Michael W. Apr 14 '21 at 08:12
7

You can force a recache/reinstall using with MSIEXEC, the recommended way to update buggy installation packages that cannot be otherwise removed is to recache with a fixed package, then uninstall as usual.

MSIEXEC /fv setup.msi
saschabeaumont
  • 21,760
  • 4
  • 61
  • 85
6

When you install a package using the Windows Installer service, the msi file does get cached in the hidden folder "%windir%\installer". It does get renamed, and the new name is a hex string that doesn't have an obvious correlation to the original name. Something like "123ab4.msi".

It's not hard to figure out which one is the cached copy of your app. The quickest way is to look for the cached file that's the same size. When you think you've found it, hover your pointer over the file's name in Windows Explorer. The tooltip will come up, and it will show you the data from the summary information stream of the package. Product name, author name, and so on. Once you've found the right file, you can directly edit it with a tool like Orca.

If you're just trying to fix things on your own machine, then directly editing the cached database may be a good option. However, Microsoft does provide a built-in way to handle a problem like this. You can create a patch (an msp file), which contains the difference between the original msi file and your updated msi file. That patch could then be distributed to anyone else that has already installed your app using the original install, and it would be easy to use.

MSDN discusses patch creation here - http://msdn.microsoft.com/en-us/library/aa368060%28VS.85%29.aspx

Deleting the hidden folder generally isn't a good idea, as that breaks some core functionality of the Installer service. That includes patching, detect and repair, and the ability to upgrade via migration rather than uninstalling and reinstalling.

Ed.
  • 1,134
  • 6
  • 8
5

To see useful names of msi files in C:\Windows\Installer right click at the top of explorer and add the field to view Subject (will probably have to select more as it isn't a default like name, date modified, etc.) From here you can find the msi and use it to uninstall programs.

thrax
  • 51
  • 1
  • 4
-1

Maybe the msi has simply been deleted. You can delete the installation folder and run the msi cleanup utility and then reinstall your program.

Klaus Byskov Pedersen
  • 111,411
  • 28
  • 180
  • 220
  • 1
    MSIZAP (Windows Installer Cleanup) is a very dangerous tool. See http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-Installers for more information – saschabeaumont Jan 17 '10 at 23:30