Home » Windows OSRSS

MSIEXEC - Keeps shutting down my app!

Hello All,

I am currently trying to solve a problem regarding a windows forms app which is running msiexec to install an MSI.

The MSI installs and registers a single DLL.  As part of the update process, I instanciate the COM object that the dll contains, query its version, and release the COM object. If an upgrade is required, I install a newer version of the MSI, containing the new file.

If the MSI has already been installed, and a newer version of the MSI is to be installed (with removepreviousversions = true), the call to MSIEXEC actually closes my parent app!

Call to MSI exec:

msiexec.exe /i c:\msi\mymsi.msi /qn /norestart

The following features in the MSI Install log (with verbose and extra debugging switches on):

MSI (s) (40:74) [14:38:06:141]: RESTART MANAGER: Will attempt to shut down and restart applications in no UI modes.
MSI (s) (40:74) [14:38:06:141]: RESTART MANAGER: Detected that application with id 3676, friendly name 'MyApp', of type RmUnknownApp and status 1 holds file[s] in use.
MSI (s) (40:74) [14:38:06:141]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (40:74) [14:38:06:141]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (c) (B0:F8) [14:38:06:172]: RESTART MANAGER: Session opened.
MSI (s) (40:74) [14:38:06:203]: RESTART MANAGER: Successfully shut down all applications in the service's session that held files in use.
MSI (c) (B0:F8) [14:38:06:203]: RESTART MANAGER: Successfully shut down all applications that held files in use.

I am still investigating why the .NET app hasnt released the dll, but that is on a different thread in this forum (http://social.msdn.microsoft.com/Forums/en-US/clr/thread/9353d00f-5115-4dcb-9d8e-07a47eff3f87/)

Is there a way instruct MSIEXEC to NOT close applications that hold files? Isnt there functionality that Windows Installer provides that installs the files after a reboot instead of closing all apps that hold a referenced file open?

Any help would be greatly appreciated!

Kind Regards,

Matthew Dendle

 

10 Answers Found

 

Answer 1

I don't think Windows Installer does this unless you sign up for it, so it depends what MyApp is (the Dll is irrelevant). For example, if your app is MFC maybe you checked the Support Restart Manager checkbox.
 

Answer 2

Hello Phil, and thank you for your reply! MyApp is a click-once deployed c# app, targeting .net frame v2. (x86) The MSI I'm trying to install has nothing to do with the MyApp application - the "MyApp" application simply handles updating a separate piece of software by downloading and installing these MSIs as necessary. The MSIs in question were constructed using visual studio 2010 deployment projects. The top-level MSI options don't seem to list anything that sounds like the feature I want to turn off. Does the VS2010 IDE allow for this level of configuration? Thanks again Phil, Matt
 

Answer 3

Hi Matt,

 

Thank you for the feedback. I can repro it locally. If you do not add “/qn” parameter, Windows Installer will prompt a dialog to notify you the application which occupies the file that is going to be updated. When “/qn” parameter is added, it shut down the application without notification.

 

Sincerely,

Kira Qian

MSDN Subscriber Support in Forum

If you have any feedback on our support, please contact msdnmg@microsoft.com
 

Answer 4

Hello Kira,

Thanks for taking the time to reproduce my problem!

Is there no other way to prevent this behaviour? I have a UI which installs a large set of MSIs, and turning on the MSI UI for each one would make things very awkward - I need to install around 18 MSIs. Plus, I dont want to give the user the option of closing my app and restarting it - as I'd have to start the process again!

Must the App be restarted? I was under the impression that Windows Installer could replace in-use files after a reboot, rather than having to close and re-open an App.

Kind Regards,

Matt

 

 

Answer 5

I think ive found the answers I need now, but one question remains...

First, let me share my solution.

In order to prevent MSIEXEC from shutting down applications which the RESTART MANAGER thinks has a "hold" on a file that needs updating (E.g.-  (MSI (s) (40:74) [14:38:06:141]: RESTART MANAGER: Detected that application with id 3676, friendly name 'MyApp', of type RmUnknownApp and status 1 holds file[s] in use.)

Set the property MSIRMSHUTDOWN=2 (see http://msdn.microsoft.com/en-us/library/aa370380(VS.85).aspx)
(you can set in the command line, at the end)

Using this property, the restart manager does not shut down the applications that it thinks have a hold on files that need updating. Using this property will make MSIEXEC return an exit code of 3010, which basically means "success, but a restart is required"

However - there is still something that I dont understand - I have confirmed that the program doesnt have a lock on the file itself when the MSI is started - so why does the restart manager think my app has a hold on it?

(I confirmed this by renaming the dll file after my call to the COM object, and disposing the object - at least I hope this is confirmation)

Can anyone tell me why the restart manager thinks my app has a "hold" on the file?

Thanks for your help in advance,

Matt

 

Answer 6

Hi-

 

In looking at this and checking with colleage, to determine exactly why this hold is seen in this instance may take some time.

You might consider posting on https://connect.microsoft.com/

or checking out support options here:

Your issue falls into a category that we are not able to resolve using the forums.   Please visit

the below link to see the various paid support options that are available to better meet your

needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

 

 

 

 

 

Answer 7

Hello Bill,

Thank you for looking into this.

With regards to the connect system, Should I post this as a bug?

I will wait to hear from you otherwise.

Thanks Bill,

Matt

 

Answer 8

This is not a bug only from our side. I won’t recommend doing it.

Citrix also involved here. Check this citrix Article http://support.citrix.com/article/CTX125453

 

Answer 9

After having opened a support case with Microsoft, I have a solution to my problems.

It turns out that the file was still loaded in my process.  They (Mircosoft) used WinDbg to list the modules that my exe had, and sure enough, the dlls were there.

The solution comes in two flavours - one for managed COM callable dlls, and the other for unmanaged com dlls.

For managed COM callable dlls, the solution is to instanciate the object in its own AppDomain, then unload the appdomain, which in turn unloads the dll in question.

For COM dlls, the solution involved using a pinvoke to CoFreeUnusedLibraries() in the ole32.dll, which releases unused libraries.  This must be called after calling Marshall.FinalReleaseCom to make sure reference counts are zero.

This solution ensured that the windows installer did not associate the files to my app.

I hope this helps ppl,

Let me know if anyone needs more info.

Thanks,

Matt

 

Answer 10

After having opened a support case with Microsoft, I have a solution to my problems.

It turns out that the file was still loaded in my process.  They (Mircosoft) used WinDbg to list the modules that my exe had, and sure enough, the dlls were there.

The solution comes in two flavours - one for managed COM callable dlls, and the other for unmanaged com dlls.

For managed COM callable dlls, the solution is to instanciate the object in its own AppDomain, then unload the appdomain, which in turn unloads the dll in question.

For COM dlls, the solution involved using a pinvoke to CoFreeUnusedLibraries() in the ole32.dll, which releases unused libraries.  This must be called after calling Marshall.FinalReleaseCom to make sure reference counts are zero.

This solution ensured that the windows installer did not associate the files to my app.

I hope this helps ppl,

Let me know if anyone needs more info.

Thanks,

Matt

 
 
 

<< Previous      Next >>


Microsoft   |   Windows   |   Visual Studio   |   Follow us on Twitter