Compartir a través de


SQL Server Patch installation fails with error 1603

Ran into this interesting issue recently. I was trying to install a patch on SQL, and it failed. I searched in the hotfix.log (since this was a SQL 2005 instance), and found these messages:-

02/03/2012 03:01:03.649 Installing file: sqlrun_sql.msp
02/03/2012 03:01:03.696 Copy Engine: Creating MSP install log file at: C:Program Files (x86)Microsoft SQL Server90Setup BootstrapLOGHotfixSQL9_Hotfix_KB2494113_sqlrun_sql.msp.log
02/03/2012 03:01:03.696 Registry: Opened registry key "SoftwarePoliciesMicrosoftWindowsInstaller"
02/03/2012 03:01:03.696 Registry: Cannot read registry key value "Debug", error 0
02/03/2012 03:01:04.226 MSP returned 1603: A fatal error occurred during installation.

From here, you can determine which component failed (in this case it was sqlrun_sql).

In case of SQL 2008 and R2, the summary.txt will point you to the relevant component's log file:-
Log with failure: C:Program FilesMicrosoft SQL Server100Setup BootstrapLog20111228_093034SQL8sql_fulltext_Cpu64_1.log
Upon opening the log of the particular component, you will see something like this:-
MSI (s) (F0:84) [09:38:53:925]: Opening existing patch 'C:WindowsInstaller278e8021.msp'.
MSI (s) (F0:84) [09:38:53:925]: SequencePatches starts. Product code: {F233AB42-A61A-4FAB-82A5-A0EBEE94176E}, Product version: 10.50.1600.1, Upgrade code: {5A5E4CCE-8348-4EF8-8FA1-2B5524329CF5}, Product language 1033
MSI (s) (F0:84) [09:38:53:926]: PATCH SEQUENCER: verifying the applicability of minor upgrade patch p:c5316177906c8cf6c8a3248b50ccx64setupsql_fulltext.msp against product code: {F233AB42-A61A-4FAB-82A5-A0EBEE94176E}, product version: 10.50.1600.1, product language 1033 and upgrade code: {5A5E4CCE-8348-4EF8-8FA1-2B5524329CF5}
MSI (s) (F0:84) [09:38:53:926]: Note: 1: 2262 2: _Tables 3: -2147287038
MSI (s) (F0:84) [09:38:53:926]: Note: 1: 2262 2: _Columns 3: -2147287038
MSI (s) (F0:84) [09:38:53:926]: PATCH SEQUENCER: minor upgrade patch p:c5316177906c8cf6c8a3248b50ccx64setupsql_fulltext.msp is applicable.
MSI (s) (F0:84) [09:38:53:926]: SequencePatches returns success.
MSI (s) (F0:84) [09:38:53:926]: Final Patch Application Order:
MSI (s) (F0:84) [09:38:53:926]: {2E7EB973-48D5-43CA-9360-CA011FAE81EE} - p:c5316177906c8cf6c8a3248b50ccx64setupsql_fulltext.msp
MSI (s) (F0:84) [09:38:53:926]: Other Patches:
MSI (s) (F0:84) [09:38:53:926]: Internal Exception during install operation: 0xc0000005 at 0x000007FEFDE93821.
MSI (s) (F0:84) [09:38:53:926]: WER report disabled for silent install.
MSI (s) (F0:84) [09:38:53:926]: WER report disabled for non-console install.
MSI (s) (F0:84) [09:38:53:926]: Internal MSI error. Installer terminated prematurely.

I noticed that as soon as it determines the final patch application order and decides to proceed with the install, it hits an AV and the windows installer terminates.

Though it may seem otherwise, this is not a problem with the windows installer itself, but a problem with the msp file in question. The file is corrupted in some way, and therefore caused the installer to fail.

I was also able to reproduce the issue on my machine as well. How? Simple, run the FindSQLInstallsOnly script (available here), pick the msp for a component, go to installer cache and corrupt it (something as simple as opening it in a notepad, modifying it and saving the changes), and then run a patch which includes a fix for the component in question. You should see a stack similar to the one above in the Setup logs.

So what’s the resolution? You guessed it. There are multiple ways to get around this issue. You can:-

1. Go to the installer cache (C:windowsInstaller) and delete/rename the offending file, and then recreate a "good" copy of the same (recommended). The steps for this can be found in the KB:-

https://support.microsoft.com/kb/969052

2. Go to the registry and remove all references to the installer cache file, as well as its last used source path (simply search for the installer cache file name, which you can get from the output of the FindSQLInstallsOnly script). This will allow the file to be created afresh when the patch runs for the next time.

Hope this helps someone. Any questions/feedback, please feel free to use the comments section. Thanks.

Comments

  • Anonymous
    September 20, 2012
    Very helpful post