Windows 7 SP1 Installation Error

Windows 7 SP1 Installation Error

  • Comments 2
  • Likes

I got a call yesterday from a partner experiencing some issues with Windows 7 SP1 installation. All of the systems were running Windows 7 OEM builds from different manufactures and he had a few customers that had encountered an error on installation. Doing a little searching around the internet I found this from the Windows Servicing Blog and thought it would be good for people that are encountering this issue:

!! 0xc0000034 !! 142/53007 (_0000000000000000.cdf-ms)

Note If you restart the computer, you experience the same error message.

If you're hitting one of these errors, you have a few options depending on the OS you're using.

Option 1 (Win7 client only): Use a system restore point to recover the system

  • This one is pretty self explanatory. Boot your machine into WinRE and pick a restore point before the service pack was installed. This should get you back up and running.
  • This doesnt work on server

Option 2 (Win7 client and 2008 R2 server): Delete the poqexec entry

  • Boot into WinRE and choose a command prompt then run the following commands and restart the computer:
    • Reg load HKLM\BaseSystem C:\Windows\System32\config\SYSTEM
    • Reg Delete "HKLM\BaseSystem\CurrentControlSet\Control\Session Manager" /v SetupExecute
    • Reg add "HKLM\BaseSystem\CurrentControlSet\Control\Session Manager" /v SetupExecute /t REG_MULTI_SZ
    • Reg unload HKLM\BaseSystem
  • If you're more graphically inclined, you can use this method:
    • Boot into WinRE
    • Open Registry Editor using regedit.exe
    • Now you will have the WinRE registry loaded so you need to load the “ System ” hive
    • To do that : Highlight HKLM then Click on File > Load Hive > Browse to C:\windows\system32\config (assuming C:\ being the system drive )
    • Name the Hive as TEST
    • Browse to HKLM\TEST\select and check the value for “ Current “
    • Assuming the value as (1) browse to HKLM\TEST\ControlSet001\Control\SessionManager
    • Locate and double click the key “SetupExecute ” at the right panel
    • Delete any value inside the key and click OK
    • Highlight TEST and then Click on File > Unload hive
    • Type exit at cmd
    • Reboot the machine

NOTE: I've seen several people that have called in and said that they cant find the values referenced in this blog once they have booted into WinRE. Please remember that when you are booted into WinRE you are booted into a RAMDRIVE. This means that when you open the registry editor you are actually seeing the hives from WinRE and NOT the ones from Windows. When you need to make sure you are loading the system hive from your Windows drive and not WinRE.

If this does not get your installation up and running there is another available workaround posted in the forums here:

It is not recommended that you edit the pending.xml but this may get your machine booted properly. If you are desperate, feel free to try this at your own risk. I wrote about why you want to be careful with this here:

If you're planning on opening an issue with SP1 for this, please try and gather the following information before you call, it will greatly help us in working on the issue:

• Registry hives. COMPONENT, and SYSTEM
• CBS log directory
• Sessions.xml
• Poqexec.log
• Pending.xml
• “Dir /s /b” Directory listing of c:\windows\winsxs

Additionally, I would like anyone who has a machine "in state" and can get logs off from WinRE to grab their \Windows\winsxs\FileMaps\$$.cdf-ms file.

Hope this helps.

avatar-body2  Will_Signiture2_2

  • Been there done that. After 4 hours down waiting on MS to come up with a fix you have to bail and do what you can to get the customer up, in this case edit the pending.xml. Now will MS re-release SP1 to WSUS to fix what is breaking/

  • This problem is not limited to OEM builds.

    I had this problem with 18 PCs that has a clean install of Windows 7 Enterprise x64.

    The PCs were all Dell Optiplex's  additional machine were only not affected because the update wasn't installed.

    Affected staff lost about 4 hours, so over 9 man days lost :-(

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment