Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

Humble fixer (MS "Owned" through a vendor) — Mon, 01 Aug 2011 08:23:30 GMT

This is the way I've solved my problem:

1. Press F8 on boot until the boot menu comes up. Choose the first option - Repair

2. Choose Command prompt in the repair menu. When the cmd window appears type the folowing:

cd d:\windows\system32\config

rename default default_old

rename sam sam_old

rename security security_old

rename software software_old

rename system system_old

cd regback

copy default d:\windows\system32\config

copy sam d:\windows\system32\config

copy security d:\windows\system32\config

copy software d:\windows\system32\config

copy system d:\windows\system32\config

exit

Click RESTART

3. Press F8 on boot until the boot menu comes up. Choose SAFE MODE

4. in safe mode click Run and type services.msc and then ENTER. Find windows update in the list, dubleclick it and modify the Startup type to DISABLED

5. Open My Computer, go to c:\windows and delete the SOFTWARE DISTRIBUTION folder

6. Restart computer

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

dickfrey — Tue, 10 May 2011 13:21:37 GMT

What does it means this last post ?

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

Joscon (doesn't work for Microsoft) — Wed, 04 May 2011 05:48:44 GMT

What a little liar...

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

Drewfus — Fri, 15 Apr 2011 14:35:58 GMT

@Andy Kinnard "Simply put, Microsoft should test ALL patches and service packs that will be pushes by WSUS in its default configuration using every available method of application INCLUDING the highly popular option to apply updates on shutdown."

To suggest that Microsoft doesn't do this is, at best, naive.

@Andy Kinnard "In addition, this SP should NEVER have been published without its being marked exclusive. For those two mistakes, there IS NO acceptible EXCUSE."

Great hindsight analysis. Now what do you suggest for these inexcusable mistakes? Public floggings?

@joscon "--We have a small increase in calls at Microsoft on the first day that this hits but those quickly trail off"

"All in all, I actually think that this is pretty good support for an issue that was mainly seen on the newsgroups and here. Had everyone who had seen this C34 error called in the day they got the error, it would most likely have generated an even faster response for the script workaround to alleviate these issues. I've said it before but I cant fix what I cant see. When you dont call me for help, I dont "see" the problems you're having. And when most of you dont call in, then the company as a whole cant see that.

@chucko "It is poor practice IMHO to look at call volume as the primary indicator of how serious a problem is."

A reasonable comment, followed soon after by ...

"You seem to be wanting to dismiss the problem because in your mind there are few PC's affected. We all know that the numbers of PC's in a "torn state" is far higher than you think it is."

chucko, is the second quote also your humble opinion? Who is 'we' a reference to? What are the true numbers? Why does joscon think they are less?

@Andy Kinnard "...MS's continued explanation that they didn't detect the magnitude of the C34 problem because, somehow, the USERS failed (by not calling MS)."

joscon above indicates that Microsoft uses helpdesk call stats as a proxy for the extent of a problem and as a determinant for resource allocation for problem resolution. Andy, what evidence do you have that suggests MSFT "didn't detect the magnitude of the C34 problem", and that this implies end users have failed? Failed what? What is the extent of the problem? How has MSFT now managed to detect the true extent of the problem? How is it that you seem to know more about what is going on that Microsoft Support?

"Then reformulate your responses to be less condescending and denigrating (in content, not tone) about what users were forced to do to get back to business."

Who or what in general is this a reference to? It is poor form to be making a statements as negative in content *and* tone as you have without being in any way specific as to what has got under your skin.

Maybe a few commenters on this blog should read, or re-read, the first post.

blogs.technet.com/.../introduction.aspx

to quote joscon: "...I am a Senior Support Escalation Engineer on the Windows CORE team. What that fancy title means in laymans terms is that I am one of the guys on the other end of the phone when you call into Microsoft support."

With respect to joscon - that is a position i envy - but remember people who your talking to here. This is not the head of the Windows division or the CEO your dumping your frustrations on. It's a guy who's doing his best to help, and educate, *in his own time*, even when problems like the subject of this post are obviously resulting in a lot of overtime. Please consider this when your commenting.

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

joscon [Microsoft] — Thu, 14 Apr 2011 20:50:16 GMT

@Ray; Yes our solution is tested and verified to work on in state machines. Our script will not result in a torn state and will allow the service pack to install properly.

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

Ray — Thu, 14 Apr 2011 19:57:05 GMT

Is the Microsoft KB script different from thiswoot's solution? Both seem to suggest modification of your pending.xml, and I've been avoiding that as advised by this blog.

Joscon's post on [13 Apr 2011 7:42 AM] seems to imply that the Microsoft KB script is a safe solution (aka Will not result in a torn state).

To be explicit, I'm referring to the following Microsoft KB article:

support.microsoft.com/default.aspx

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

Susan — Thu, 14 Apr 2011 18:16:52 GMT

Tvarde - ping me and I'll get a case set up susan-at-msmvps.com

Same with you dickfrey -- I'll help you and you can help us all.

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

TVarde — Thu, 14 Apr 2011 17:03:23 GMT

Just fyi, we have 22 systems in this "torn state" (out of around 125 that WSUS deployed updates to the evening of 3/17/11). The next morning, we scrambled to get the 22 user's up and running asap -- they, and their boses were not happy.

We would also like to see a supported fix to this situation vs. re-imaging the affected systems.

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

dickfrey — Thu, 14 Apr 2011 12:31:42 GMT

You can see my comments upper.

I have again 14 PCs to try, but not before 3 weeks...

re: Why you don’t want to edit your pending.xml to resolve 0xC0000034 issues

joscon [Microsoft] — Thu, 14 Apr 2011 12:25:36 GMT

@Kristian;

Because I dont have a machine thats broken in the same way that the groups appears to be, I cant validate this as a solution. If more of you tell me that it is working for you, then we can look into it as a possible solution.