0

I have windows service which will get installed as part of wix installation . Problem is that, currently service is in production and it is not responding to stop due to some poorly written code in service OnStop method .

So next time when the user tries to install upgraded version installation will fail because service will never stop when wix tries to stop the service .

Is there any way in which i come to know if wix is taking too much time to uninstall and i can kill the process if i get that notification ?

Also, is there any way i can kill process based on product version ?

Thanks

Praveen M
  • 443
  • 2
  • 11

2 Answers2

0

Maybe try this: newer answer.

I shouldn't answer this since it has been ages since I have dealt with stuff like this, but what the heck, let's try.

  1. CloseApplication Element: Maybe I would just try WiX's CloseApplication Element first. I doubt it will work for a service, but this is the most convenient approach I can think of off the top of my head.
  2. Sysinternals PsKill: Mark Russinovich's PsKill would be worth a try. I think his tools are redistributable so you can include them in your setup, and they are always good. You have to invoke it from an elevated, deferred mode custom action - which is alway more involved than using a built-in WiX construct.
  3. Taskkill: There is also the built-in Taskkill - which I have never used. Suggested use with the sc tool.

I want to emphasize that I haven't actually tested these tools for killing services, and I don't have time to do so right now. There could be issues with the sequencing whereby StopServices could be scheduled before the CloseApplication custom action from WiX is scheduled to run. Please check the InstallExecuteSequence using Orca (towards bottom) after compilation to see whether this is the case.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thank you Stein. Is there any way i can look into wix before directly killing process . I was looking possibilities with FailureActionsWhen so that if service fails to stop i can execute process in "runCommand" parameter to kill service process. I am looking something like if service fails to stop then only kill the process. On failure i am getting service failed to stop message with retry option. Again thank you for your response links – Praveen M Apr 12 '18 at 09:46
  • [I am seeing some warnings regarding these new MSI service constructs on MSDN](https://msdn.microsoft.com/en-us/library/windows/desktop/dd407945%28v=vs.85%29.aspx). Essentially: "*...this functionality is not working as expected*" (last year). Accordingly I have never spent time testing them out. Custom actions allow you to do pretty much anything, but they are terribly error prone. The more you do, the higher the risk of deployment problems that are hard to fix. The sequencing, impersonation and conditioning issues are challenging. Do it all in a custom action? Possible: yes. Easy: no. – Stein Åsmul Apr 14 '18 at 01:57
  • [Just cross-linking another answer](https://stackoverflow.com/a/49802335/129130). Maybe have a quick skim. The sc.exe tool is probably something you can try. – Stein Åsmul Apr 14 '18 at 02:03
0

I have found a solution for this after digging for sometime .

I am creating new C# custom action project and i am sequencing my action before InstallInitialize.

In my C# custom action method, i am reading the existing installed file version by using FileVersionInfo.GetVersionInfo(filePath);

Then i am checking with desired version which i want to check and if condition matches i am killing my service process using 

 foreach (Process proc in Process.GetProcessesByName("ProcessName"))
 {
      proc.Kill();
      session.Log("Service Killed");
 }

in order to achieve this, Wix toolset v3.11.1 has to installed beforehand

Praveen M
  • 443
  • 2
  • 11
  • Immediate mode custom actions run without elevated rights. They will not have access to kill a service if the MSI is launched in a locked-down managed environment where users have standard rights (not admin rights). I assume you succeed because you launch your MSI from an elevated command prompt or you elevate via the UAC prompt - selecting yes to elevate whilst installing the MSI? The access problem will manifest itself if you try to deploy via AD / group policy. Is this a package for your own use or for large scale distribution? – Stein Åsmul Apr 18 '18 at 03:46
  • One of the primary requirement to install our package is, only admin can install the package . if the non admin user tries to install the package it will ask for admin credentials . Considering this i think this solution is fine . what are your thoughts? – Praveen M Apr 18 '18 at 05:01
  • So all users will have admin rights or just the installing user? What happens if you trigger **modify** or **repair** or **self-repair** from a **standard user account**? You should test that at least - **a runtime error is likely**. You can condition the custom action to only run when the user has elevated rights, check the [**Privileged property**](https://msdn.microsoft.com/en-us/library/windows/desktop/aa370852%28v=vs.85%29.aspx). For large scale distribution I would be very sceptical, for smaller distribution for a few PCs it might get the job done. – Stein Åsmul Apr 18 '18 at 16:32
  • Just want to make it clear that **I do recommend you run such an action properly elevated**. How about checking in immediate mode for whether to kill the process or not, and then set properties to indicate whether a CloseApplication call in deferred mode should do the process killing? All you would remove from your immediate mode custom action is the process killing, and what you would set would be something like a DOKILLPROCESS property or similar. And you would condition your CloseApplication element with that property. That condition should be very carefully made to apply only when needed. – Stein Åsmul Apr 18 '18 at 16:46
  • When normal user tries to uninstall, modify or repair, it will ask for admin username and pwd and after correct input, it will run in administrator mode. Yes i completely agree with your statement. it is always safe to run these kind of action in elevated mode. – Praveen M Apr 19 '18 at 06:05