[wix-users] Avoiding Files In Use and Reboot During Upgrade/Uninstall with WMI Provider

[Bryan Dam]

For anyone in the future so interested: the solution was to use the Civ2:MSFT_Providers class to determine if my providers were loaded, what process they are running in, and call the UnLoad method.  The caveat being that merely unloading them isn't enough to free up the files: you need to wait for the process to shut down.  Do this right before InstallFiles and you should avoid files in use.  However, once installed the providers can't be used until the WMI service itself is restarted or you use the MSFT_Providers.Load method to load them again.  Note: the docs for the Load method marks TransactionIdentifier as 'for future use' but you must provide a valid GUID surrounded by curly brackets.

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Bryan Dam via wix-users
Sent: Friday, August 20, 2021 1:15 PM
To: wix-users at lists.wixtoolset.org
Cc: Bryan Dam <bryand at recastsoftware.com>
Subject: [wix-users] Avoiding Files In Use and Reboot During Upgrade/Uninstall with WMI Provider

We recently acquired some new software that I'm integrating into our installer that has a WMI provider.  When the provider is called the WMI subsystem will load the provider DLLs and keep them in memory for a few minutes until they are unloaded.  If we attempt an upgrade/uninstall when they are loaded Restart Manager dutifully does its thing:
>RESTART MANAGER: Detected that application with id 6188, friendly name 'WmiPrvSE.exe', of type RmCritical and status 1 holds file[s] in use.

So that's working as designed but this app is an agent that runs silent background without any user interaction.  It will get deployed silently to 100s of thousands devices across our customers.  They are not going to be receptive to taking a reboot for it.  What's more, the company we acquired solved this problem by writing their own pre-elevate wrapper EXE that basically did all the real install/uninstall itself.  Which is to say that the bar has already been set for never requiring a reboot though I'm not a fan of the wrapper solution.

Any ideas of how to handle this without a wrapper?

I tried writing a custom action that uses AssemblyInstaller to remove the WMIProvider assembly (WMI.NET requires them to have a class that derives from DefaultManagementInstaller) but I realized all too late of course that any kind of deferred action like that will happen after InstallValidate anyways.

There's the CloseApplication element but I can't indiscriminately kill 'WmiPrvSE.exe' since there could be several instances and I might even be sharing that instance with other providers.

Is there a way to add a wait time (unelevated) or run an elevated custom action before InstallValidate?  Or maybe some other thing I haven't thought of.

         Bryan

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=04%7C01%7Cbryand%40recastsoftware.com%7C8ca70b041553476d3f6d08d963fe13fa%7C9315bb44634846c6bd378880b87e774e%7C0%7C0%7C637650765197590567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=M0eCYmK9Inj1s%2Bm91keA9ubx7pv2C2BG%2BLszwxBSrVc%3D&reserved=0