8024402C and 80072ee7

Robin Walker [MVP] wrote:
> The evidence seems to be that your PC is unable to communicate with
> download.windowsupdate.com
>
> If you click on the URL above, does your browser download muredir.cab?

Yes, it appears to contain a small xml file. (In light of the results
below, which seem to indicate a slow cnxn, this download did seem to be
slow for such a small file.)

> Can you try opening a command prompt window and typing the following
> commands:
>
> route print
>
> tracert download.windowsupdate.com
>
> and copy&paste the results back?

Here it is:
-----------------------
C:\Documents and Settings\maxwell>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 13 d3 9e 36 8f ...... Realtek RTL8139/810x Family Fast
Ethernet NIC -
Packet Scheduler Miniport
0x3 ...00 40 f4 f3 ab be ...... IEEE 802.11g Wireless Cardbus/PCI
Adapter - Pac
et Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface
Metric
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.4
40
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1
192.168.2.0 255.255.255.0 192.168.2.4 192.168.2.4
40
192.168.2.4 255.255.255.255 127.0.0.1 127.0.0.1
40
192.168.2.255 255.255.255.255 192.168.2.4 192.168.2.4
40
224.0.0.0 240.0.0.0 192.168.2.4 192.168.2.4
40
255.255.255.255 255.255.255.255 192.168.2.4 2
1
255.255.255.255 255.255.255.255 192.168.2.4 192.168.2.4
1
Default Gateway: 192.168.2.1
===========================================================================
Persistent Routes:
None

C:\Documents and Settings\maxwell>tracert download.windowsupdate.com

Tracing route to download.windowsupdate.com.c.footprint.net
[64.152.2.62]
over a maximum of 30 hops:

1 1 ms 2 ms 1 ms 192.168.2.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 17 ms 18 ms 16 ms unknown.Level3.net [64.152.2.62]

Trace complete.
----------------------

Mike Maxwell

maxwell@ldc.upenn.edu wrote:

> C:\Documents and Settings\maxwell>tracert download.windowsupdate.com
>
> Tracing route to download.windowsupdate.com.c.footprint.net
> [64.152.2.62]
> over a maximum of 30 hops:
>
> 1 1 ms 2 ms 1 ms 192.168.2.1
> 2 * * * Request timed out.
> 3 * * * Request timed out.
> 4 * * * Request timed out.
> 5 * * * Request timed out.
> 6 * * * Request timed out.
> 7 * * * Request timed out.
> 8 * * * Request timed out.
> 9 * * * Request timed out.
> 10 * * * Request timed out.
> 11 * * * Request timed out.
> 12 * * * Request timed out.
> 13 * * * Request timed out.
> 14 * * * Request timed out.
> 15 * * * Request timed out.
> 16 17 ms 18 ms 16 ms unknown.Level3.net [64.152.2.62]
>
> Trace complete.

If you do the same tracert on the other PCs on your LAN, do you get the same
results?

--
Robin Walker [MVP Networking]
rdhw@cam.ac.uk

Robin Walker [MVP] wrote:
> If you do the same tracert on the other PCs on your LAN, do you get the same
> results?

No, this is what I got on one of the other PCs:
-------------------------------------------
>tracert download.windowsupdate.com

Tracing route to a258.g.akamai.net [207.138.82.23]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms 192.168.2.1
2 * * * Request timed out.
3 9 ms 8 ms 9 ms
ge-1-22-ur01.hyattsville.md.bad.comcast.net [68.
87.136.113]
4 7 ms 9 ms 12 ms te-9-3-ur02.lanham.md.bad.comcast.net
[68.87.129
..46]
5 9 ms 19 ms 8 ms te-9-1-ur01.lanham.md.bad.comcast.net
[68.87.129
..61]
6 10 ms 9 ms 9 ms te-9-1-ur01.bowie.md.bad.comcast.net
[68.87.128.
177]
7 10 ms 9 ms 8 ms
te-8-2-ar01.capitolhghts.md.bad.comcast.net [68.
87.128.182]
8 10 ms 9 ms 9 ms
POS-2-3-cr01.ritchieroad.md.pvcomcast.net [68.87
..16.165]
9 12 ms 9 ms 8 ms 12.118.122.9
10 11 ms 12 ms 11 ms tbr1-p010401.wswdc.ip.att.net
[12.123.8.26]
11 16 ms 11 ms 11 ms 12.123.8.113
12 12 ms 11 ms 12 ms att-gw.washdc.gblx.net [192.205.32.42]
13 16 ms 18 ms 16 ms so2-2-0-10G.scr1.NYC1.gblx.net
[67.17.95.73]
14 17 ms 16 ms 16 ms te8-1-10G.ar4.NYC1.gblx.net
[67.17.105.238]
15 17 ms 16 ms 16 ms 207.138.82.23

Trace complete.
-------------------------

I just re-ran it on this PC and got the same results as before, i.e.
all requests timed out except the first and last ones. However, the
previous time the last line returned an "unknown.Level3.net" (whatever
that means), this time it was
15 17 ms 16 ms 16 ms 207.138.82.23
I have no idea of the significance of that difference, or why the first
and last ones don't time out...

Mike Maxwell

I decided to try the tracert on my dialup with the PC that won't
update. If anything, it was even worse than the cable service--every
one of 30 tries timed out.

I also tried 'tracert www.google.com', back with my cable ISP again.
This gives basically the same results as 'tracert
download.windowsupdate.com' did: the first line is
1 1 ms 1 ms 1 ms 192.168.2.1
and the last line is
21 34 ms 40 ms 37 ms 72.14.207.99
while all the rest look like
2 * * * Request timed out.

Given that I can easily get to google in my browser (I'm there now),
I'm not sure what this means. But I guess that's why you have 'MVP'
after your name!

Robin Walker [MVP] wrote:
> Can you try opening a command prompt window and typing the following
> commands:
>
> route print
>
> tracert download.windowsupdate.com
>
> and copy&paste the results back?

Turned out my bad 'route print' and 'tracert' results were caused by my
firewall. I turned the firewall (Comodo) off and turned my WinXP
firewall on (I didn't figure I should be out there without any firewall
at all), and this time (using cable ISP), I got significantly different
results:
------------------------
>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 13 d3 9e 36 8f ...... Realtek RTL8139/810x Family Fast
Ethernet NIC -
Packet Scheduler Miniport
0x3 ...00 40 f4 f3 ab be ...... IEEE 802.11g Wireless Cardbus/PCI
Adapter - Pack
et Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface
Metric
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.4
40
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1
192.168.2.0 255.255.255.0 192.168.2.4 192.168.2.4
40
192.168.2.4 255.255.255.255 127.0.0.1 127.0.0.1
40
192.168.2.255 255.255.255.255 192.168.2.4 192.168.2.4
40
224.0.0.0 240.0.0.0 192.168.2.4 192.168.2.4
40
255.255.255.255 255.255.255.255 192.168.2.4 2
1
255.255.255.255 255.255.255.255 192.168.2.4 192.168.2.4
1
Default Gateway: 192.168.2.1
===========================================================================
Persistent Routes:
None

>tracert download.windowsupdate.com

Tracing route to download.windowsupdate.com.c.footprint.net
[208.172.64.222]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.2.1
2 * * * Request timed out.
3 12 ms 8 ms 9 ms
ge-1-22-ur01.hyattsville.md.bad.comcast.net [68.
87.136.113]
4 8 ms 9 ms 10 ms te-9-3-ur02.lanham.md.bad.comcast.net
[68.87.129
..46]
5 9 ms 9 ms 9 ms te-9-1-ur01.lanham.md.bad.comcast.net
[68.87.129
..61]
6 9 ms 9 ms 12 ms te-9-1-ur01.bowie.md.bad.comcast.net
[68.87.128.
177]
7 11 ms 15 ms 15 ms
te-8-2-ar01.capitolhghts.md.bad.comcast.net [68.
87.128.182]
8 15 ms 11 ms 11 ms
POS-2-3-cr01.ritchieroad.md.pvcomcast.net [68.87
..16.165]
9 14 ms 10 ms 11 ms 12.118.122.5
10 12 ms 12 ms 11 ms tbr2-p011701.wswdc.ip.att.net
[12.123.8.30]
11 12 ms 12 ms 11 ms 12.123.8.109
12 10 ms 11 ms 32 ms dcr2-so-4-0-0.Washington.savvis.net
[206.24.238.
161]
13 74 ms 10 ms 12 ms bcs2-as0-0.Washington.savvis.net
[204.70.192.166
]
14 11 ms 12 ms 11 ms bcs1-so-7-0-0.Washington.savvis.net
[204.70.192.
33]
15 25 ms 26 ms 23 ms dcr1-so-3-0-0.Atlanta.savvis.net
[204.70.192.53]

16 24 ms 23 ms 23 ms acr1-so-4-0-0.Atlanta.savvis.net
[208.172.67.245
]
17 28 ms 24 ms 25 ms 208.172.64.222

Trace complete.
---------------------------

But Windows Update still gives me the same 8024402C and 80072ee7 errors
(I just checked again).

Mike Maxwell

maxwell@ldc.upenn.edu wrote:

> Turned out my bad 'route print' and 'tracert' results were caused by
> my firewall. I turned the firewall (Comodo) off and turned my WinXP
> firewall on (I didn't figure I should be out there without any
> firewall at all), and this time (using cable ISP), I got
> significantly different results:
> [snip]
> But Windows Update still gives me the same 8024402C and 80072ee7
> errors (I just checked again).

So let's summarise what we know so far:

1. You can download with IE a file (muredir.cab) from
download.windowsupdate.com, but, according to the log, Windows Update cannot
download the same file from the same URL;

2. All the other PCs on your home LAN can use Windows Update without
problems;

3. The affected PC exhibits the same symptoms via an alternate dial-up
connection;

4. You have already tried renaming SoftwareDistribution, and re-registering
various DLLs, using Dial-a-fix.

All of this seems to point to a problem with the interface between Windows
Update and WinHTTP. Assuming that winhttp.dll is present in system32, it
should have been re-registered when Dial-a-fix repaired Windows Update.

It is possible to re-install the Windows Update files as follows:

1. Download and "Save" (not "Run"):
http://download.windowsupdate.com/v6...gent20-x86.exe
to a convenient directory.

2. Open a command prompt window and navigate using the CD command to the
directory in which you saved the above download.

3. Type the command:

WindowsUpdateAgent20-x86.exe /wuforce

That should re-install all WindowsUpdate files correctly.

For repairing WinHTTP I don't know a better way than re-installing XP
Service Pack 2 (the available downloads for WinHTTP and BITS are all pre-SP2
versions). If your CD copy of XP already has SP2 incorporated, then do a
Repair Installation (see
http://www.microsoft.com/windowsxp/u...ps/doug92.mspx
for method - this will leave all your other installations intact). If SP2
was applied after XP was first installed, then just re-apply SP2 by
downloading the complete installer from
http://www.microsoft.com/downloads/d...DisplayLang=en
which will run without requiring internet access during the process.
Unfortunately, after either of the above procedures, you will need to
re-apply all post-SP2 updates. So let's hope Windows Update is working
again by then!

As you can probably sense, I am almost clutching at straws trying to figure
out a resolution to your symptoms. If any other advisor on this newsgroup
has any better insights, please dive in now.

--
Robin Walker [MVP Networking]
rdhw@cam.ac.uk

Robin Walker [MVP] wrote:
> As you can probably sense, I am almost clutching at straws trying to figure
> out a resolution to your symptoms. If any other advisor on this newsgroup
> has any better insights, please dive in now.

I'll give your suggestions a try when I get back home this evening.

There was one other reply to my original msg, from Robert Aldwinckle,
who suggested "FiddlerTool with RPASpy (in case the problem is with
https)". I have not tried that yet, in part because I wasn't clear
what this would do, and partly because I was scared off by the RPASpy
site's statement that "RPASpy is experimental code and should only be
installed on test machines."

Which would you suggest doing first--the re-install of the windows
update and/or XP Service Pack 2, or RPASpy?

Mike Maxwell

maxwell@ldc.upenn.edu wrote:

> Which would you suggest doing first--the re-install of the windows
> update and/or XP Service Pack 2, or RPASpy?

Fiddler and RPASpy will not themselves fix anything, but might reveal the
HTTP dialog between Windows Update and the servers, and thus might provide
more diagnostic information. My bet is that the Windows Update requests
never get as far as hitting the network, so might not appear in Fiddler at
all. On the other hand, if they do appear in Fiddler, we shall have a
little more diagnostic information.

You can try the Fiddler/RPASpy combo before the re-installations.

--
Robin Walker [MVP Networking]
rdhw@cam.ac.uk

Robin Walker [MVP] wrote:
> Fiddler and RPASpy will not themselves fix anything,

Oddly, it does seem to fix it. That is, without Fiddler running, I
still can't do the update. But with Fiddler running, Windows Update
works fine! (And so does Windows Defender's built-in update, which I
presume uses the same stuff--if that's the technical term--behind the
scenes.)

> ...but might reveal the
> HTTP dialog between Windows Update and the servers, and thus might provide
> more diagnostic information. My bet is that the Windows Update requests
> never get as far as hitting the network, so might not appear in Fiddler at
> all. On the other hand, if they do appear in Fiddler, we shall have a
> little more diagnostic information.
>
> You can try the Fiddler/RPASpy combo before the re-installations.

I did do the re-install of the Windows Update files before installing
Fiddler/ RPASpy; I did not re-install XP SP2 (being basically lazy).

The first time I tried to run Fiddler, it hung in the load phase (all I
had was the splash screen), and couldn't even be stopped with Task
Manager: each time I stopped it, it apparently re-started itself. But
it worked OK after a re-boot.

Any chance I have some kind of a Trojan (which doesn't show up even
with all the scans I've done), and Fiddler is somehow stealing back
control from the Trojan? Seems far-fetched, but so does the idea that
a debugger (I guess that's what Fiddler is) would fix the problem...

Mike Maxwell

<maxwell@ldc.upenn.edu> wrote in message news:1152582461.680758.77640@m73g2000cwd.googlegroups.com...
> Robin Walker [MVP] wrote:
>> Fiddler and RPASpy will not themselves fix anything,
>
> Oddly, it does seem to fix it. That is, without Fiddler running, I
> still can't do the update. But with Fiddler running, Windows Update
> works fine!


; )


....
> Any chance I have some kind of a Trojan (which doesn't show up even
> with all the scans I've done), and Fiddler is somehow stealing back
> control from the Trojan? Seems far-fetched, but so does the idea that
> a debugger (I guess that's what Fiddler is) would fix the problem...


Your symptoms are common in interfering proxy server scenarios.
FiddlerTool is a proxy server so if you only replaced
an old proxy with a new one (e.g. instead of chaining them)
you might thereby be bypassing the (still unknown) symptom cause.

Another set of tools which would not require a proxy to be used
are netcap (from the XP Support Tools) and Ethereal (freeware)
for formatting the resulting .cap file. Ethereal can also be used
to do the capture provided you also install its WinPCap service
but FWIW I don't think that that results in as transparent a trace.


Robert
---

maxwell@ldc.upenn.edu wrote:

> Any chance I have some kind of a Trojan (which doesn't show up even
> with all the scans I've done)

From sysinternals, try RootkitRevealer.

--
Robin Walker [MVP Networking]
rdhw@cam.ac.uk

Robert Aldwinckle wrote:
....
> Your symptoms are common in interfering proxy server scenarios.
> FiddlerTool is a proxy server so if you only replaced
> an old proxy with a new one (e.g. instead of chaining them)
> you might thereby be bypassing the (still unknown) symptom cause.

When I ran proxycfg earlier, this is what I got:

------------------Attached here-----------
>proxycfg

Microsoft (R) WinHTTP Default Proxy Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

Current WinHTTP proxy settings under:
HKEY_LOCAL_MACHINE\
SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\Connections\
WinHttpSettings :

Direct access (no proxy server).
------------------End attachment---------

Is there a circumstance under which a proxy server would not show up in
the output of 'proxycfg'? (perhaps intentionally, i.e. malware?) Or
by "the (still unknown) symptom cause", did you mean something else?

Mike Maxwell

<maxwell@ldc.upenn.edu> wrote in message
news:1152630572.149674.38470@p79g2000cwp.googlegroups.com...
> Robert Aldwinckle wrote:
> ...
>> Your symptoms are common in interfering proxy server scenarios.
>> FiddlerTool is a proxy server so if you only replaced
>> an old proxy with a new one (e.g. instead of chaining them)
>> you might thereby be bypassing the (still unknown) symptom cause.
>
> When I ran proxycfg earlier, this is what I got:
>
> ------------------Attached here-----------
>>proxycfg
>
> Microsoft (R) WinHTTP Default Proxy Configuration Tool
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> Current WinHTTP proxy settings under:
> HKEY_LOCAL_MACHINE\
> SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
> Settings\Connections\
> WinHttpSettings :
>
> Direct access (no proxy server).
> ------------------End attachment---------
>
> Is there a circumstance under which a proxy server would not show up in
> the output of 'proxycfg'? (perhaps intentionally, i.e. malware?) Or
> by "the (still unknown) symptom cause", did you mean something else?
>
> Mike Maxwell


proxycfg only shows the WinHTTP proxy settings
which as I understand it is in a different protocol layer.

Also at one point I think it was thought that its display
wasn't always reliable so repeating the command which
would cause that display could be a good idea.

I think that you could still have IE proxy settings in effect
which would be different. E.g. that would be the reason
for the -u switch syntax, to ensure they were the same.


You could look at that side of the picture with this diagnostic:

msinfo32 /category IEConnectivity

That's where FiddlerTool would work from.
Heh. It never even occurred to me if it would be necessary
to do proxycfg -u just because you inserted FiddlerTool
into IE's communications path.

I'm also not sure if the -u switch is a one-time thing
or whether it enables a continuous update of it in which case
the question about setting it when you activated the
FiddlerTool proxy would be moot.

So my guess would be if the proxycfg -d option was
really in effect it may just mean that certain transactions
would not be traced by FiddlerTool. But I don't know.
I have never seen any detailed documentation (e.g. specs)
on how this is supposed to work and I have never bothered
to do sufficient blackbox testing to do the reverse engineering
required as an alternative.


FWIW

Robert
---

I finally fixed it; this msg is just a follow-up for anyone reading
this thread, no reply required.

The "fix" when I used RPASpy to monitor things (as per my 10 July msg)
worked only some of the time.

The inability to do updates affected not only Windows Update, but also
Avast virus's auto update and Windows Defender. I suspect (but don't
know) that that's because all these programs use the same technique to
ensure that they reach the right website, rather than an imposter.

Towards the end, I was getting behavior that looked like malware--one
example is that Firefox launched itself multiple times, with an icon on
the pages in Firefox that said "Home Page" which I didn't click on, but
which I suspect was not my real home page. The only way to stop this
behavior was with the Task Manager (no matter how fast I clicked on the
'x' buttons in the upper right-hand corner of FF, new instances came up
faster). Nonetheless, scans with multipe virus scanners and spyware
detectors showed nothing, nor did a scan with RootkitRevealer. So I'm
at a loss to explain what was going on.

The only thing I didn't try was to re-install the Windows Update files.
I decided it would be easier (and more secure, in light of the other
problems I was starting to have) just to re-install Windows.

The fix that finally worked was to use the OEM's Windows re-install CD
to re-install Windows. Fortunately, this saves your data (to a
temporary partition, I presume) before re-formatting (the partition
with Windows). And everything is working fine again.

Thanks to all for your suggestions!

Mike Maxwell

[JudaZ]

Hi, just wanted to add, for anyone that experinece the same problem.

Had the same problem as above on a customers computer, but what finally solved it for me was running, smitfraudfix v2.330 found here Mainly its the winsockfix that solves it.

Hopefully it will help someone else.

By the way, some antivirus programs complain about a file in smitfraudfix called reboot, used this program in a lot of diffrent situations and had no problems, but if you feel unsure you can delete the reboot file, you can still run the program.