none
SQL 2005 SP1 installation hangs

    Question

  • I am trying to install SQL 2005 SP1 on a Windows 2000 Server SP4 platform. I have repeatedly tried this, and have trashed and re-built the platform all to no avail. I keep getting the same problem. The installation hangs, using 0 CPU apparently after successfully extracting the files to disk. It leaves the HOTFIX.EXE running, and cancelling it ends the process. The HOTFIX.LOG looks like this:

    5/31/2006 10:05:03.185 ================================================================================

    05/31/2006 10:05:03.185 Hotfix package launched

    05/31/2006 10:05:03.195 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion

    05/31/2006 10:05:03.195 Successfully read registry key: CommonFilesDir, string value = G:\Program Files\Common Files

    05/31/2006 10:05:03.195 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion

    05/31/2006 10:05:03.205 Successfully read registry key: ProgramFilesDir, string value = G:\Program Files

     

    I have been searching various forums for an answer and have found one hit here (but no answer):

    http://www.eggheadcafe.com/aspnet_answers/SQLServersetup/May2006/post26789173.asp

    After reading this I cancelled the CMD.EXE instead of the HOTFIX.EXE and duly got a "Product Enumeration" popup window. The HOTFIX.LOG now looks like this:

    05/31/2006 12:27:18.057 ================================================================================

    05/31/2006 12:27:18.057 Hotfix package launched

    05/31/2006 12:27:18.057 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion

    05/31/2006 12:27:18.057 Successfully read registry key: CommonFilesDir, string value = G:\Program Files\Common Files

    05/31/2006 12:27:18.067 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion

    05/31/2006 12:27:18.067 Successfully read registry key: ProgramFilesDir, string value = G:\Program Files

    05/31/2006 16:09:34.452 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion

    05/31/2006 16:09:34.462 Successfully read registry key: CommonFilesDir, string value = G:\Program Files\Common Files

    05/31/2006 16:09:34.462 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion

    05/31/2006 16:09:34.462 Successfully read registry key: ProgramFilesDir, string value = G:\Program Files

    05/31/2006 16:09:34.462 Local Computer:

    05/31/2006 16:09:34.462 Target Details: PET005-5

    05/31/2006 16:09:34.462 commonfilesdir = G:\Program Files\Common Files

    05/31/2006 16:09:34.462 lcidsupportdir = G:\sql2005sp1_ext\1033

    05/31/2006 16:09:34.472 programfilesdir = G:\Program Files

    05/31/2006 16:09:34.472 supportdir = G:\sql2005sp1_ext

    05/31/2006 16:09:34.472 supportdirlocal = G:\sql2005sp1_ext

    05/31/2006 16:09:34.472 windir = G:\WINNT

    05/31/2006 16:09:34.472 winsysdir = G:\WINNT\system32

    05/31/2006 16:09:34.472

    05/31/2006 16:09:34.512 Enumerating applicable products for this patch

    05/31/2006 16:09:34.532 Found Redist 2005 product definition

    And there is also now a REDIST9_HOTFIX_KB913090.LOG file which looks like this:

    05/31/2006 16:09:34.582 ================================================================================

    05/31/2006 16:09:34.582 Hotfix package launched

    Yes I am logged on as an Administrator. Yes the SQL 2005 is off the latest MSDN CDs.

    How do I resolve this issue and install SP1?

     

    Wednesday, May 31, 2006 4:16 PM

All replies

  • Check the version number of SQLservr.exe, if it is below 9.00.1399, it is not supported by SP1.
    Monday, June 05, 2006 7:49 PM
  • According to properties the version is 2005.90.0.1399.0. I have also now tried it on a Windows Server 2003 SP 1 with identical results. Same version of SQLservr.exe as well.

    I have tried using FilMon and RegMon and have noticed that cmd.exe is accessing the C drive via a network share. My machines are multi-partition machines and the C drive is the dos boot partition and not part on the Windows environment at all. I hope this is a complete red herring other wise this is not going to work.

    Tuesday, June 06, 2006 8:24 AM
  • I've got the same problem: here's my log file

    06/13/2006 18:19:50.343 ================================================================================
    06/13/2006 18:19:50.359 Hotfix package launched
    06/13/2006 18:19:50.375 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion
    06/13/2006 18:19:50.375 Successfully read registry key: CommonFilesDir, string value = C:\Program Files\Common Files
    06/13/2006 18:19:50.437 Successfully opened registry key: SOFTWARE\Microsoft\Windows\CurrentVersion
    06/13/2006 18:19:50.453 Successfully read registry key: ProgramFilesDir, string value = C:\Program Files

    I've checked, and I do have the 9.0.1399.0 version. Has anything more been discovered about this problem?
    Wednesday, June 14, 2006 1:41 AM
  • Niall Gordon & Erstam please email me directly at petersad@microsoft.com.  We have had a few reports of a "hanging" but have been unable to repro the problem in-house and the log files are not providing much information. We would like to work with you directly to conduct some advanced debugging. 

     

    Thanks,

    Peter


    Wednesday, June 14, 2006 2:43 AM
  • Here is the fix to the problem on my machines at least:

    Hotfix.exe spawns a cmd.exe with command line switch "/C dir \\<servername>\c$" to get a directory listing. I had the environmental variable DIRCMD set to "/odg/p" which causes the dir command to pause after each page of directory listings. So, the sp1 installer was waiting forever at the dir's prompt "Press any key to continue". Taking the /p off the environmental variable fixed this problem.

    Tuesday, June 20, 2006 10:22 PM
  • Yes, we have confirmed the SP1 installer will hang if the DIRCMD environmental variable had a "/p".  We will be addressing this issue in service pack 2.

    Thanks to all that assisted us with a repro.

    Peter Saddow

    Wednesday, June 21, 2006 2:34 AM
  • So is there any way around this?
    Tuesday, May 29, 2007 2:54 PM
  • Sure, take the /p out of the DIRCMD environmental variable. If that doesn't work then you are having a different problem than I described.

     

    Ed

    Tuesday, May 29, 2007 3:27 PM