update.exe problem

A customer brought an XP Home system in to our shop, complaining of excessive
cpu utilization. After removing a small amount of adware and a trojan.spybot
variant, and doing a full system scan with Norton AV, I rebooted the system
and connected to our broadband internet, since that was the trigger,
according to the customer. The system got very sluggish. ProcessExplorer
showed that update.exe running under SP1 installer, in conjunction with
"system" was taking up 100% of the cpu. Disconnecting from the internet at
this point made no difference.

After renaming update.exe in the SP1 download directory and rebooting, all
was normal, even when connected to the internet. Thinking that it needed to
be updated to at least SP1, which I have on a CD, I started that install and
got into the same loop. SP1 installer got hung at "inspecting system" with
update.exe + system = 100% utilization. This time, update.exe was in the
directory that was created when SP1 was extracted, and I presume that this is
a fresh copy of the file, created during the extraction process.

If I abort the SP1 install, update.exe continues to run. If I try to kill
the update.exe process, it acts as though nothing was done - the same
process remains after the refresh with the same PID.

At this point, there appears to be some kind of system setting or file
damage. I know all malware has been removed, so I am thinking of doing the
XP repair reinstall, unless someone has a more specific fix. The system is a
P4 w/256mb ram, swap file set to 384/512.

1) Download the following three items...

McAfee Stinger
http://vil.nai.com/vil/stinger/

Trend Sysclean Package
http://www.trendmicro.com/download/dcs.asp

Latest Trend signature files.
http://www.trendmicro.com/download/pattern.asp

Create a directory.
On drive "C:\"
(e.g., "c:\New Folder")
or the desktop
(e.g., "C:\Documents and Settings\lipman\Desktop\New Folder")

Download SYSCLEAN.COM and place it in that directory.
Download the Trend Pattern File by obtaining the ZIP file.
For example; lpt359.zip

Extract the contents of the ZIP file and place the contents in the same directory as
SYSCLEAN.COM.

2) Disable System Restore
http://vil.nai.com/vil/SystemHelpDoc...SysRestore.htm
3) Reboot your PC into Safe Mode and shutdown as many applications as possible
4) Using both the Trend Sysclean utility and Stinger, perform a Full Scan of your
platform and clean/delete any infectors found
5) Restart your PC and perform a "final" Full Scan of your platform using both.
6) Re-enable System Restore and re-apply any System Restore preferences,
(e.g. HD space to use suggested 400 ~ 600MB),
7) Reboot your PC.
8) Create a new Restore point


* * * Please report back your results * * *

--
Dave
http://www.claymania.com/removal-trojan-adware.html




"wyocowboy" <> wrote in message
newsF74A637-EA34-4FBA-89A9-...
| A customer brought an XP Home system in to our shop, complaining of excessive
| cpu utilization. After removing a small amount of adware and a trojan.spybot
| variant, and doing a full system scan with Norton AV, I rebooted the system
| and connected to our broadband internet, since that was the trigger,
| according to the customer. The system got very sluggish. ProcessExplorer
| showed that update.exe running under SP1 installer, in conjunction with
| "system" was taking up 100% of the cpu. Disconnecting from the internet at
| this point made no difference.
|
| After renaming update.exe in the SP1 download directory and rebooting, all
| was normal, even when connected to the internet. Thinking that it needed to
| be updated to at least SP1, which I have on a CD, I started that install and
| got into the same loop. SP1 installer got hung at "inspecting system" with
| update.exe + system = 100% utilization. This time, update.exe was in the
| directory that was created when SP1 was extracted, and I presume that this is
| a fresh copy of the file, created during the extraction process.
|
| If I abort the SP1 install, update.exe continues to run. If I try to kill
| the update.exe process, it acts as though nothing was done - the same
| process remains after the refresh with the same PID.
|
| At this point, there appears to be some kind of system setting or file
| damage. I know all malware has been removed, so I am thinking of doing the
| XP repair reinstall, unless someone has a more specific fix. The system is a
| P4 w/256mb ram, swap file set to 384/512.

"David H. Lipman" wrote:

>
>
>
> * * * Please report back your results * * *


No viruses found, so it looks like Norton was doing its job.

Anyways, I see other folks are reporting similar problems with high cpu
usage involving update.exe - is Microsoft aware of the problem? Anybody know
how to fix this?

I tried a repair reinstall - no help. I would rather find a fix than do a
complete reinstall.

Since no further advice seems to be forthcoming, here is some more info...

As I mentioned, the only way I could get out of the loop where update.exe +
system is eating 100% of the cpu was to rename update.exe and reboot. This
makes the system run normally, until I try to run windows update from IE, or
install sp1 from a cd. Until I try one or the other, the system seems to
work ok with other programs.

When I launch IE, it takes a long, long time to get to the page to scan for
updates. I have not actually gone through the update process, to avoid
getting back into the 100% cpu problem. This machine is on a DSL connection
here in the shop and another xp machine on the same hub gets the windows
update pages up very quickly, even though it is a slower machine. Normal
browsing of the internet seems to be a little slow on the problem machine as
well.

Thinking that maybe this is something that would be cleared up by installing
sp1, I tried that and it gets stuck at the "examing your system" phase, again
with update.exe + system =100% of cpu. The machine is currently in that
state, and has been on that screen for about 2 hours now, with cpu usage @
100%, so just letting it take its time does not work.

Thinking that maybe the problem was with leftovers from previous update
attemps, I tried renaming the folders under \windows\software distribution,
but this made no difference.

The other odd thing I've noticed is that auto update was continuing to run
even after disabling it in my computer - properties -autoupdate. The only way
I could get it to quit was to disable the autoupdate service, but since IE
windows update won't run without the autoupdate service running (!?!?!?) I
had to re-enable it.

Anyone know how to fix this, or have ideas? I'm running out of time and
options - I'm pretty sure that doing a full reinstall will fix it, but it
would be better for the customer if I didn't have to resort to the brute
force method.

"wyocowboy" wrote:

>
>
> "David H. Lipman" wrote:
>
> >
> >
> >
> > * * * Please report back your results * * *
>
>
> No viruses found, so it looks like Norton was doing its job.
>
> Anyways, I see other folks are reporting similar problems with high cpu
> usage involving update.exe - is Microsoft aware of the problem? Anybody know
> how to fix this?
>
> I tried a repair reinstall - no help. I would rather find a fix than do a
> complete reinstall.
>
>
>

> At this point, there appears to be some kind of system setting or file
> damage.

Agreed. Try using Catroot2 as a search term for possible fixes.

Or if you want to try to diagnose what's happening look for *.log
files which are being changed during the update.


Good luck

Robert Aldwinckle
---


"wyocowboy" <> wrote in message
newsF74A637-EA34-4FBA-89A9-...
>A customer brought an XP Home system in to our shop, complaining of excessive
> cpu utilization. After removing a small amount of adware and a trojan.spybot
> variant, and doing a full system scan with Norton AV, I rebooted the system
> and connected to our broadband internet, since that was the trigger,
> according to the customer. The system got very sluggish. ProcessExplorer
> showed that update.exe running under SP1 installer, in conjunction with
> "system" was taking up 100% of the cpu. Disconnecting from the internet at
> this point made no difference.
>
> After renaming update.exe in the SP1 download directory and rebooting, all
> was normal, even when connected to the internet. Thinking that it needed to
> be updated to at least SP1, which I have on a CD, I started that install and
> got into the same loop. SP1 installer got hung at "inspecting system" with
> update.exe + system = 100% utilization. This time, update.exe was in the
> directory that was created when SP1 was extracted, and I presume that this is
> a fresh copy of the file, created during the extraction process.
>
> If I abort the SP1 install, update.exe continues to run. If I try to kill
> the update.exe process, it acts as though nothing was done - the same
> process remains after the refresh with the same PID.
>
> At this point, there appears to be some kind of system setting or file
> damage. I know all malware has been removed, so I am thinking of doing the
> XP repair reinstall, unless someone has a more specific fix. The system is a
> P4 w/256mb ram, swap file set to 384/512.

Even though I had already renamed the catroot2 directory and tried it again
(same results), I searched on both google and this forum for catroot2. There
weren't a lot of hits, and none of them seemed to address the problem.

svcpack.log only shows that the sp1 install process has started, and nothing
more. I looked for other logs and browsed the plain text ones, but did not
find anything that looked like it was involved.

I don't have the time to learn how to run the xp debugger, and since they
stopped including the symbols in the update package, you have to hunt that
down as well.

According to the info at ...
http://www.microsoft.com/technet/pro.../winupdte.mspx

.... there isn't a command line switch for piping any kind of status info
that might lend a clue as to WTH is going on. There is a mechanism you can
use in Dr Watson that will send such info to MS, but since no MVPs are
chiming in on this or very many of the other update problem posts , I
wouldn't expect any help from MS on this one.

I did notice yesterday that 2 hardware interrupts (triggering 2 DPCs) are
occurring every 5-10 seconds or so, as indicated by ProcessExplorer. I ran
h/w diags overnight, and it found a ram failure that went away with reseating
the DDR stick (oxidized connection). I think the mem issue is a red herring,
as it now passes the MS mem test but update still gets stuck at the same
point.

Not sure about the h/w interrupts. They are occurring before I start the sp1
install, and I don't have any diags at the ready that will tell me what is
generating them. The only card I could pull was the modem and no change.

Note that the system is not hanging, only the update process. I can still
navigate, run search, etc - it just runs slower because sysetm+update.exe are
taking up 100% (indicated) of the cpu time.

I wish Microsoft had an answer for this, or better yet, abandon the use of
InactiveX for installing updates. I am going to contact the customer and
discuss a full reinstall of xp, with the hopes that this isn't a h/w problem.
What a PITA.

"Robert Aldwinckle" wrote:

> > At this point, there appears to be some kind of system setting or file
> > damage.
>
> Agreed. Try using Catroot2 as a search term for possible fixes.
>
> Or if you want to try to diagnose what's happening look for *.log
> files which are being changed during the update.
>
>
> Good luck
>
> Robert Aldwinckle
> ---
>

I thought I posted an update, but it didn't show up, so here is an update. A
parallel install of xp (into /windows.new) works, so it's not the hardware.
The customer has elected for a reinstall of xp, so the mystery remains....

"wyocowboy" <> wrote in message
news:2ACD7DD1-3FE3-49E7-B973-
....
> "Robert Aldwinckle" wrote:
>> Try using Catroot2 as a search term for possible fixes.


> Even though I had already renamed the catroot2 directory and tried it again
> (same results), I searched on both google and this forum for catroot2. There
> weren't a lot of hits, and none of them seemed to address the problem.

I guess I could have specified that I was thinking of MSKB articles
which mention that in their resolutions. Many of them also provide
other troubleshooting ideas and repair suggestions.
I thought that might be an easy way to get you to look at them
without being specific about something I'm not certain of.


>
> svcpack.log only shows that the sp1 install process has started, and nothing
> more. I looked for other logs and browsed the plain text ones, but did not
> find anything that looked like it was involved.

Would FileMon show the loop perhaps?


>
> I don't have the time to learn how to run the xp debugger, and since they
> stopped including the symbols in the update package, you have to hunt that
> down as well.
>
> According to the info at ...
> http://www.microsoft.com/technet/pro.../winupdte.mspx

BTW thanks for that link.

....
> I wish Microsoft had an answer for this, or better yet, abandon the use of
> InactiveX for installing updates.

One of the cases which is failing for you is on the CD.
Is that using ActiveX? (It bypasses WU in any case.)


> I am going to contact the customer and
> discuss a full reinstall of xp, with the hopes that this isn't a h/w problem.
> What a PITA.

Too bad. My only other idea was to try using RegMon and FileMon
to see if there were any additional clues about your loop.

Also I think that there actually is a regedit floating around which can be
used to make the diagnostics more verbose than they already are.

Hmm... looks like verbose is a useful keyword:

Torgeir says that svcpack.log is the wrong log to look at. Etc.

(Google Groups search for
verbose author:torgeir svcpack
)


FYI For next time?


Robert
---

"Robert Aldwinckle" wrote:

> Would FileMon show the loop perhaps?

What is FileMon? It is not part of xp support tools...


> ....
> > I wish Microsoft had an answer for this, or better yet, abandon the use of
> > InactiveX for installing updates.
>
> One of the cases which is failing for you is on the CD.
> Is that using ActiveX?

Don't know, but since it seems to be embedded into the guts of most
everything (e.g. desktop, manual windows update) it wouldn't surprise me.
More of a general complaint.

>(It bypasses WU in any case.)

Yes, but both use update.exe to apply the updates.

> > I am going to contact the customer and
> > discuss a full reinstall of xp, with the hopes that this isn't a h/w problem.
> > What a PITA.

I first did a parallel install (into windows.new directory) and verified
that it was not h/w - I was able to load sp1 w/no problem. After consulting
with the client, I reinstalled his programs while booted on the new xp
install and all is now well. Still bugs me that I don't know what the cause
was, but since this seems to be a rare problem, it will probably go into the
"oh well" file.

> Too bad. My only other idea was to try using RegMon and FileMon
> to see if there were any additional clues about your loop.

RegMon?
>
> Also I think that there actually is a regedit floating around which can be
> used to make the diagnostics more verbose than they already are.

Could be. There is a potentially useful after market registry editor (don't
remember the name) that can be run from recovery console in a GUI mode. I'm
going to trac it down and get a copy. I like to try to salvage wounded xp
installations without using reinstall, except as a last resort. You learn a
lot more that way, and preserve the client's settings.


> (Google Groups search for
> verbose author:torgeir svcpack)
>
>
> FYI For next time?

Thanks. Hopefully, there won't be a next time, but if there is, knowing
where it is hanging is a good clue.