Windows Installer related information reposted on the Internet

(1) Q: What kind of product is Windows Installer?
A: Windows Installer is a system service used to install and manage applications in the system. It provides a standardized method and means for application development, customization, installation and upgrade.

(2) Q: What basic functions are provided by Windows Installer?
A: Windows Installer provides the following basic functions:

-- Transaction-type operation. All installation operations are in the transaction format. For each operation performed by Windows Installer, it generates a corresponding Undo operation to cancel the user's modifications to the system as needed. If an error occurs during installation, Windows Installer can restore the system back to the status before installation.
-- Self-healing. Windows Installer supports the "self-healing" capability of applications. Applications can check for various common security issues, such as file or registry key loss issues at startup, and automatically fix themselves.
-- Install on demand. Windows Installer supports on-demand installation of applications. For example, the spelling check function of Microsoft Office Word is not installed by default, but you can also install this function as needed.
-- Installation in the "locked" environment. In a fully locked environment, users generally do not have the permissions or capabilities required to install the application. In most cases, they do not have the "write" permission on the computer's "Program Files" folder or the HKEY_LOCAL_MACHINE registry location. For example, if the administrator allows users to install a package through a group policy, Windows Installer can install the program on behalf of users.
-- Status management. Windows Installer provides a set of standard Win32? Application programming interfaces (APIS) and automated interfaces, which administrators can use to query the installation status of programs on their computers. The API can query the current state of a program, verify the existing state, or repair the damaged state, and transition from one state to another.

(3) Q: Windows Installer V2.0 is the latest version of the product. What new and improved functions are provided in version 2.0?
A: Compared with earlier versions, Windows Installer of Version 2.0 includes a large number of new features and improvement features, such:

-- Install and manage components. Windows Installer 2.0 is fully integrated with the sxs (fusion) and Common Language Runtime (CLR) components ..
-- Higher security. The architecture of Windows Installer has been modified to improve security.
-- The ability to hide personal information. Windows Installer provides the author with a method to hide information (such as passwords) in log files.
-- Isolation between multiple users. Modifications made to the Windows Installer architecture enable real isolation for each user's installation, because the configuration of each user on the product is no longer shared among multiple users.
-- Supports digital signatures. Digital signature support is already included in files related to Windows Installer, such as software packages (. MSI), patches (. MSP), and conversions (. MST ). Windows Installer can also perform digital signature verification on the Installation-related external. cab file.
-- More robust patches. Version 2.0 fixes many patch issues.
-- Simplifies the patch production process. In version 2.0, the successful resolution of patch conflicts eliminates the burden on users in the patch preparation process. Developers who develop and install programs for Version 2.0 no longer need to track each disk ID and the last serial number used by the previous patch.
-- The patch and upgrade File Installation process has been improved. Version 2.0 reduces unnecessary source code parsing attempts. In most cases, when a patch is applied, the user is no longer requested to access the location of the original program unless the creator of the patch and upgrade files emphasizes this. In addition, because you do not need to copy files unrelated to version changes, the upgrade process is more efficient.
-- Supports conversion and patch from URL source. Version 2.0 of Windows Installer now allows the use of conversion and patch from URL (Unified Resource Locator.
-- Enhancement of operating system features. With System Restoration and Software Restriction Policies (windows? XP functions and features) integrated, and improved support for terminal services.
-- 64-bit windows 64-bit service. Windows Installer is a born 64-bit service that can install 64-bit applications on 64-bit windows.
-- Enhanced logging capability. The event logging has been greatly improved to help technicians solve problems encountered during installation. This includes ensuring that each error has a unique event ID.
-- Configurable merging module. Improved mergemod. dll allows users to create merging modules (. MSM files). These files contain attributes that can be configured by users of the merging module.

(4) Q: Where can I obtain more information about Windows Installer?
A: For more information about Windows Installer, see Windows Installer sdks.

For more information about Windows Installer, see the following White Paper:

-- Windows Installer Service Overview
-- Windows Installer: Advantages and implementation process

(1) Q: Which versions of Windows include Windows Installer?
A: Microsoft Windows 2000, Windows Millennium Edition (Windows ME), and Windows XP include Windows installer. Windows 2000 includes Windows Installer of Version 1.1, Windows ME includes version 1.2, and Windows Installer of Windows XP is 2.0. Windows 2000 sp3 also contains Windows Installer of version 2.0.

(2) Q: Which operating systems does Windows Installer support?
A: The following table details the operating systems supported by each version of Windows installer.

 

(3) Q: Where can I get the latest Windows Installer reseller?
A: You can use the Microsoft platform SDK redistributables site to obtain the latest version of the Windows Installer redistribution program. The Windows Installer redistribution program has two different versions: one applies to Windows 95, Windows 98, and Windows Me, And the other applies to Windows NT and Windows 2000.

(4) Q: I need to resend these technologies in my Installer. Where can I obtain the merge modules for Microsoft technologies?
A: The Microsoft merge module is provided along with Microsoft Visual Studio. NET. Their default installation location is [programfilesfolder]/common files/merge modules. Note: not all Microsoft redistribution components have available merging modules.

(1) Q: How can I hide an application in 'add or delete project?
A: To hide an application in 'add or delete', set the arpsystemcomponent attribute to 1. This attribute can be set in the command line, in the 'properties' table of the package, or through conversion. On Operating Systems earlier than Windows 2000, you can set the arpnoremove attribute to 1 to hide the application in 'add or delete project. In Windows 2000 and Windows XP operating systems, arnoremove can disable the 'delete' button in 'add or delete a project.

(2) Q: After I edited my. MSI Package Multiple times in orca, the package size increased significantly. How can I reduce the. MSI file size?
A: The database format of the. MSI package is based on OLE structured storage. Frequent edits to the database result in the emergence of fragments, which wastes some space. You can use the 'Save As 'command in Orca to reduce the size of the. MSI package. You can also use msidb.exe to export all tables, and then import these tables to a new database to reduce the size of the package.

The orcaand msidb.exe tools can be obtained through the Windows Installer SDK.

(3) Q: How do I hide the 'cancel' button during installation?
A: Starting from Windows Installer 2.0, we provide a command line option to hide the 'cancel' button when a simple installation interface (UI) is displayed. The following command line script demonstrates how to use this new option:

Msiexec/I {path to package}/QB!
You can also use the msisetinternalui Win32 API and use installuilevel_hidecancel and installuilevel_basic to hide the 'cancel' button. Alternatively, you can use msiuilevelhidecancel and msiuilevelbasic in combination when using the Windows Installer object to read and write the uilevel attribute. This can be achieved through Windows Installer automation.

During program installation, the existence of the cancel button can be changed through a DLL or script Customization Operation. This operation will send an installmessage_commondata message. The custom DLL operation uses the msiprocessmessage Win32 API to send the installmessage_commondata message. In this message, Field 1 is set to '2', and field 2 is set to '0 '. To unhide the 'cancel' button, you can still use this message, but set field 2 to '1 '. Custom scripts use the message method of the session object.

(4) Q: How can I install only the features I want?
A: You can use the addlocal, addsource, and advertise attributes to install certain features. The following command line script can install the 'Sports 'and 'news' (News) features in the example. MSI package on a local computer.

Msiexec/I example. MSI addlocal = sports, news/qb
The following command line script can advertise the 'Sports 'feature and install the 'new' feature to run these features from the source program.

Msiexec/I example. MSI advertise = sports addsource = News/qb
Another important note is that the name of a feature is case sensitive.

(5) Q: How can I forcibly upgrade a version-independent file during the upgrade even if the user has modified the file?
A: By creating a version number for the file in the 'file' table, you can 'force upgrade' a file irrelevant to the version during the upgrade. According to the file version control principle of Windows Installer, a file whose version changes will overwrite a file that is not related to the version. Note that all subsequent reinstallation processes need to access the source program, because all subsequent Version checks will indicate that the file needs to be reinstalled.

(6) Q: How can I correctly write the path string?
A: The Directory property value ends with a directory separator. Therefore, directory separators are not required for writing path strings.

Incorrect syntax: [directoryproperty]/somelocation
Correct syntax: [directoryproperty] somelocation

(7) Q: How should I develop products for different geographic regions?
A: For products of different versions, such differences can be different in product languages or product functions. You can use different product codes. In order to specify the direction, be familiar with the relationship between products, and share the same Upgrade Code with the product.

(1) Q: What is a managed application?
A: managed applications are programs that administrators can control during installation and maintenance. Managed applications are often used for large-scale software deployment. For system administrators, managed applications allow users to install authorization software in a 'lock' environment. In this environment, you generally do not have the required permissions to install the software.

An application is considered managed if the following conditions are met:

Users can be installed or advertised by members of the (Administrator) group.
It can be installed and advertised by members of the Administrators group on a computer basis.
Administrators can assign or publish data on Windows 2000 or later operating systems.
It can be marked as a managed program by other software or deployment management systems. The specific method depends on the management system used by the user, but the Administrator usually needs to complete this operation.
The installation package cannot claim to be 'managed 'by itself. Whether the program is a 'managed' program is controlled by the system administrator.

Note: 'managed 'is different from 'permission escalation. Applications with elevated permissions refer to programs running with system permissions during installation. All managed applications are permission escalation programs, but permission escalation programs are not necessarily managed programs, which are determined by the alwaysinstallelevated policy. For security reasons, this policy is disabled by default. before using this policy, you must carefully consider its potential hazards.

(2) Q: What are the differences between adminuser and privileged attributes?
A: If the user who performs the installation operation is an administrator, the adminuser attribute will be set. If the user is allowed to install the program using the elevated permissions, the privileged attribute will be set. If you are an administrator, you can use the upgraded permission to install the program, whether you set the alwaysinstallelevated policy by user or by computer, or, the program has been assigned to the user by the system administrator.

If the user is an administrator, the attributes of adminuser and privileged will be set. If the user is not an administrator, the adminuser attribute will never be set. In this case, if the Administrator has granted permissions to the installer through assignment or policy, the privileged attribute will be the only property to be set.

In many cases, we recommend that you use the privileged attribute instead of the adminuser attribute to install the application assigned by the Administrator.

(3) Q: Should users with user-level permissions be allowed to install MSI programs?
A: If the Administrator permits, users with user-level permissions can install managed applications. Otherwise, you can only install MSI applications that write files, create directories, and write registry keys at the locations that match your permissions. If you cannot write data at a certain location, the installer cannot write data at this location unless the Administrator has granted the write permission to the installer.

(1) Q: What is the difference between the 'latest' custom operation and the 'Instant 'custom operation?
A: The 'latest' Customization Operation can only be performed on installinitialize or installfinalize in subsequent tables as subsequent operations. The "immediate" customization operation can be performed anywhere in the subsequent table.
The 'delay' custom operation cannot access the installed database. In fact, the 'latest' custom operation only has limited access to the installation session, because the installation script can be executed outside the installation session where the script is created. You can access the installation database by using the "immediate" Custom operation. You can also read and set the installation attributes, modify the features and component status, and add temporary rows, temporary columns, temporary tables, and other things.

Although both the 'latencies 'and 'Instant' custom operations can run in the user context environment where the installation is initiated, however, the system context environment can be used for only the 'latest' custom operation to get the upgraded permission.

The 'delay' custom operation cannot be executed immediately. Instead, they run during script execution according to the preset schedule. The execution script is not processed until the installexecute, installexecuteagain, or installfinalize operations are run.

(2) Q: When should I use a delayed custom script instead of an instant custom script?
A: If a custom operation must modify the system or call another system service, you must use a delayed custom script. In addition, only delayed custom operations can run in a context with elevated permissions. If your custom scripts can run only with elevated permissions, You need to mark the custom scripts as 'latest' scripts. Note: You can only mark the installer as a custom operation running in the system context environment (msidbcustomactiontypeinscript + msidbcustomactiontypenoimpersonate) when the permissions are elevated.

In addition, if you want to modify the system through a custom operation, you should also include a custom rollback operation to undo the modification and restore the system back to the previous state.

(3) Q: How can I provide data to my delayed custom scripts?
A: delayed customization only allows limited access to the installation session. If your delayed Customization Operation cannot obtain installation information through this limited access, you can use the customactiondata attribute to provide this information for delayed customization operations. This method is only effective for customizing scripts and DLL latencies. The procedure is as follows:

The Instant Customization Operation performed before the delayed Customization Operation uses the same name as the delayed Customization Operation to set an attribute as the value required for the delayed Customization Operation. Therefore, if the primary key name of the delayed Customization Operation is 'descriredca', the custom operation will set the attribute 'descriredca' to the value required for the delayed Customization Operation. Type 51 custom operations can easily set this attribute. Another method is to use the 'szname' parameter to call msisetproperty. The szname parameter is equal to 'referredca '. Note: The operation name is case sensitive.
After the delayed Customization Operation is queued into the installation script, the installer will write the 'referredca' attribute value to the installation script and use it as the value of the customactiondata attribute.
During execution, the delayed custom script calls the msigetproperty with the szname parameter to obtain the required value. The szname parameter is equal to customactiondata. Or, the 'properties' attribute of the session object is used for the script Customization Operation.

(4) Q: Can I use a custom operation to restart my computer?
A: You can call msisetmode by using the running mode of msirunmode_rebootatend or msirunmode_reboot and the status value equal to 'true'. You can restart the computer by customizing the operation now. Because msisetmode requires an hinstall handle, only the DLL and script customization operations can restart the computer. The Custom Script operation uses the 'pattern 'attribute of the 'session' object. Alternatively, you can use the szaction parameter that is equal to 'schedulereboot' to call msidoaction.

The delayed Customization Operation cannot call msisetmode. Delayed customization requires you to set the value at a certain location in the registry. This value will be customized immediately and subsequently read by installfinalize. Then, you can use msisetmode to set the computer restart schedule. If you need to use this method, you should also provide a customized rollback operation to delete the key value that can trigger restart from the Registry when you cancel the installation.

(5) Q: How can I add information to a log file for my custom operations?
A: You can use the msiprocessmessage API to send the installmessage_info message. dll and script customization operations can add information to the log file. The Custom Script operation uses the 'message' method of the 'session 'object.

(6) Q: How many msiexec.exe processes will run on my computer when installing the program?
A: Multiple msiexec processes are running during program installation. This occurs mainly because Windows Installer uses the client-server mode to execute the program installation task. In addition, for security considerations, Windows Installer will resident DLL and script customization operations in a 'sandbox' process. Depending on the initialization method of the installation process, an msiexec process acts as a client process. Another msiexec process serves as a Windows installer. All msiexec processes running on a computer are generally sandbox processes used to host custom operations. The specific process of deciding which msiexec process will be used as a sandbox process for script or DLL custom operations depends on whether the custom operation runs in an elevated permission or in a personalized manner, and whether the custom operation is 32-bit or 64-bit.

1) Q: What is the difference between small, secondary, and major upgrades?
A: A 'Min' upgrade is a product upgrade that only modifies a small number of files or adds only a small amount of new content. The 'secondary 'upgrade is a product upgrade that makes modifications to the product to change the product version number, while the 'main' upgrade greatly modifies the product, so that you need to modify the product code for the product upgrade activity. The following table summarizes the product changes made by each upgrade method and the possible distribution carrier forms for each upgrade method.

To some extent, you can consider a small upgrade as a hot fix or quick fix Engineering (QFE) upgrade, and a secondary upgrade as a service package, the major upgrade is the product upgrade.

Minor and minor upgrades can be considered to be basically the same except for minor upgrades that change the product version. They follow the same principles as patches. Both small and secondary updates require explicit re-installation. Major upgrades are not subject to this restriction, and patches do not need to be re-installed. In addition, minor and minor updates have limited modifications to the functional component structure of the package. The main upgrade will significantly modify the functional component structure of the program.

(2) Q: When will the patch need the original source file?
A: Windows Installer 2. A lot of improvements have been made to minimize the number of times the patch requires the original source file. However, in the following special cases, it still requires the original source file:

-- The patch applied to a feature is currently running in the source file. In this case, the feature will transition from the 'run-from-source' state to the local state.
-- The component to be patched has a problem (File loss or damage ).
-- The file to be patched is included in a component. The component also contains files unrelated to version changes and does not have an msifilehash project. A filled msifilehash table is required to prevent reproduction of these files irrelevant to version changes from the source location.
-- There is a reinstallmode option with the value 'amus' when patching an application. This option is dangerous because it ignores the file version to copy the file. As a result, the earlier file is revised, so it always requires the source file. We recommend that you set the value of reinstallmode to 'omus '.
-- The cache package of the product is lost. Cached packages are required for patches. The cached package is stored in the '% WINDIR %/installer' folder.
-- The package is designed to call the resolvesource operation. This operation should be avoided as much as possible, or only used under certain conditions, because executing this operation will always cause the system to access the source file.
-- The package has a custom operation, which attempts to access the source file in some way.

-- A patch package consists of binary patch files that cannot be applied to the current version of computer files. See the following example:
1. Install the RTM version of the sample product. This will install example. dll of version 1.0 to your computer.
2. Apply the patch qfe1.msp on your computer. This patch upgrades example. dll from 1.0 to 1.1.
3. The new patch qfe2.msp has been released. It can upgrade example. DLL to version 1.2. However, this patch is only applicable to version 1.0 of example. dll, because it is generated by RTM of this product. In version 1.2, example. dll includes all patches in example. dll 1.1, but MSP is generated between the RTM and qfe2 images. Therefore, if qfe2.msp is applied on a computer, Windows Installer needs to access the original source file. The binary patch of example. dll cannot be applied to version 1.1. It can only be applied to Version 1.0. This causes the installer to re-copy example. dll of version 1.0 from the original source file so that the patch can be successfully applied.

(3) Q: How can I prevent my patch from accessing source files?
A: currently, you cannot completely prevent the patch from accessing the source file. However, the following steps can help you reduce the number of times the program accesses the source file:

-- Use a patch that only contains the complete file. This eliminates the need to create Binary patches based on each previously released patch and the RTM version of the product. Set the value of the includewholefilesonly attribute in the 'properties' (attribute) Table of the patch creation properties (patch creation attribute, PCP) file to '1 ', you can easily create a patch that contains only the complete file.
-- Make sure that all your custom operations do not access the original source file location.
-- Make sure that the resolvesource operation is only executed under certain conditions, or does not exist at all.
-- Create a 'msifilehash' table for all files in the package that are not related to version changes. The Windows Installer sdkpackage uses a tool named 'msifiler.exe 'and a script named 'wifilver. vbs', which can automatically complete this task.

(4) Q: Why is my file not updated even though my patch has been successfully applied to a computer?
A: This is probably because you simply double-click a small or secondary update Patch. Minor or minor updates require a clear re-installation process for the files to be upgraded. You can use the msiexec command line to complete this operation, and include the reinstall and reinstallmode attributes in the command line command (that is, msiexec/P {path to my patch. MSP} reinstall = All reinstallmode = omus ). Another method is to include a custom operation in the patch to set the reinstall and reinstallmode attributes. You should be sure that you impose strict restrictions on the conditions for performing this operation, only during the first application of the patch. Subsequent re-installation of the product should not result in the execution of this custom operation, otherwise your product may become undetachable. Other methods include calling msiapplypatch using a startup execution file and setting the correct attributes, or using a Windows Installer Automation Object to write a patch application using scripts.

(5) Q: Can I upgrade a custom operation through patches?
A: Yes. You can use the patch to upgrade a custom operation. If custom operations are included in the 'binary 'table, you can simply upgrade the custom operations in the upgrade and installation image. If you use the original file and upgrade the installation image to create a patch, the patch will contain a database conversion and convert the old binary data stream into a new binary data stream.

(1) Q: How can I find out the cause of package installation failure?
A: There are three better methods to track the installation issues of the package. The first method is to verify that your package is valid. Through verification, you can find errors and warnings, and find some common installation program creation problems. There are two tools to verify the installation package, both of which can be obtained through the Windows Installer SDK: msival2 and orca. Msival2 is a command line tool used to verify the package. Orca provides a graphical user interface for verification and highlights invalid entities in the package.

The second method is to use Application Event Logs. Windows Installer records the Success and Failure Information in the Application Event Log.

The last method is to generate a detailed log file. Analyze the detailed log file and find out the root cause of the error. Wlogutl.exe of Windows Installer sdk.exe helps you analyze detailed log files. You can enable logging by using the Windows Installer logging policy, or by appending '/L * V path to logfile' to the msiexec command line.

To obtain detailed log files through a policy, use the following registry key:

HKLM/software/policies/Microsoft/Windows/Installer
Set: logging = REG_SZ voicewarmup
Set: DEBUG = REG_DWORD 0x7

Log files generated by using the policy key are stored in the user's '% Temp %' folder in the format of msixxxxx. log.

Note: The log records generated through the command line have a higher priority than all log record policies.

(2) Q: Every time I start a program, Windows Installer will install it. How can I determine the reason for this on-demand installation?
A: There is a way to easily identify the cause of on-demand installation, that is: Find the msiinstaller log information in the following format in the Application Event Log:

Event Type: Warning
Event Source: msiinstaller
Event ID: 1001
Description:
The detection product '{000c1109-0000-0000-c000-000000000046}' and the feature 'example 'fails when the request component' {00030829-0000-0000-c000-000000000046 }'

Event Type: Warning
Event Source: msiinstaller
Event ID: 1004
Description:
Detection product '{000c1109-0000-0000-c000-000000000046}', feature 'example ', component' {00030829-0000-0000-c000-000000000046} 'failed. Resource 'C:/progam files/example/example.exe 'does not exist.

The first information (event ID 1001) indicates which component is being installed. The components listed here are the components specified in the component column of the shortcut cut (shortcut) Table for special shortcuts.

The second message (event ID: 1004) indicates which component fails during detection. The improved Event Log feature of Windows Installer 2.0 has updated the information so that in most cases, you can find the root cause of the failure. If the Key Path of the component is lost or damaged, the user may reinstall the program.

In the preceding example, You need to reinstall the program because the resource 'C:/program files/example/example.exe 'does not exist. You should find out why the key path does not exist-in this example, it is because the user deleted the file.

(3) Q: How can I determine If Windows Installer has installed my features or components?
A: It is very easy to determine whether Windows Installer has installed a specific function or component. You can find the answer in the Windows Installer's verbose log file. First, you need to find the log information of the installvalidate operation. This operation records the installation, request, and operation status of each function and component in the package.

MSI (s) (5c: F4): execute Operation: installvalidate
Operation start 1: 51: 18: installvalidate.
MSI (s) (5c: F4): function: example; installation: absent; Request: Local; Operation: Local
MSI (s) (5c: F4): component: example; installation: absent; Request: Local; Operation: Local
Operation ended 1: 51: 18: installvalidate. Return Value 1.

In the preceding log file segment, the 'example 'function will be installed locally, because its operation status is 'local, the 'example 'component will also be installed locally based on the specified operation status.

(4) Q: Why is my file not deleted during the uninstallation process?
A: There are four main reasons for this problem:

The components to which these files belong are marked as permanent ). (This can be achieved through the attributes column of the component table)
None of the components to which these files belong have the guid of the component. (The value in the componentid column of the component table is null ). Windows Installer cannot manage components without a guid.
If the key path of a component has a shared DLL refcount, the component cannot be detached.
If the component is installed in the system folder and a file in the component has an externally shared DLL refcount when the program is uninstalled, the component cannot be uninstalled.

(5) Q: Why is my folder not deleted when the program is uninstalled?
A: The folder cannot be deleted during program uninstallation. The following are the main causes:

When the createfolder table and createfolders operation are used simultaneously, the removefolders operation in the sequence table is lost.
This folder is not created by Windows Installer, so it will not delete them unless you tell Windows installer to delete these folders.
There are still Resources in the folder.

(6) Q: Why is my registry key not deleted during program uninstallation?
A: The following are the most common causes of uninstallation of the registry key:

1. The Registry table contains objects marked with '+. This symbol indicates that the installer retains these registry keys when uninstalling the program.
2. In the installexecutesequence table, the removeregistryvalues operation is performed after the unregisterprogidinfo and unregistermimeinfo operations. You need to reverse the order of these operations. Certain registry key values written to the Registry table prevent specific progid, extension, and CLSID keys from being deleted.

(7) Q: Why is the disk space occupied during the installation process much larger than the actual size of the file I installed?
A: Windows Installer calculates two types of disk occupation: disk occupation with rollback operations, and space occupation without rollback operations. The disk space occupied by the program installation is not rolled back. The space occupied by the rollback operation includes the space occupied by the backup files required for the rollback operation during installation. In addition, Windows Installer calculates some additional space required for installation. This includes the space occupied by the installation script and the space required by the cache package. In addition, during installation, the installer needs to temporarily copy the installation package. The space occupied by the installation script and package running copy is temporary. After the installation is complete, these files will be cleared. See the following example. In this example, the size of your installation package is about 80 KB, And you are installing a 4 kb file. (Note: depending on the size of the hard disk cluster, your number may be different from mine ):

89120 bytes (the cached MSI is basically an integer multiple of the 4 kb cluster size)
89120 bytes (temporary working copy of MSI)
8192 bytes (estimated script size)
4096 bytes (small file, equivalent to a 4 kb disk cluster)
----------------------
176128 bytes = 172 KB

(8) Q: Why does Windows Installer prompt me to restart my computer?
A: If Windows Installer needs to overwrite a file in use or the installation package explicitly requires the installer to restart the computer, Windows Installer will prompt you to restart. We can easily determine whether Windows Installer prompts you to restart your computer because it needs to overwrite a file in use. First, we need to generate a detailed log file. In this detailed log file, check whether the replacedinusefiles attribute exists in the property section. If this property exists and the value is 1, the installer will initiate a request to restart the computer because it needs to overwrite a file in use.

To determine which file is being used, scan the log file and find the information 'info 1603 'and 'Info 1903'. Information 1603 is recorded in the log file by the installvalidate operation. For example:

MSI (s) (DC: DC): execute Operation: installvalidate
Operation started 19: 55: 42: installvalidate.
...
Info 1603. The file 'd:/test/sample.exe 'is being used by the following processes: Name: sample.exe, ID: 4068, window title: 'sample '. Close the program and try again.

Generally, the 'filesinuse' dialog box appears when the message is displayed. However, this dialog box does not appear when the 'quiet' UI is used. In addition, not all files in use will appear in the 'filesinuse' dialog box. If a file in use is not an executable file, the process holding the file is a process related to the installation process, or the process holding the file does not have a window title related to it, the 'filesinuse' dialog box may not be displayed.

The filecopy opcode in the installation script also records the info 1603 information in the log. In the preceding example, the log file contains:

MSI (s) (DC: DC): executing OP: running, 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 in use. Close the program and try again.

At the end of the script during file cleanup, the following log file information indicates the 'culprit 'that requires the user to restart the computer ':

Info 1903. Set the restart schedule: delete the file 'd:/config. MSI/12544a31. RBF '. You must restart to complete the operation.

The file name is '12544a31.rbf', but 'sample.exe 'is stored on the file. To install the file, the file in use will be renamed as the. RBF file and deleted after restart.

(9) Q: What does 'error _ install_package_version error (1613) mean?
A: 'error _ install_package_version 'indicates that Windows Installer on the computer does not support the architecture of this package. The package architecture is pointed out by the pid_pagecount attribute in the package summary information stream. If the architecture Number of the package is greater than the maximum architecture supported by Windows Installer, You need to upgrade the version of Windows Installer or re-create the installation package to compile it using the earlier architecture.

The minimum architecture supported by all versions of MSI is 30.
The maximum architecture number supported by each version of MSI is as follows:
Windows Installer 1.0: 100
Windows Installer 1.1: 110
Windows Installer 1.2: 120
Windows Installer 2.0: 200

(10) Q: When I started an installation process with a system account, I got the error code 2103. Why?
A: starting a program installation from a system account (such as the Scheduled Task Service) may cause a 2103 error. If you perform a user-specific installation, this will happen. The system account can only be used for computer installation, because the system account cannot access all necessary user configuration folders.

(11) Q: Why is error 2755 displayed when I install a ing drive on the terminal server?
A: Windows 2000 and earlier operating systems do not support transferring the ing drive letter information between Terminal Server sessions. Because the Windows Installer Service runs as a service in the console session, the mapped drive disk created in the remote session is invisible to the Windows Installer Service, this error occurs. This error occurs only when the service runs in the application server mode, but not in the remote admin mode.

Note: Windows XP and later operating systems do not have this restriction.

(12) Q: Why do I get a security warning dialog box when I install a package that uses Web to download the Startup File? The message in the dialog box is "An error occurred while accessing the online cancel server '?
A: The security alert dialog box appears because a problem occurs when the start file (setup.exe) is downloaded from the Web to perform digital signature verification. We have solved this problem through the latest sample code provided by the Windows Installer SDK. This SDK can be obtained from Microsoft download center. You only need to use the tool to re-configure setup.exe. You can download the corrected sample code from the SDK Update site.