通过

Insights into the underlying Windows Installer reboot behavior.

  • 项目

Here are a set of frequent and infrequent questions around Windows Installer's reboot behavior

Question

What happens if the user reboots their machine during an installation?

Answer

This is called a suspended installation. If you’ll search the archives for the alias, you will found more information. The equivalent condition is a loss of power for the machine during an install. The installer keeps track of the installation in-progress. When resumed, the user has the option to rollback the suspended install or continue the suspended install.

If you want to try out the default user experience, then add a ForceReboot Action [Windows Installer] to a sample installation package and say "no" to the reboot. Then try to do another installation and see what happens.

If you’d like to code for this condition, please see MSDN Topics: Preselected property [Windows Installer], RESUME property [Windows Installer], and Sequence Table Detailed Example [Windows Installer].

Question

What happens when a file is in use on uninstall? If it is marked for deleting in place on reboot. will a reboot be required before an install of the same file by another install? If it is first moved to a temp directory or renamed and then marked for delete on reboot, is a reboot not required before an install of the same file by another install?

Answer

When you uninstall MSI and the file being uninstalled is in use and all of the following are false

  • The files in use are not executables.
  • The installer is not actually trying to install those files.
  • The process holding those files is the process invoking the installation.
  • The process holding those files is one that does not have a window with a title associated with it.

the user will be given a FilesInUse Dialog with the option to RETRY, CANCEL or IGNORE.

If you choose Ignore,

  • the file in question will be renamed and placed in Folder Config.rbf where it will be deleted upon reboot.

  • An entry such as the following will be placed in the log per Logging of Reboot Requests [Windows Installer]

     MSI (s) (BC:24) [15:23:14:208]: Verifying accessibility of file: 2841496c.rbf

Info 1903. Scheduling reboot operation: Deleting file D:\Config.Msi\2841496c.rbf. Must reboot to complete operation.

I any of the first four bullets are true or if this is a quiet uninstall, the above Ignore case will happen automatically.

Question

RemoveExistingProducts Action [Windows Installer] is uninstalling a product that wants to reboot on uninstall. How can I trigger a reboot immediately after RemoveExistingProducts rather than waiting until the end of the install?

Answer

A product removed via RemoveExistingProducts that requires a reboot has the reboot propogated to the "parent" -- i.e. the new product. If you want to trigger a reboot at that moment rather than having it occur at the end of the installation you'll have to modify the InstallExecuteSequence table of the new product to call ForceReboot. To do this selectively, condition the action to only run in the scenarios you want it to run. Thus, you can use a custom action and do the following work.

You can of course query the reboot status from the parent installation for the actual install using MsiGetMode for MSIRUNMODE_REBOOTATEND. This happens when the nested install requires a reboot due to files in use or ScheduleReboot action.

If MsiGetMode returns true for a reboot at the end after RemoveExistingProducts, then you can set a property that triggers the ForceReboot action (which was conditionalized on that property).

Of course, you should probably differentiate between your installation requiring a reboot during installation of files versus your older product removal requiring a reboot.

The CA is not deferred. RemoveExistingProducts starts the nested uninstall immediately when encountered. If the custom action is not deferred, then it can only run as the user. Even if that was the case where it would have to be deferred, the concept of least privilege would mean that you wouldn't want it to run as system.

The properties used in conditions for your actions should be PUBLIC.

Question

Why is Windows Installer prompting for a reboot?

Answer

(ported from FAQ answer)

Windows Installer may prompt for a reboot if it installs over a file that is in use or the package explicitly requests that the installer reboot. It is easy to determine if Windows Installer prompts for a reboot because it installed over a file that is in use. The first step is to generate a verbose log file. In the verbose log file, look for the presence of the ReplacedInUseFiles property in the property dump. If this property is present with a value of 1, then the Installer will require a reboot because it overwrote an in-use file.

To determine which file was in-use, scan the log file for "Info 1603" and "Info 1903" messages. The 1603 message will be logged by the InstallValidate action. For example:

 
 

MSI (s) (DC:DC): Doing action: InstallValidate

Action start 19:55:42: InstallValidate.

…

Info 1603. The file d:\test\sample.exe is being held in use by the following process: Name: sample.exe, Id: 4068, Window Title: 

'Sample'. Close that application and retry.

Normally, this message coincides with the presentation of the FilesInUse dialog box. In silent UI cases, this dialog box will not be presented. Additionally, not all files that are in use will show up in the FilesInUse dialog box. The FilesInUse dialog box may not be displayed if the files in use are not executables, the process holding the files is the process invoking the installation, or the process holding those files is one that does not have a window title associated with it.

The FileCopy opcode in the install script can also log the 1603 info message. In the above example, the log file contains:

 

 

MSI (s) (DC:DC): Executing op: FileCopy(SourceName=sample.exe, SourceCabKey=sample.exe, DestName=sample.exe, Attributes=0, 

FileSize=2044928, PerTick=32768, , VerifyMedia=1, , , , , CheckCRC=0, Version=2.0.2600.0, Language=0, InstallMode=59244544, , , 

, , , )

…

Info 1603. The file D:\test\sample.exe is being held in use. Close that application and retry.

At the end of the script during cleanup, the following log file message identifies the culprit for the reboot:

  

Info 1903. Scheduling reboot operation: Deleting file D:\Config.Msi\12544a31.rbf. Must reboot to complete operation.

While the file is named 12544a31.rbf, it is the Sample.exe file. In order to install the file, the in-use file was renamed to the .rbf file and will be deleted upon reboot.

Question

Can I upgrade to MSI 3.0 and install my agent before rebooting?

Answer

Yes. This is called Delayed Reboot. Unfortunately this particular MSDN topic can be challenging to find as it’s written in the topic describing the redistributable. For MSI 2.0 and before, see Instmsi.exe [Windows Installer].  For MSI 3.0 and beyond see Windows Installer Redistributables [Windows Installer]

Question

We have two products one called Server and the other called Agent. Basically agent is sub-set of server, where server and agent products can exist on same box. So, we are creating a single patch by specifying two targets in TargetImages of PCP file. When we apply a patch on a box where it has one server feature and agent, it is patching only server. The patch isn’t getting applied to agent.

Answer

The patch would work, except that the first product required a reboot to complete...

  

MSI (s) (A4:48): MainEngineThread is returning 1641

This automatically halts the processing of the MsiApplyPatch loop for installed targets. If the MainEngineThread had actually returned 0 (ERROR_SUCCESS) and not 1641 (ERROR_SUCCESS_REBOOT_INITIATED), then the 2nd product would have been patched.

This is one of the know limitations of patching multiple products. The processing stops if a reboot is required. MsiApplyPatch basically works as follows:

  
status = ERROR_SUCCESS
Read List of Target Products For Patch
    While 
        If Product Is Installed
            status = RunEngine(Product, PATCH="path to patch")
        End If
        Next Product
    Wend

Your log file indicates a return of 1641 -- this is not ERROR_SUCCESS and halts the processing. The reboot occurred because the Installer had to replace a file in use. Per the log file:

  
Property(S): ReplacedInUseFiles = 1

And the file in question is:

  
Information 1603.The file D:\Program Files\Application 2005\AppCommon.dll is being held in use.  Close that application and retry.
Information 1603.The file D:\Program Files\Application 2005\AppCommon.dll is being held in use.  Close that application and retry.

According to the log file, there was no window title associated for the application holding it in use, therefore the user was not prompted to shut down the app

Question

How are global assemblies treated differently than normal win32 files?

Answer

Perhaps the documentation is somewhat lacking in the area, but it's important to recognize that global assemblies are treated completely different from normal Win32 files -- especially with regards to MSI. The same "reboot" style replacement behavior that MSI has is not available to global assemblies unless the underlying assembly technology implements it. MSI is not responsible for the actual installation and removal of global assemblies. That process is delegated to fusion and sxs based upon the assembly type. Thus regardless of whether the file was in use or not, there's nothing that MSI does about as it pertains to the actual placement of the file bits on the machine.

All four are of course possibilities -- with each one addressed in different ways.

Files in use detection

There are known issues (with bugs filed in Longhorn) against detection of assemblies that are in use. And it's not exactly clear cut. Because MSI doesn't control the installation of assemblies, it doesn't know where the files were placed. The file table and directory table authoring included in the MSI does not accurately reflect the actual name and location of the global assembly on disk. Are their ways to find out that information? Possibly in some cases -- and in particular for .NET assemblies however those hooks aren't in place. In essence, a translation is needed for files in use detection in MSI between the "name" as authored in the MSI package and the actual file as installed by fusion or sxs.

Also, the file that is reported in use isn't the SXS assembly file. Rather, it's the file in the system32 directory. As mentioned above, there is no files in use detection by MSI for assembly files (either .NET or sxs). Your package actually also installs this DLL to the system directory and the file that is detected in use is the "normal" win32 installation file. This is easily determined by the fact that the opcode used is FileCopy rather than AssemblyCopy. All global assemblies are installed using the AssemblyCopy opcode.

  
MSI (s) (E0:40): Executing op: FileCopy(SourceName=RTCRES.dll,SourceCabKey=RTCRES.dll1.A1940191_0A44_4654_AFBE_ADD73C234286,DestName=RTCRES.dll,Attributes=16384,FileSize=138320,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=4.2.4949.1001,Language=103
3,InstallMode=59244544,,,,,,)
MSI (s) (E0:40): File: C:\WINDOWS\System32\RTCRES.dll;  Overwrite;  No patch;  Existing file is of an equal version
MSI (s) (E0:40): Source for file 'RTCRES.dll1.A1940191_0A44_4654_AFBE_ADD73C234286' is compressed
InstallFiles: File: RTCRES.dll,  Directory: C:\WINDOWS\System32\,  Size: 138320
MSI (s) (E0:40): Re-applying security from existing file.
Info 1603. The file C:\WINDOWS\System32\RTCRES.dll is being held in use.  Close that application and retry.

c:\windows\system32\rtcres.dll is not the sxs assembly file. As mentioned before (and documented on MSDN), the files in use UI in the InstallValidate action will only display the application holding the file in use if there's an associated window title.

Error message

I agree that an error message with an HRESULT is ugly. The assembly error messages have undergone a number of changes in recent versions, including the addition of specialized error messages for certain scenarios (error codes 1936-1938).

However, you can customize the error message -- that's what the Error table is for. Office has customized a number of Windows Installer error messages to better fit their requirements and wording. Just keep the number of parameters the same. Alter the error message for 1935 so that the HRESULT doesn't show up in the user visible portion. The documentation on the Error table provides information on how you can alter error messages so that some portions show up in the log file and not in the user's UI.

Currently, it's this:

  
An error occurred during the installation of assembly '[6]'. Please refer to Help and Support for more information. HRESULT: [3]. {{assembly interface: [4], function: [5], component: [2]}}

Change it to this:

  
An error occurred during the installation of assembly '[6]'. Please refer to Help and Support for more information. {{HRESULT: [3]. assembly interface: [4], function: [5], component: [2]}}
Reinstall Component

Normally if the global assembly component was already installed, the CostFinalize action would log a "Skipping installation of assembly component '%s' because it already exists" message. However, that doesn't happen here and the reason is related to the REINSTALLMODE settings. As documented in the Windows Installer documentation on MSDN, "Reinstallation Modes of Common Language Runtime Assemblies", the reinstallmode values affect global assemblies different from normal files.

According to the log file, you set the REINSTALLMODE to "ecmus". Note that 'c' in REINSTALLMODE implies additional checking of global assembly status such that a QUERYASMINFO_FLAG_VALIDATE is provided to fusion/sxs to check the state of the assembly. Also, I can't confirm any authoring but for win32 sxs assemblies, the keypath of the component should not be the catalog or manifest file.

Error with In-Use Assembly

I'll have to defer this to the sxs team as there appear to be issues with how sxs handles assembly files in use. This is outside of the control of MSI at this point and regardless of whether or not the user was presented with files in use information, the user has the option to not shut down the application -- thus leaving the file in use. Therefore, sxs still needs to handle this situation. Note there's a longhorn bug against this exact situation with no particular resolution between the integrated behavior of MSI and SXS.

Question

How does the file replacement work after the reboot?

Answer

PendingFileRenameOperations to replace in-use files after the reboot - these are copied over very early in the boot by the session manager. It is a fairly simple process involing some temporary files and a registry value that you could script or create a custom action for. Here's how it works: 181345: How to replace in-use files at Windows restart

Question

I have a patch created using MSI 3.0, it patches an NT Service. As part of the patch installation I stop and start the service at the appropriate time and avoid a reboot. When the patch is uninstalled from Add/remove I’m being prompted for a reboot. ( since the NT Service was not stopped).

Answer

If you stopped and started the service via a custom action that was added in the patch, then the service won't be stopped. The documentation on MSDN for patch uninstall discusses patch uninstall custom actions and dictates that those custom actions included in a patch being removed are not executed. It also offers further details on what you can do to make it work.

Question

How do I customize the default ScheduleReboot Message (no change to the OK button)?

Answer

Reboot messages come from the error table if authored...

  • Error message ID 1703 controls reboots from ScheduleReboot if no more than 1 user is logged on to the machine.
  • Error message ID 1732 controls reboots from ScheduleReboot with more than 1 user logged on to the machine (TS scenario).

The customization can occur in the Error table. As authored today, they are:

  • 1702 The installer must restart your system before configuration of [2] can continue. Click Yes to restart now or No if you plan to manually restart later.
  • 1732 In order to complete the installation of [2], you must restart the computer. Other users are currently logged on to this computer, and restarting may cause them to lose their work. Do you want to restart now?

Note that when customizing error text, do not alter the formatted values (eg. [2]).

Question

Why am I getting a reboot prompt even though I say force the update of the MSI?

Answer

some data can be found in the documentation: Logging of Reboot Requests. From the log file:

  
Info 1603. The file C:\Program Files\Host Integration Server\system\mngagent.exe is being held in use.  Close that application and retry.
Info 1603. The file C:\Program Files\Host Integration Server\system\snamanag.dll is being held in use.  Close that application and retry.
Info 1603. The file C:\Program Files\Host Integration Server\system\mngsna.dll is being held in use.  Close that application and retry.
Info 1603. The file C:\Program Files\Host Integration Server\system\mngbase.dll is being held in use.  Close that application and retry.
Info 1603. The file C:\Program Files\Host Integration Server\system\hostproc.exe is being held in use.  Close that application and retry.
Info 1603. The file C:\WINDOWS\system32\Msvcp60.dll is being held in use.  Close that application and retry.
Info 1603. The file C:\WINDOWS\system32\Msvcp60.dll is being held in use.  Close that application and retry.
Info 1603. The file C:\WINDOWS\system32\Msvcp60.dll is being held in use.  Close that application and retry.
... 


 
MSI (c) (64:68) [16:15:52:088]: GetWindowTitle: FilesInUse record has 0 for ProcessID - Unexpected
MSI (c) (64:68) [16:15:52:088]: Window with Title could not be found for any of the Files-In-Use

...
 
MSI (s) (78:9C) [16:16:24:981]: Executing op: FileCopy(SourceName=nthstreg.dll,SourceCabKey=nthstreg.dll.D63986A2_2A53_40FD_A4FA_E59F0C52F277,DestName=nthstreg.dll,Attributes=0,FileSize=28944,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=5.0.0.2037,Language=1033,InstallMode=130023424,,,,,,,)
MSI (s) (78:9C) [16:16:24:981]: File: C:\Program Files\Host Integration Server\system\nthstreg.dll; Overwrite; Won't patch; REINSTALLMODE specifies all files to be overwritten
MSI (s) (78:9C) [16:16:24:981]: Source for file 'nthstreg.dll.D63986A2_2A53_40FD_A4FA_E59F0C52F277' is compressed
MSI (s) (78:9C) [16:16:24:981]: Re-applying security from existing file.
MSI (s) (78:9C) [16:16:31:509]: Verifying accessibility of file: nthstreg.dll
MSI (s) (78:9C) [16:16:31:525]: Note: 1: 2318 2: C:\Program Files\Host Integration Server\system\nthstreg.dll 
MSI (s) (78:9C) [16:16:31:525]: Note: 1: 2360 
Info 1603. The file C:\Program Files\Host Integration Server\system\nthstreg.dll is being held in use.  Close that application and retry.
...
 
MSI (s) (78:9C) [16:17:06:772]: PROPERTY CHANGE: Adding ReplacedInUseFiles property. Its value is '1'.

...
 
MSI (s) (78:9C) [16:18:48:356]: Product: Microsoft Host Integration Server 2000 SP 2 -- Configuration completed successfully.
 
MSI (s) (78:9C) [16:18:48:356]: The Windows Installer initiated a system restart to complete or continue the configuration of 'Microsoft Host Integration Server 2000 SP 2'.
 
MSI (s) (78:9C) [16:18:48:372]: Cleaning up uninstalled install packages, if any exist
MSI (s) (78:9C) [16:18:48:372]: Post-install cleanup: removing installer file 'C:\WINDOWS\Installer\5051cba.msp'
MSI (s) (78:9C) [16:18:48:388]: MainEngineThread is returning 3010

The Installer sets the ReplacedInUseFiles property to 1 when it overwrites a file that is in use. The reboot will be triggered because of that (unless REBOOT=ReallySuppress is set). From the FileCopy opcode, the file that was in use was nthstreg.dll.

Question

What are the circumstances a reboot can occur?

Answer

A reboot can be triggered in one of the following ways:

  1. ForceReboot action evaluates to true in package
  2. ScheduleReboot action evaluates to true in package
  3. Installation overwrites a file that is in-use
  4. CustomAction calls MsiSetMode to trigger reboot

Easiest way to know that you hit case #3 is if the ReplacedInUseFiles property is set to 1. If it is, you'll reboot.

Question

Our customers are seeing Event ID: 1025 from Event Source: MsiInstaller such as the following

  

Event Type:       Information
Event Source:    MsiInstaller
Event Category: None
Event ID:           1025
Date:                12/28/2004
Time:                1:05:19 AM
User:                SETUPSRV2\Administrator
Computer:         SETUPSRV2

Description:

Product: Microsoft ISA Server 2004. The file D:\Program Files\Microsoft ISA Server\msfpc.dll is being held in use by the following process Name: msiexec , Id 1856. 

Data:

0000: 7b 30 41 43 39 35 44 39   {0AC95D9
0008: 37 2d 31 42 37 35 2d 34   7-1B75-4
0010: 41 43 37 2d 42 30 36 31   AC7-B061
0018: 2d 46 32 31 45 33 37 39   -F21E379
0020: 46 46 38 30 39 7d         FF809}

So we're wondering

  • Is the source for this in Windows Installer? In W2K? Why does this happen?
  • Do these messages indicate some kind of problem we should relate to?
  • Are there implications to these messages/their cause on the installation process?

Answer

Those are information messages and are logged anytime MSI detects a file in use. The eventlog message was added per request by the Windows reboot team so that they could use it in gathering data about machine reboots. They have tools to collect eventlogs from premier customers. The information can help them learn more about why system reboots were caused (they can correlate this data in the app event log to the data in the system event log (where reboot initiations are logged)).

Thus, this is really data gathering info.

Question

I've a question about temporary transforms. When I start an installation with applied transform, the msi-client makes a copy of the transform and save this at %Userprofile%\temp. The msi-service makes another copy of the transform and save at %windows%\installer. After installation, msi is attempt to delete the files. When I create an installation-log, the following entries are shown:

Server process:
  

MSI (s) (6C:5C) [10:35:39:497]: Attempting to delete file C:\WINDOWS\Installer\18a0ffc6.mst 
MSI (s) (6C:5C) [10:35:39:497]: Unable to delete the file. LastError = 32 
MSI (s) (6C:5C) [10:35:39:529]: MainEngineThread is returning 0 
MSI (c) (28:FC) [10:35:39:529]: Back from server. Return value: 0
Client process:
  

MSI (c) (28:FC) [10:35:40:700]: Attempting to delete file C:\DOCUME~1\akerl\LOCALS~1\Temp\18a55b7f.mst 
MSI (c) (28:FC) [10:35:40:700]: Unable to delete the file. LastError = 32 
MSI (c) (28:FC) [10:35:40:732]: Grabbed execution mutex. 
MSI (c) (28:FC) [10:35:40:732]: Cleaning up uninstalled install packages, if any exist 
MSI (c) (28:FC) [10:35:40:763]: MainEngineThread is returning 0

The tempfile of the server process is deleted correctly, but the temp of the client process is not deleted. I see this problem on every msi-version, in all cases, when I use a transform.

Answer

A couple of things that are important to note:

  • The installer makes local copies of transforms, patches, and the installation package to run from
  • For security reasons, the service process cannot trust a local temp copy in the user's space (and conversely the client process most likely doesn't have the rights to cache the file in a secure location)
  • The installer makes its best attempt to track temporary copies of files and has a multi-step mechanism for addressing clean-up
    1. The engine itself keeps track of the temp copies and tries to delete when it terminates (this is what you see from those logged lines)
    2. An opcode is created CleanupTempFiles to register files for post-install clean-up. You'll see this from the "Scheduling file '%s' for deleting during post-install cleanup (not post-reboot)."
    3. Once the install completes, the service will read the post-install cleanup list and attempt to cleanup those files on the list.

You'll note from the logged messages that the failure to delete the file is due to a sharing violation. This is somewhat expected when you think about it -- the calling process still has the database open, thus the transforms are left open as well. However, only the engine knew about the transforms so when it failed to delete the file it couldn't get the client to try again later (no communication mechanism in that direction). The difference between the client and service behavior is that the service has the delay cleanup option available to it whereas the client does not.

Note that the inability to delete a temp copy of a file is not deemed a fatal error.

Question

What is the best practice to quit / kill a process running under a system tray icon during uninstall?

Answer

Start by consulting the System Reboots topic for more details. Excerpted here:

  
If you expect the installer to display a FilesInUseDialog, but it does not, this may be due to one of the following reasons:

The files in use are not executables. 
The installer is not actually trying to install those files. 
The process holding those files is the process invoking the installation. 
The process holding those files is one that does not have a window with a title associated with it.

SysTray apps generally fall into the above categories. You can always use a custom action to shut down the process during uninstall. The custom action possibility is available with all versions of MSI. As for the best method to shut down the process -- the application owner should really be the best qualified person to answer. There are Win32 API (searchable on MSDN) for killing processes (eg. TerminateProcess) but many have their own pros and cons that you'll have to evaluate. TerminateProcess is usually not a highly recommended approach. Some additional information can be found in the following KB article: How to terminate an application "cleanly" in Win32.

Question

I’m uninstalling a product on Windows Server 2003. At the time of uninstall, one of the product’s DLL is in use. The log file generated during uninstall contains the following entry:

  

MSI (s) (A0:CC): Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1903 

Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\bdc5d1.rbf. Must reboot to complete operation.

In spite of the message indicating that reboot is necessary, I’m not prompted for reboot when uninstall completes. Is there some sort of bug in my install program or is this by design?

I thought that reboot was going to automatically occur to avoid the above scenario, but apparently this isn’t so. Can someone comment on this scenario and suggest what we might do overcome this problem?

Answer

Generally this can be safely ignored.

The only authoring degree of freedom with reboots is the REBOOT Property [Windows Installer] and generally folks want less reboots not more.

.rbf files are internal copies (technically the moved original) of the files that Darwin keeps for Rollback Installation [Windows Installer] purposes. Al this says is that Darwin is going to put an entry into the windows registry to delete this file at the next reboot of the system.

The behavior by Windows Installer is by-design. This is related to the functionality that Windows NT offers for handling in-use files. Win9X systems used a replace on reboot model for updating files that were in-use. WinNT systems provided a better model that helped eliminate unnecessary reboots by providing a move-and-replace model. The Installer makes full use of the WinNT model on those platforms. When the file is in use and must be removed, the installer can simply rename it to some secret location and then schedule it for deletion at a later time. Since nobody else can find the file (they usually ask for it by its former name), the delete-on-reboot portion of the update is considered optional. Why reboot for a file that none knows about?

Currently there is no way to turn off the Installer's reboot-ignore behavior on file removal. If the behavior doesn't fit your model (and you're identified one such occurrence), then adjust your setup to make it work. You can either ensure that your file is not held in use by getting all users to unload it or alternatively authoring your setup to force a reboot for the scenario. At this point, the only identification of the state is the 1903 message sent to the log file (or to an external UI handler). There are no properties that are set to identify the scenario as ReplacedInUseFiles is only set when the Installer actually overwrites an existing in-use file.

Question

What is the impact of customers using system restore rather than MSI uninstall?

Answer

First, Windows Installer already integrates with system restore. A system restore point is created at application installation and at application uninstallation. The application of a small/minor update Windows Installer MSP does not result in a new system restore point being created.

System restore is not available on the Server platform nor on Windows 2000. System restore has been an option for users to undo changes made to the system. The limitations of system restore include whether or not a restore point has actually been created or is still available. System restore has its own algorithm/timeline for when restore points are created and when they are aged out. There are integration points for application installations -- which is why MSI utilizes it.

Additionally, prior to MSI 3.0 there were possibilities of problems when using system restore and dealing with MSPs. Unfortunately system restore does not monitor MSP files, so if you obsoleted a patch and then restored to a point prior to that patch having been obsoleted, you'd have a problem if the patch's source was no longer available. The behavior in MSI 3.0 fixes this problem by not removing obsoleted patches (they stay around for the purposes of patch uninstall).

As for the choice to use system restore -- it's more brute force than MSI. It will always require a reboot and additionally it can remove more things than just the most recently applied patch. In answer to your question, the two technologies are already integrated and MSI patch removal is a necessary addition to servicing support. I think it adds value between the two.

System restore won't call into MSI. The mechanism for system restore is completely different. It has a file system driver to monitor file changes and it also monitors registry changes. It also has an exclusion list to exclude certain locations on disk (like the user's My Documents folders). System restore does not monitor user data file extensions.

When you select to restore to a particular point, it restores the entire state of the system that it had captured to that prior state. This includes registry and files. If you want more details, then consult the system restore documentation:

Question

When REBOOT property [Windows Installer] is set to ReallySuppress what happens to the reboot?

Answer

SDK says

ReallySuppress:

Suppress all reboots and reboot prompts initiated by ForceReboot during the installation. Suppress all reboots and reboot prompts at the end of the installation. Both the reboot prompt and the reboot itself are suppressed. For example, reboots at the end of the installation, caused by an attempt to install a file in use, are suppressed.

Question

What happens when a file is in use?

Answer

If an install package supports the FilesInUse Dialog [Windows Installer], the user will be given an opportunity to shut down the app provided all of the following are false

  • The files in use are not executables.
  • The installer is not actually trying to install those files.
  • The process holding those files is the process invoking the installation.
  • The process holding those files is one that does not have a window with a title associated with it.

Question

What happens if a user does not shut down the app thus the files remain in use?

Answer

A verbose log will include one or more of the errors 1603, 1732, 1902, 1903, 3010 (per Logging of Reboot Requests [Windows Installer], Windows Installer Error Messages [Windows Installer] and Error Codes [Windows Installer]). If the file isn’t hard locked, then the windows installer will move the in use file to the rollback cache and place the new file in the place of the in use file. If the move to the rollback directory is blocked (by hard locking) the PendingFileRenameOpertions hive is used. For the former case, shutting down and restarting the app is required. For the latter case, rebooting the OS is required.

Content credit also belongs to

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.

Comments