Blog Archives

the savedstate dictionary does not contain the expected values and might have been corrupted

This is a common error with custom action development, especially if you are working with your own custom installer class, not using wix or some other windows installer derivative.

Since many of the Google entries for this were unresolved, thought I would give it a quick tackle. 😉

First Solution

Throw an exception.

This solution seems to be the most popular among Google results.. You can throw a new Exception or InstallException, but this creates an unsightly error message which you would not want your users to see.

 public override void Install(System.Collections.IDictionary stateSaver)
            Process proc = new Process();
            string path = Path.GetDirectoryName(System.Reflection.Assembly.GetAssembly(typeof(InstallHelper)).Location);
            proc.StartInfo.FileName = path + "\\somesubprocess.exe";
//note ProductCode argument is an installer variable
            proc.StartInfo.Arguments = "\"" + this.Context.Parameters["action"] + "\" \"" + this.Context.Parameters["ProductCode"] + "\" \"" + this.Context.Parameters["src"];


//optional showwindow code to force window into foreground
 IntPtr msiwindowhandle;
            msiwindowhandle = FindWindow("#32770", InstallTitle);
            ShowWindow(msiwindowhandle, 0);

if (proc.ExitCode == 1)
throw new InstallException("Installation cancelled. Any changes made will now rollback.");
                if (stateSaver == null)
                    stateSaver = new Dictionary<string, string>();
                    //Add some default values to the dictionary here...if you dare..

                base.Rollback(stateSaver); //will give you article title error

The code above was a bit much to simply explain the concept of throwing a new “InstallException”, but does illustrate there are definitely things you can do from your custom action bootstrap DLL which have room for error (like spawning a sub process!).

The Alternative

…is to simply click/call the cancel button for the base installer from your custom action code.

Since the msi installer process is separate from your bootstrap custom action DLL, you will have to use some old school tricks to work around the constraints.

Simply import User32.dll and call the “SendMessage” function, passing in the handle of cancel button. See code example below:

using System.Runtime.InteropServices;

[DllImport("User32.dll", EntryPoint = "SendMessage")]
        public static extern int SendMessage(IntPtr hWnd, int Msg, IntPtr wParam, IntPtr lParam);

        [DllImport("user32.dll", SetLastError = true)]
        private static extern IntPtr FindWindowEx(IntPtr parentHandle, IntPtr childAfter, string className, string windowTitle);

        [DllImport("user32.dll", SetLastError = true)]
        public static extern IntPtr SetActiveWindow(IntPtr hWnd);

        [DllImport("user32.dll", SetLastError = true)]
        static extern IntPtr FindWindow(string lpClassName, string lpWindowName);

        static extern bool ShowWindow(IntPtr hWnd, ShowWindowCommands nCmdShow);

        enum ShowWindowCommands : int

            Hide = 0,
            Normal = 1,
            ShowMinimized = 2,
            Maximize = 3,   
            ShowMaximized = 3,
            ShowNoActivate = 4,
            Show = 5,
            Minimize = 6,
            ShowMinNoActive = 7,
            ShowNA = 8,
            Restore = 9,
            ShowDefault = 10,
            ForceMinimize = 11

public static string InstallTitle = "AppbarTitle"; //used to get the window handle

  public override void Install(System.Collections.IDictionary stateSaver)
ShowWindow(msiwindowhandle, ShowWindowCommands.Show);
                IntPtr cancelbuttonhandle;
                const int BM_CLICK = 0x00F5;
                msiwindowhandle = FindWindow("#32770", InstallTitle);
                cancelbuttonhandle = FindWindowEx(msiwindowhandle, IntPtr.Zero, "Button", "Cancel");
                SetActiveWindow(msiwindowhandle); //necessary for button click to fire
                SendMessage(cancelbuttonhandle, BM_CLICK, IntPtr.Zero, IntPtr.Zero);

The MSDN Social article listed in my references below comes up in Google rankings high for the error the OP received when calling the Rollback method manually. To track any social momentum my solution may possibly gain, refer to this link.

MSDN Social,
MSDN, “Installer.Rollback Method”,
MSDN, “Installer.BeforeRollback Method”,

Remove Repair Option from Custom Windows Installer

This technically can be done in various ways relating to InstallShield, Wise, WiX, NSIS or other installer platforms, but generally speaking is the same concept all throughout whether you are using third party tools or creating your own bootstrap/windows installer project/custom action.

An MSI file contains tables of data. Within these tables, there is one labeled “property” which contains a series of string/value items. The properties which control visibility of repair/modify in button are referred to as:


In order to modify the MSI tables and change these properties you must first be able to modify the MSI file. This can be done one of two ways:

Option 1:
Download and install the Windows SDK Components for Windows Installer Developers.

Once downloaded and installed, navigate to “\Program Files\Microsoft SDKs\Windows\v7.0\Bin” and run “Orca.msi” to begin the install for orca.

Once installed, run orca and open the propery table and add an entry for ARPNOREPAIR and set its value to 1.

Option 2:

As an alternative, unless you have some other reason for DLing the SDK, you can totally bypass the 2.5GB DL just for a little orca file by using an awesome proprietary tool called SuperOrca :).

SuperOrca IMO is much improved over the basic MS orca, but the end result is the same. Open the MSI, navigate to PROPERTY table, and add the entry with a value of 1, save, test.

For C++ or custom action programmers, you can call MsiSetProperty and pass in ARNOREPAIR for the name and 1 for the value for the same end result.

MsiSetProperty and MsiGetProperty cannot be called from your typical C# installer class/bootstrap DLL, since the handle to the installer is never passed in.

For a little background history, in my particular case, a custom action in the installer is targeting a DLL I created (separate project in the same solution). This DLL inherits the installer class and overrides the install and uninstall methods.

MSDN (Windows Installer SDK),,
SuperOrca (Pantaray),
MSDN (msisetproperty),
MSDN Blogs (msisetproperty,getproperty),
MSDN (create a custom action),