Best Practices Microsoft

Build more secure applications using Microsoft Security Development Lifecycle (SDL)

The Microsoft SDL – Developer Starter Kit offers content, labs, and training to help you establish a standardized approach to rolling out the Microsoft Security Development Lifecycle (SDL) in your organization—or enrich your existing development practices.

This Kit provides a compliation of baseline developer security training materials on the following core Microsoft Security Development Lifecycle (SDL) topics:
a) secure design principles;
b) secure implementation principles;
c) secure verification principles;
d) SQL injection;
e) cross-site scripting;
f) code analysis;
g)banned application programming interfaces (APIs);
h) buffer overflows;
i) source code annotation language;
j) security code review;
k) compiler defenses;
l) fuzz testing;
m) Microsoft SDL threat modeling principles; and
n) the Microsoft SDL threat modeling tool. Each set of guidance contains Microsoft Office PowerPoint slides, speaker notes, train-the-trainer audio files, and sample comprehension questions.

All materials have limited formatting so that you can leverage the content to achieve broader, enhanced adoption of Microsoft SDL principles in your development organization.

Download the Starter Kit Here

Other References

How-to Microsoft Windows Installer, Application Compatibility and Deployments

Troubleshoot the error 1603 “Fatal Error During Installation”

This error message is displayed by the Microsoft Windows Installer Engine (Wondering whats this? Read here) and is a general error code that indicates a problem occurred during the installation. Read on this article to learn how to sidestep this speed bump. The following is the probable list of known causes for this error to occur:

  • Short file name creation is disabled on the target machine.
  • An Install Script custom action is prototyped incorrectly.
  • A file is locked and cannot be overwritten.
  • The Microsoft Windows Installer Service is not installed correctly.
  • The Windows Temp folders are full.
  • The setup was corrupted after installation and, therefore, fails with this error during un-installation.
  • An older version of Install Shield Developer is being used.
  • Print and File sharing is not installed if your application needs it.

Troubleshooting 1603 MSI Error

As discussed, The 1603 error code is mostly returned when any action fails during an installation on Windows, and most commonly it indicates that one of the custom actions in the MSI failed. When we encounter a failed setup with return code 1603, here are the steps that we should follow:

Re-run the setup with verbose logging enabled using steps similar to those that are listed here.

Step 1: Generate a verbose log file named msi*.log in the %temp% directory the next time the setup package is executed. (Click here to know more ways to generate log). Know more about the command-line switches here.

msiexec /i <msipath>setup.msi /l*v c:\temp\msi.log

Step 2: Open the verbose log in a text editor such as notepad and search for the string “return value 3”. In nearly all cases, this will take us to the section in the verbose log that lists the action that failed that initially caused setup to rollback.

Step 3: Review the contents of the log file immediately above the “return value 3” string to determine which custom action or standard action failed. Depending on which action is failing, We will need to proceed to more detailed debugging from here.

One can find that the biggest hurdle to debugging a failed setup is often zeroing in on which part of the setup is actually failing, and this trick of searching for “return value 3” ends up helping speed this process up in nearly all cases. Of course, it does not work in 100% of scenarios.

You can find some ways of troubleshooting the logs here –

“Access your favorite Windows Applications from your Android/iOS device with a virtual desktop by of the best Desktop as a Service providers. Get a free trial of Office 365 and excellent support by

Known Solutions

The following solutions have resolved this error in the majority of cases:

  1. Make sure short file name creation is enabled on the target machine. You can check to ensure that the target machine does not have short file name creation disabled by navigating to the following registry entry:

    Make sure the value “NtfsDisable8dot3NameCreation” is equal to 0. This indicates that short file name creation is enabled. A value of 1 indicates that this functionality is disabled. You should change the value to 0. After modifying this value, the target machine should be rebooted before attempting to launch the setup again.

    Note: If the target machine should normally have short file name creation disabled, it can be disabled after the install completes by resetting “NtfsDisable8dot3NameCreation” to 1 and rebooting.
  2. To ensure that the Windows Installer Service is properly installed and configured, it is recommended that users install the file InstmsiA.exe on Windows 95/98/Me or InstmsiW.exe on Win NT systems. These files are shipped with your InstallShield product and are located in the following location: <Product Path>\Redist\Language Independent\i386. If the service is installed, to know the status of the service exection, you could also goto services.msc in the command prompt, check the status of the Windows Installer Service. “Stopping and restarting it can help”
  3. Empty all temporary folders. The specific temporary folders for a machine can be determined by accessing the DOS prompt and typing set. Note the values listed for TEMP and TMP, and delete all files in those locations.
  4. Make sure no other applications, including utilities such as virus scanners, are running in the background. Close all running applications and utilities, and launch the installation again.
  5. If this error occurs during un-installation, use the Microsoft Windows Installer CleanUp utility to uninstall the installation. Once the installation has been successfully un-installed, you can then debug the project to determine what caused the original error.

If it doesn’t fall in this last, it could be any other error which occurred during the installation, do update in the comments..lets fix that..!

LinkedIn and other Discussions

I had also posted this on LinkedIn Discussions and have got some quality responses for the same – I will extract some information from there and post it here so that, you can get all the information at one single place.

A Senior Desktop Analyst, Jack Fei writes,

Vijay has makes some excellent points about how to troubleshoot these types of issues. From my experience, the fix is usually trivial once you understand “how to correlate verbose logging results” with msi internals.

First, know that “installation” means msiexec.exe sequentially processing rows of the InstallExecuteSequence table inside the msi database.

Second, know that msiexec.exe processes the commands sequenced between InstallInitialize and InstallFinalizes in two passes. A way to think about it is the first pass “conditionally installs the change” to the machine while checking the syntax of the command and the second pass “commits the change to the machine”. A 1603 essentially means “an error occurred” trying to commit the change, causing msiexec.exe to “backout the change”.

This type of error is either caused by msi misengineering (most vendor msi are misengineered) or by an “machine specfic issue”. So Patrick Pepin makes an excellent suggetion to check the msi vendor.

Having VMWare or imaging tool really helps troubleshoot this type of issue.

1. I would determine the issue can be reproduced on a clean machine with all pre-requisites installed (just to eliminate the possibility false negative caused by testing on an unknown or corrupt pc environment).

2. If it is a capture msi (original source is non-msi) I would systematically exclude files and registry keys until I isolated the component causing the issue in my msi. I built it, so I know best how to fix it.

3. if the msi was engineered by another vendor, I would review the verbose log and isolate the failing instruction in the InstallExecuteSequenceTable. My major technique was to find the failure that generated the “1603” error and find the likely instruction that caused it. To test my theory, I would comment out only that instruction (put a negative sign in the sequence column) and rerun the command. Sometimes, I would get lucky and even “work around” the msi defect by leaving the custom action commented out. This type of change works great when the custom action is doing “unnecessary checks” for desktops in your environments. Obviously, I would “test the modified msi” and make sure the application installed and starts cleanly.

4. If I can reproduce the problem on a clean desktop, I will have good ammunition to contact the vendor. However, my experience is if you know how to do what I have outlined, you will exhaust the technical support departments of whatever vendor you call. This is done for “political reasons” more than anything else – so you can be the hero when the vendor despite considerable persistance from you, can not find a solution.

Good luck. Hope this helps.

Community Activities Microsoft Windows Installer, Application Compatibility and Deployments

Webinar: Get Installations Ready for Windows 7

Join the Windows 7 experts to learn more about preparing installations for Windows 7. The Acresso team is presenting a webinar which will highlight the new features of Windows 7 and Installer 5.0 which will impact the existing software installations.  This webinar will present solutions on how to overcome the potential pitfalls such as compatiblity issues. Further, it would showcase on how to use the InstallShield® to get the application installations ready for Windows 7.  There would also be a live Q&A session after the webinar.

Make sure you make the best of this webinar by registering now.

Date: Tuesday, October 13, 2009
Times: 11am ET, 2pm ET, and 7pm ET
Registration Link:

Microsoft Windows Installer, Application Compatibility and Deployments

How do I install a Windows Installer Patch?

Consider a scenario where a single file in the application has undergone a change, and this file needs to be replaced in all the machines where it is Installed. In such a situation, it doesn’t make sense in creating a new package and deploy the same. Also, if we have any configuration file which the user has modified for his customization, re-installing the package will also replace those files. Hence, we will need to find a way to replace only that file.., without reinstalling the application package. That is where a patch comes into picture. 

Keeping it simple, a patch is basically the file from which changes to an already installed application is done. Also, a Patch can be installed individually, if the previous MSI already exists in the system. A windows Installer Patch file, will usually have an extension of .msp.
How to Install a Patch
When you run the patch Silent/unattended, the dialogs are not displayed and the required property like REINSTALL are not set. Hence, we will need to define this in the command line for Patch Installation.


Also, double-clicking the .MSP file will patch an existing installation as well as the locally cached copy of the MSI database because the dialogs are run and they in turn set REINSTALL and REINSTALLMODE properties.

Advantages of Using Patches:

  1. A patch can contain an entire file or only the file bits necessary to update part of the file. This will enable the user to download an upgrade patch that is much smaller than the installation package for the entire product.
  2. Create and install patches that can be uninstalled singly, and in any order, without having to uninstall and reinstall the entire application and other patches.
  3. Skip actions associated with specific tables that are unmodified by the patch. This can significantly reduce the time required to install the patch
  4. An update using a patch can preserve a user customization of the application through the upgrade.
How-to Windows Installer, Application Compatibility and Deployments

Access MSI Database in Deffered Context through Custom Actions

Deferred custom actions have limited access to the installation session. If your deferred custom action requires information about the installation that it cannot obtain through its limited access, then you can provide that information to the deferred custom action through the CustomActionData property. This method is only available to script and DLL deferred custom actions.

“How-to” make this work??

1.An immediate custom action that executes before the deferred custom action sets a property with the same name as the deferred custom action to the value that is needed by the deferred custom action. So, if the primary key for a deferred custom action is called “DeferredCA,” then the immediate custom action would set a property called “DeferredCA” to the value that was needed. A type 51 custom action would be an easy way to set this property. Another method would be an immediate custom action that calls MsiSetProperty with the szName parameter equal to “DeferredCA.” Note: The action name is case-sensitive.

2. When the deferred custom action is queued into the installation script, the installer will write the value of the property “DeferredCA” into the installation script as the value of the property CustomActionData.

3.Upon execution, the deferred custom action retrieves the value by making a MsiGetProperty call with the szName parameter equal to “CustomActionData.” Alternatively, a script custom action would use the Property property of the Session object

Best Practices How-to Microsoft

Darwin Descriptors in Windows Registry – Cryptic Strings

The most common method of ensuring applications remain highly available is through Windows Installer file associations. This mechanism operates very much the same way as Windows Installer shortcuts, but instead of directly linking to an application’s executable file, the association is made by a registered file type.

As you can see in Figure below, Windows Installer file associations are defined using the same mechanism that standard file associations use, with one exception. Notice that an extra value is listed under the typical “shell\Open\command” registry key. The extra value (also named “command”) is where Windows Installer looks any time you double-click on a file from within the Windows shell. This cryptic-looking string, sometimes referred to as a “Darwin Descriptor” is actually an encoded representation of a specific product, component, and feature. If this extra value exists, Windows Installer will decode the data, and use it to perform checks against that product and component. If the component is found to be missing or corrupt, Windows Installer will launch a repair to restore the missing file or data, and finally launch the referenced application as normal, passing the appropriate command-line options to it.

Cryptic-looking string - Darwin Descriptors

Viewing a “Darwin Descriptor” for a file association

Cryptic-looking string - Darwin Descriptors

Viewing a “Darwin Descriptor” for a COM Server

The Darwin Descriptor for COM Advertising is stored as the InProcServer32 registry value. The advertised shortcut’s TargetPath is a combination of the ProductCode & Darwin Descriptor + some tags. Open the shortcut using ex. notepad and find the descriptor. A Darwin Descriptor is an encoded string and when decoded produces a combination of the ProductCode, Feature & ComponentId(s).As the Darwin Descriptor is stored as a “REG_MULTI_SZ” entry it can contain more then one descriptor where other packages may have installed same component. We can find Darwin Descriptors under the following locations

HKCR\Installer\Assemblies and HKCR\Installer\Components

Cryptic-looking string - Darwin Descriptors


Cryptic-looking string - Darwin Descriptors


Cryptic-looking string - Darwin Descriptors

While Packaging, we can use snapshot with advertising (not registry as-is) as it gives some extra entrypoints (Darwin Descriptors) to trigger a potential repair if required. If there are some problems for the application to call any COM component/ActiveX functions then Advertsing setting “Retain Registry Information as-is” works better.

Thanks to AngelD, who shared this information!

Best Practices How-to Windows Installer, Application Compatibility and Deployments

How good is to use GetVersion function to detect the OS version number?

The internal version number for Windows Vista is 6.0 and Windows 7 is 6.1.  The GetVersion function returns this version number. The problem is, some applications will return a higher version number. 

Symptoms of OS Version 

  1. Applications that check for OS version will get higher version number.
  2. Application installers may prevent themselves from installing the app and apps may prevent themselves from starting.
  3. Applications may warn users and continue to function properly.

Mitigation Techniques for OS Version

  1. For apps and installers that check for OS version, a Compatibility mode is provided in Windows Vista
  2. Users can right right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from the Compatibility tab. This applies multiple shims including “WinXPSP2VersionLie”
  3. Better: Apply the shim “WinXPSP2VersionLie”
  4. In many cases, applications will work the same way that it did in Windows XP and there is no need for changes to the application

Fixes for OS Version

Applications should not perform version checks for equality (== 5.1)

  1. If you need a specific feature, check whether the feature is available.
  2. If you need Windows XP, check for Windows XP or later (>= 5.1).
  3. Exceptions to this occur when there is a very specific business, or legal need to do a version check, such as regulatory body requires you to certify your application for each operating system and version.
Best Practices Windows Installer, Application Compatibility and Deployments

Best Practices to follow while Packaging Applications

Hard-coding should be avoided

In an MSI, Hard coding should be avoided to the maximum and should be replaced by properties. For e.g. instead of “C:\Program Files\…”, property “ProgramFilesFolder should be used.

Least Use of custom actions involving 3rd party tools

Any changes which are being made to the system during an installation should possibly be made through an MSI involving least use of 3rd party tools. For e.g. If an UI Installation needs to created, it should be done through MSI Dialogues not through Visual Basic exe’s. If a file has to be installed conditionally, same should be done through MSI’s functionality not through VB Scripts.

Deletion and allocation of resources (files, registries) to proper components.

During Setup capture, Wise package Studio, captures lot of junk registries and usually you will find all these registries in a component by name “registryXX”.
This component needs to be carefully looked at since this component will have registries which otherwise should belong to other components. For e.g this component will have registries for e.g HKCR\CLSID\{GUIID} or HKCR\Interface\{GUIID}.If there is a dll in your application and registration of this dll has this GUID, then this registry should be moved from this component to the component having this dll else this registry is categorized as junk registry and needs to be removed.

 Ini Files should be retained as INIFile Table Entries not as Files, to the extent possible.

Ensure that any INI file changes are recorded in the INI file table, rather than just as files in the file table. This will ensure that INI files are edited if they exist already, rather than replaced with the version within the MSI Package.

Shortcuts should be made as “Advertised” shortcuts to the extent possible.

This is to ensure Self Healing.

DLL’s should be registered through Advertising Tables to the extent possible.

This is to ensure Self Healing and minimize registry conflicts.

As soon as you realize that the source installation is an MSI or installs an MSI embedded in it, it should be scripted as Vendor MSI.There should be no empty components in the MSI.

 Only COM Dll’s should be isolated.

If any custom actions are used, “In-Script” options and “Processing Options” need to be set correctly for them.

During Setup Capture

if it’s observed that lot of .INI Files have got captured, it’s better to exclude the INI files from the capture and then a second capture can be taken just with INI files or the INI files can be added as files, else the capture will take several hours and some times may not complete.

it’s possible that .INI Files, .INF Files, .HLP Files or .CHM Files do not get captured properly. To make sure all these files are present in MSI, it’s better to compare the size of the application folder in target machine (where application is installed) with captured folders after Setup Capture.

In some applications, it’s required to do the capture in some specific accounts and Wise can’t be installed in that account. In such cases it’s better to use the Wise as “run as” rather than going for some other capture techniques.  

Note: Run as account should be the account in which Wise is installed.


Lot of CHM files

 When there are lot of CHM files need to be added in the script which might have missed during capture, add it to the components directly rather than adding through Installation Expert. The reason for this is if you add through Installation expert, then the CHM files will be moved to the components, which is already having some CHM files, getting installed in some other folder.


Best Practices How-to Windows Installer, Application Compatibility and Deployments

Capture configuration Entries through Gap-Capture

This tip will shine some light on the concept of performing a “Gap Capture”. Let’s start with a simple equation: GAP CAPTURE = SOURCE APPLICATION – CAPTURED MSI.

Basically, a Gap Capture is the difference between a Source Application and Captured MSI.

When do we do this??

You have done the setup capture but your MSI fails in Functionality Testing. One reason could be that some files or registry is missing in your package. To capture the LEFT OUT entries, we need to do GAP capture.

How do I do this ??

1. Install Captured MSI of the Application on your system.
2. RUN Setup Capture and take the SnapShot.
3. Install Source Application over it.
4. Now finish the Capture (SnapShot of OS+MSI+Source Application)

What you’ve captured in the WSI is now a GAP Capture.

What Next??

First re-build the machine and install your earlier packaged MSI. If the Gapcaptured content is a registry entry or a file. just add this entry in the machine and launch the application shortcut. If it launches fine..its a Bingo!

Now, add this content to the MSI. Many a times, it can also be beause of an autoupdation of an ini file. In this case, install the source application and extract the ini files into your package and check for its functionality. I reckon, these steps will help !!!

Windows Installer, Application Compatibility and Deployments

How to avoid Self-Healing of an MSI Package?

The correct way to avoid self healing on a component is not but removing the keypath.

If you want self healing to be disabled you should be removing Component code. A blank key path confuses self healing. A blank component GUID stops self healing data being written to the registry, effectively disabling it.