Uninstall Command Fails Only in Release Mode

Question

I am able to successfully uninstall a third-party application via the command line and via a custom Inno Setup installer.

Command line Execution:

MSIEXEC.exe /x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn

Inno Setup Command:

[Run]
Filename: msiexec.exe; Flags: runhidden waituntilterminated; 
Parameters: "/x {{14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
StatusMsg: "Uninstalling Service...";

I am also able to uninstall the application programmatically when executing the following C# code in debug mode.

C# Code:

string fileName = "MSIEXEC.exe";
string arguments = "/x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";

ProcessStartInfo psi = new ProcessStartInfo(fileName, arguments)
{
    CreateNoWindow = true,
    UseShellExecute = false,
    RedirectStandardOutput = true
};

Process process = Process.Start(psi);
string errorMsg = process.StandardOutput.ReadToEnd();
process.WaitForExit();

The same C# code, however, produces the following failure output when run as a compiled, deployed Windows Service:

"This action is only valid for products that are currently installed."

Additional Comments:

• The Windows Service which is issuing the uninstall command is running on the same machine as the code being tested in Debug Mode. The Windows Service is running/logged on as the Local system account.
• I have consulted my application logs and I have validated that the executed command arguments are thhe same in both debug and release mode.
• I have consulted the Event Viewer but it doesn't offer any clues.

Thoughts? Any help would be greatly appreciated. Thanks.

Answer 1

Step 1: Check the MSI error log files

I'm suspicious that your problem is due to running as LocalSystem.

The Local System account is not the same as a normal user account which happens to have admin rights. It has no access to the network, and its interaction with the registry and file system is quite different.

From memory any requests to read/write to your 'home directory' or HKCU under the registry actually go into either the default user profile, or in the case of temp dirs, c:\windows\temp

Answer 2

I've come across similar problems in the past with installation, a customer was using the SYSTEM account to install and this was causing all sorts of permission problems for non-administrative users.

MSI log files aren't really going to help if the application doesn't appear "installed", I'd suggest starting with capturing the output of MSIINV.EXE under the system account, that will get you an "Inventory" of the currently installed programs (or what that user sees installed) - http://blogs.msdn.com/brada/archive/2005/06/24/432209.aspx

I think you probably need to go back to the drawing board and see if you really need the windows service to do the uninstall. You'll probably come across all sorts of Vista UAC issues if you haven't already...

Answer 3

Thanks to those offering help. This appears to be a permissions issue. I have updated my service to run under an Administrator account and it was able to successfully uninstall the third-party application. To Orion's point, though the Local System account is a powerful account that has full access to the system -- http://technet.microsoft.com/en-us/library/cc782435.aspx -- it doesn't seem to have the necessary rights to perform the uninstall.

[See additional comments for full story regarding the LocalSystem being able to uninstall application for which it installed.]

Answer 4

This is bizarre. LocalSystem definitely has the privileges to install applications (that's how Windows Update and software deployment in Active Directory work), so it should be able to uninstall as well.

Perhaps the application is initially installed per-user instead of per-machine?

Answer 5

@Paul Lalonde

The app's installer is wrapped within a custom InnoSetup Installer. The InnoSetup installer, in turn, is manually executed by the logged in user. That said, the uninstall is trigged by a service running under the Local System account.

Apparently, you were on to something. I put together a quick test which had the service running under the LocalSystem account install as well as uninstall the application and everything worked flawlessly. You were correct. The LocalSystem account has required uninstall permissions for applications in which it installs. You saved the day. Thanks for the feedback!