Troubleshoot MSI Installation Issues and Functional Errors

If the application does not work after the install, there could be several possible reasons for this. I’ve tried to outline a few of the troubleshooting steps I take when I run into these types of errors. Read on to learn more. 

The application does not work in user context ie., locked-down environment. 
  • To test this, install the package and run the application under a local administrator account for the workstation.
  • If the application works under this account but not under a normal user account, then the following problems might be present.
  • Unable to write to drives/folders such as R:, C:\Program Files, C:\Windows, etc. which are read-only for normal users. If this is suspected then make the drives read/write for the user to test this. Check whether R:\ and other shared directories are mapped properly before installation.
  • Unable to write to registry keys. With the exception of HKCU and HKLM\SOFTWARE, all other hives are read-only for normal users. If this is suspected then make the hive read/write for the user to test this (use REGEDT32.EXE in W2000 and regedit in XP and Vista).
    In either case if such problems are encountered then the resolution of the problem should be to give the read/write access required for folders on the workstation or hives in the registry.

The application does not work because of missing component!

  • To test this, run the source or native install on a clean machine, and run the application.
    Note that this test can also be done, after the initial application capture. If it does not work, then it is reasonable to assume that the application install is missing some components for it to work or the application will never work on this environment.
  • If it seems as if a component is missing then it can be added.

Not everything has been captured.

  • To test this, install the source, compile the captured .wsi or .wse file and execute the resulting .msi or .exe on the machine, and run the application. If it works then this indicates that all was captured but perhaps too much was removed whilst creating the package or wrong versions of components were used from the originals.
  • In either case a reasonable next step is to perform a “gap capture” on the workstation on which the package has been installed and tested.
    To do this, run WfWI or WI on this workstation and perform a capture of the original native install on top of the Packages install. This will give a “gap capture” indicating the differences, or what has been left out.
    Look at the files and registry entries in the resulting .wsi or .wse.

This post outlined some actions to be taken in the event of a completed package not working when installed. Further it also provided some details of the most common problems and actions.

Leave a comment

Your email address will not be published.