Don't do it!
Why you don't want to edit your pending.xml to resolve 0xC0000034 issues - The Windows Servicing Guy - Site Home - TechNet Blogs: http://blogs.technet.com/b/joscon/archive/2011/03/11/why-you-don-t-want-to-edit-your-pending-xml-to-resolve-0xc0000034-issues.aspx I know that one of the workarounds everyone is using is editing the pending.xml file and rebooting the machine. This is seemingly working for everyone that the SetupExecute registry value does not. I wanted to give a brief rundown as to why you only want to do this as a last resort. During service pack installation, we populate the pending.xml file with all of the files and registry values needed to install a particular update. Service packs are special in that they are broken into critical and non-critical transactions to allow us to recover more quickly and reduce the no-boot window that could occur during installation. During system shutdown, we process all of the critical transactions first and then the non-critical transactions. If we fail processing the critical transactions, the service pack will just fail and rollback. If the critical operations succeed but the non-critical operations fail, we attempt to process them on reboot using Session Manager (smss) and the SetupExecute registry value. When the system reboots and reads the SetupExecute key, it retries installation first and if that fails it will roll back the Service Pack installation. Deleting the registry value tells smss to not try and run the poqexec. It should be reattempted again during startup processing or fail outright. So effectively deleting the registry value breaks you out of the install fail reboot loop that the machine ends up being in. Additionally, the pending.xml file has a checkpoint value that tells Windows where the critical transactions end and the non-critical transactions begin. When you delete the checkpoint value in the pending.xml, its effectively marking everything in the pending operation queue as critical. Because your machine has already rebooted, Windows thinks it has nothing to do and just boots normally. The problem with this is that because there are still operations that need to be processed that will not get processed and this could potentially leave the machine in an even worse state. Doing this should be an absolute last resort. The best thing to do here is let the failure occur later on so a rollback can take place. --Joseph Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com From: Jim Dandy [mailto:[email protected]] Sent: Friday, March 11, 2011 12:41 PM To: NT System Admin Issues Subject: Windows 7 64-bit SP1 fails I installed SP1 on a bunch of test systems with no problem. So, I decided to risk pushing it with WSUS to subset of computers out in the department (don't have SCCM implemented yet). It seems that a large percentage (perhaps 90%?) of those failed. I have no idea what the difference is between the ones that worked and the ones that didn't. I've run into a few others that have had similar difficulties. We've been able to get the systems back up with this http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/1c9a7151-b48c-4a98-aae7-a4b82682ea8e#bcabda57-7338-499f-aee2-d708e76df315 I'm not sure what the implications of this fix are but it gets them back up and running. Curt Finley ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
