Definitions STILL won't update.

[Kerry]

I have deleted the >120k version of gcUnCompress.dll
(several weeks ago) and re-installed MSAS to get the
smaller version (>90k). That worked, for a while. Was
able to get past sypware defs 5727 with that fix.

However, now it is stuck on defs 5735. Keeps trying to
download 5737 and install. Says it does. Looks okay,
until you click "Check for updates" again. Does the same
blasted thing again (updates def 5735 to 5737).

I now have MSAS build 1.0.615 as of yesterday, and the
problem persists today. I deleted the frigging
gcUnCompress.dll file and re-installed MSAS (from
(Add/Reove programs) again, ran the updater again, and it
goes through the motions of downloading and installing
the 5737 defs again. Click "Check for Updates" again
when that is done. Guess what. SAME FRIGGING PROBLEM.

Can't you guys get a simple updater to work, for crying
out loud?

 

[Engel]

Did you

Empty your IE cache and your other temporary file folders,
eg: c:\temp, c:\windows\temp or C:\Documents and
Settings\<name>\Local Settings\Temp (the path to your temp
folder will change depending on your name) - sometimes
programmes can be hidden in there - watch out for
mysterious *.exe files or *.dll files in those folders.

Before you reinstall?

http://www.mvps.org/winhelp2002/delcache.htm

 

[Kerry]

1. A user should NEVER have to MANUALLY
delete "temporary" files from all over the frigging hard
drive in order to get a so-called AUTO updater to work.

2. I did it anyway just now at your suggestion.

3. It did not fix the problem.

4. The same problem exists on three different computers
(two with XP Home and one with XP Pro).

5. The problem was gone for a while when I had to perform
Robin Walker's 10 step "fix" for the updater errors back
with Spyware Def file 5727 a few weeks ago.

6. The problem came back this week, and it happens on
both build 1.0.614 AND the new build 1.0.615

7. I especially love this quote at the end of Robin
Walker's article with the Updater/gcUnCompress fix:

"You won't ever have to manually install the definition
files again, nor will the update keep repeating every
time you try."

Famous last words.

 

[Anonymous Bob]

Did you

Empty your IE cache and your other temporary file folders,
eg: c:\temp, c:\windows\temp or C:\Documents and
Settings\<name>\Local Settings\Temp (the path to your temp
folder will change depending on your name) - sometimes
programmes can be hidden in there - watch out for
mysterious *.exe files or *.dll files in those folders.

Before you reinstall?

http://www.mvps.org/winhelp2002/delcache.htm

Engel,

I see the same problem here on w2k. I've cleared the cache from
internet options, I've cleared the cache using ZAP, I've disabled
ZAP, I've disabled NAV.

I don't believe this is a cache problem. Here's the errors.log
entry:
"0::Could not verify WinTrust::fileE:\Program Files\Microsoft
AntiSpyware\temp.zip::catalogE:\Program Files\Microsoft
AntiSpyware\temp.cat::gcTCPObjLib:modMain:VerifyCatalog::7/21/2005
9:41:26 PM:2000:1.0.615"

gcTCPObjLib.dll is dated 7/12/05 as are the other build 615 modules.

It this point I'd be looking for a hardware problem.

If you can give me the ip of the servers/mirrors, since I'm one of
the victims, I'd be happy to sit out here all night running
pingplotter looking for the router that's dropping packets.

If that's something Microsoft would prefer not to be general
knowledge, my email is (e-mail address removed)

Bob Vanderveen

 

[Anonymous Bob]

It this point I'd be looking for a hardware problem.

If you can give me the ip of the servers/mirrors, since I'm one of
the victims, I'd be happy to sit out here all night running
pingplotter looking for the router that's dropping packets.

So I figured I'd capture at least one of the ip addresses in
question. I brought up TcpView and started an update on MSAS. That
gave me the ip I was connecting to. I ran pingplotter against that
address and other than a bit of congestion occasionally, all was
well. I didn't realize how well it was until I checked MSAS.

It had updated successfully at that ip!

You know how that goes...it never breaks while you're watching. ;-)

I guess I'll have to wait for the next def file update.

Bob Vanderveen

 

[Alan]

Removing those files can be very important, and usefull.

At times the cache becomes so large that it causes
problems downloading things. I've had to remove those
files in the past because some features of AOL's web-
based e-mail system weren't working properly. A tech
from AOL told me to do that, and after rebooting, the
spell checking feature worked fine. I had to do the same
thing last night because going to this forum of the
newsgroup constantly kept coming up with every post and
reply shown, and no 'Collapse All' button visible. Doing
so fixed the problem.

At times like these, deleting these files can help, as
somwtimes older files can cause problems with the newer
files.

As for 615, you might not have 615 installed at all. Go
to Help > Microsoft Windows AntiSpyware... and see if 615
is installed. You might have actually downloaded 614, as
there's been some problems with the server sending 614
instead of 615.

Also, did you first shutdown MSAS before updating to
615? If not, then this will likely cause problems.

I'd suggest shutting down MSAS, remove the application,
go to c:\windows\program folders and rename the MSAS
folder to end with .old. Now reboot the system and
install MSAS.

Remember, this is a beta version not a final release
version, and these types of problems are typical of betas.

Alan

 

[Kerry]

At times the cache becomes so large that it causes

problems downloading things.

IE allows you to set a throttle on the size of your
temporary Internet files cache. I have mine throttled
down pretty low.

MSAS is not a Web Browser (neither is AOL really, but
that's a different debate). It may be using the
application or system temp folder(s) but if MSAS is using
Temporary Internet Cache then it must have IE embedded in
it (possible, but I don't think so).

Aside from Internet cache, Apps that leave behind "temp"
files in the system or application temp folders when they
are done with them should be uninstalled, and the
programmers who wrote them should be slapped crosseyed.

I've had to remove those
files in the past because some features of AOL's web-
based e-mail system weren't working properly. A tech
from AOL told me to do that, and after rebooting, the
spell checking feature worked fine.

Nice anecdote, but this ain't AOL (and I'm a 25+ year
computer systems engineer, by the way).

As for 615, you might not have 615 installed at all.

Yeah, I really, really do.

Go to Help > Microsoft Windows AntiSpyware...
and see if 615 is installed.

I know you are trying to be helpful, but newbies should
not be Beta testers. I know what I'm doing and I have
615 installed.

You might have actually downloaded 614, as
there's been some problems with the server sending 614
instead of 615.

Uhhh, no. The autoupdater did the download and install
all by itself, not me.

-Kerry-

 

[Kerry]

After a couple of days wrangling with def upgrade from
5735 to 5737 on three different computers, it finally
worked on one (haven't tried the other two yet).

Trish just posted a message in the "Announcements"
section that 5737 is now available, so I tried it after I
saw that post, and it worked.

What was the problem? An incomplete/trashed/bogus 5737
def file on the MSAS download servers?

-Kerry-

 

[Anonymous Bob]

If you can give me the ip of the servers/mirrors, since I'm one of
the victims, I'd be happy to sit out here all night running
pingplotter looking for the router that's dropping packets.

So here's pingplotter with a dropped packet at hop 12. You can
disregard -32764 as this is the free version and I think they left
that bug in there to encourage people to upgrade. ;-)

The times don't look good from hop 9 - 12. I'm sure this is just
momentary congestion, but I'm also sure it's not a one in a million
chance.

Another thing I've noticed is that if you monitor the connections
with TCPView when doing a manual update check the connections seem
remain in an "established" state much longer than is needed if the
dialog box is left open. I would imagine that's a strong server in
San Jose, but with 20 million users and some finite maximum number
of established connections this could cause problems. Perhaps some
more attention to network error detection and recovery would be
appropriate.

Now that I've documented the dropped packet I can get some sleep.
<bEg>

Target Name: www.spynet.com
IP: 216.32.240.29
Date/Time: 7/22/2005 1:38:16 AM

1 4 ms 3 ms 4 ms 245-60.35-65.tampabay.res.rr.com
[65.35.60.245]
2 8 ms 11 ms 9 ms [10.100.192.1]
3 12 ms 12 ms 11 ms
atm6-0-961.tampflerl-rtr2.tampabay.rr.com [65.32.10.222]
4 12 ms 12 ms 10 ms
pos6-0-OC-192.tampflerl-rtr4.tampabay.rr.com [65.32.8.137]
5 13 ms 15 ms 11 ms so-9-1.car2.Tampa1.Level3.net
[4.79.174.1]
6 10 ms 10 ms 12 ms ae-1-56.mp2.Tampa1.Level3.net
[4.68.104.161]
7 -32764 ms 78 ms 75 ms as-2-0.bbr2.SanJose1.Level3.net
[4.68.128.157]
8 -32764 ms 79 ms 75 ms ge-2-0-0-53.gar1.SanJose1.Level3.net
[4.68.123.66]
9 82 ms 491 ms 86 ms [65.57.86.6]
10 474 ms 77 ms 78 ms ten7-2.pax-76cb-1a.ntwk.msn.net
[207.46.37.25]
11 446 ms 430 ms 450 ms pos6-2.tuk-76cb-1a.ntwk.msn.net
[207.46.34.173]
12 418 ms * 422 ms ten2-3.tuk-76c-1b.ntwk.msn.net
[207.46.35.77]
13 * * * [-]

Respectfully,
Bob Vanderveen

 

[Robin Walker [MVP]]

I don't believe this is a cache problem. Here's the errors.log
entry:
"0::Could not verify WinTrust::fileE:\Program Files\Microsoft
AntiSpyware\temp.zip::catalogE:\Program Files\Microsoft
AntiSpyware\temp.cat::gcTCPObjLib:modMain:VerifyCatalog::7/21/2005
9:41:26 PM:2000:1.0.615"

That is the evidence that explains why the definitions update did not work
for you.

Here is how MSAS definitions update works:

MSAS downloads a zipped definitions file into temp.zip.
MSAS then downloads the corresponding cryptographic verification file into
temp.cat.
It then performs a cryptographic checksum of the temp.zip file, and compares
it with the expected checksum in the temp.cat file, which is backed up by
cryptographic certificates verifying that the temp.cat file was signed by
Microsoft and not forged by anyone else.
Only if the checksum check succeeds does the temp.zip files get unzipped
into the .gcd definitions file.

Your error message shows that the cryptographic comparison failed, perhaps
owing to one of these problems:
- the download of the .gcz file was corrupt;
- the download of the .cat file was corrupt;
- the downloaded .gcz file was stale, from a previous version;
- the downloaded .cat file was stale, from a previous version;
- one or both of the .gcz/.cat files was stale because it was taken from a
web cache somewhere in your PC or between your PC and the Microsoft update
servers.

Now for the bad as far as my understanding of the MSAS definitions
update process goes, we will ALWAYS see definition update failures and
repeat cycles for the first day or two after a new definition file is
released, for the following reasons.

When it is about to try updating the definitions, MSAS asks the central
spynet server what the latest definition update number is. MSAS makes this
request with the "no-cache" HTTP request header, so that the request and its
reply punch through all web caches and reach the genuine spynet server, and
the genuine reply from the spynet server comes all the way back to MSAS. As
soon as the spynet central server is updated with new definitions file, the
number will be updated, and all copies of MSAS in the world will get that
new number when they ask for it.

MSAS only fetches the definitions files (.gcz and .cat) themselves if it
sees a version number higher than the ones it has already got.

When MSAS asks for the definitions .gcz and .cat files, the request is
diverted to the world-wide server farm operated by Akamai on behalf of
Microsoft. This server farm does not update itself as fast as the central
spynet server can change the definitions version number. It takes time for
all the Akamai servers to get updated with the new definitions .gcz and .cat
files.

So, the "early adopters" who race to get new definitions files as soon as
the central spynet server signals an update, will almost always fail to get
the update, and will observe the "repeating update cycle" which is so often
reported. We should just wait for the Akamai server farm to propagate the
new definitions files across the world.

There is another problem causing the same update problem: the actual HTTP
requests for the .gcz and .cat files are not sent with the "no-cache" HTTP
request header, so stale versions of the .gcz and .cat files in web caches
between MSAS and the Akamai server farm will return stale versions of the
files. Memo to the MSAS developers: for the definitions files, you should
not make an Unconditional HTTP GET request: you should instead make it a
Conditional GET request, looking for a different "ETag" header, or with an
"if-modified-since" condition. Making the request Conditional will give
intervening web caches (including the MSIE Temporary Internet Files) the
right signal for whether they need to refresh their stale copies.

None of this is helped by the fact that MSAS never indicates to the user if
the Definitions update process has failed in any way: MSAS always appears to
indicate an update success. Users need to be told if the updates have
failed, then they won't be so puzzled that the updates are tried again next
time.

 

[Robin Walker [MVP]]

7. I especially love this quote at the end of Robin
Walker's article with the Updater/gcUnCompress fix:

"You won't ever have to manually install the definition
files again, nor will the update keep repeating every
time you try."

Famous last words.

The procedure posted was a complete final permanent fix for the
incorrect-version DLL problem experienced with Build 614, and only with
Build 614. The procedure is utterly inappropriate for all subsequent build
versions of MSAS.

The incorrect version DLL was a complete showstopper, that made it
impossible for MSAS ever to update any definitions files.

Now the showstopper has been fixed with Build 615, other latent definitions
update problems have come to light, on which I have also posted analyses and
workarounds. These are not complete showstoppers, and the definitions will
eventually update in time, given patience.

 

[StuNun]

-----Original Message-----

I don't believe this is a cache problem. Here's the errors.log
entry:
"0::Could not verify WinTrust::fileE:\Program Files\Microsoft
AntiSpyware\temp.zip::catalogE:\Program Files\Microsoft

AntiSpyware\temp.cat::gcTCPObjLib:modMain:VerifyCatalog::7/
21/2005

9:41:26 PM:2000:1.0.615"

That is the evidence that explains why the definitions update did not work
for you.

Here is how MSAS definitions update works:

MSAS downloads a zipped definitions file into temp.zip.
MSAS then downloads the corresponding cryptographic verification file into
temp.cat.
It then performs a cryptographic checksum of the temp.zip file, and compares
it with the expected checksum in the temp.cat file, which is backed up by
cryptographic certificates verifying that the temp.cat file was signed by
Microsoft and not forged by anyone else.
Only if the checksum check succeeds does the temp.zip files get unzipped
into the .gcd definitions file.

Your error message shows that the cryptographic comparison failed, perhaps
owing to one of these problems:
- the download of the .gcz file was corrupt;
- the download of the .cat file was corrupt;
- the downloaded .gcz file was stale, from a previous version;
- the downloaded .cat file was stale, from a previous version;
- one or both of the .gcz/.cat files was stale because it was taken from a
web cache somewhere in your PC or between your PC and the Microsoft update
servers.

Now for the bad as far as my understanding of the MSAS definitions
update process goes, we will ALWAYS see definition update failures and
repeat cycles for the first day or two after a new definition file is
released, for the following reasons.

When it is about to try updating the definitions, MSAS asks the central
spynet server what the latest definition update number is. MSAS makes this
request with the "no-cache" HTTP request header, so that the request and its
reply punch through all web caches and reach the genuine spynet server, and
the genuine reply from the spynet server comes all the way back to MSAS. As
soon as the spynet central server is updated with new definitions file, the
number will be updated, and all copies of MSAS in the world will get that
new number when they ask for it.

MSAS only fetches the definitions files (.gcz and .cat) themselves if it
sees a version number higher than the ones it has already got.

When MSAS asks for the definitions .gcz and .cat files, the request is
diverted to the world-wide server farm operated by Akamai on behalf of
Microsoft. This server farm does not update itself as fast as the central
spynet server can change the definitions version number. It takes time for
all the Akamai servers to get updated with the new definitions .gcz and .cat
files.

So, the "early adopters" who race to get new definitions files as soon as
the central spynet server signals an update, will almost always fail to get
the update, and will observe the "repeating update cycle" which is so often
reported. We should just wait for the Akamai server farm to propagate the
new definitions files across the world.

There is another problem causing the same update problem: the actual HTTP
requests for the .gcz and .cat files are not sent with the "no-cache" HTTP
request header, so stale versions of the .gcz and .cat files in web caches
between MSAS and the Akamai server farm will return stale versions of the
files. Memo to the MSAS developers: for the definitions files, you should
not make an Unconditional HTTP GET request: you should instead make it a
Conditional GET request, looking for a different "ETag" header, or with an
"if-modified-since" condition. Making the request Conditional will give
intervening web caches (including the MSIE Temporary Internet Files) the
right signal for whether they need to refresh their stale copies.

None of this is helped by the fact that MSAS never indicates to the user if
the Definitions update process has failed in any way: MSAS always appears to
indicate an update success. Users need to be told if the updates have
failed, then they won't be so puzzled that the updates are tried again next
time.

--
Robin Walker [MVP Networking]
(e-mail address removed)

Many thanks for your explanation of the update procedure

for the MSAS defs. That goes a long way to explain why
yesterday evening I seemingly updated successfully from
5735 to 5737, closed down for the night and then this
morning MSAS repeated the update again. The various
servers must have been playing catchup. Next time - less
haste! Give it a day or two! However, I agree there should
be a process in place informing users if the defs have
taken or not only once the entire process has been checked
and certified correct. I take it apart from being aware of
this the boys at MS are working on a simpler procedure -
or not? It sounds as if the entire procedure is over
complicated to the point it is creating more problems than
it was designed to prevent - work for the boys at MS too!

StuNun

 

[Anonymous Bob]

Reply interleaved with much snipping for the sake of brevity and
coherency.

Your error message shows that the cryptographic comparison failed, perhaps
owing to one of these problems:
- the download of the .gcz file was corrupt;
- the download of the .cat file was corrupt;
- the downloaded .gcz file was stale, from a previous version;
- the downloaded .cat file was stale, from a previous version;
- one or both of the .gcz/.cat files was stale because it was taken from a
web cache somewhere in your PC or between your PC and the Microsoft update
servers.

I somewhat agree, but I'm an old hardheaded dutchman, as you'll see
below. ;-)

MSAS only fetches the definitions files (.gcz and .cat) themselves if it
sees a version number higher than the ones it has already got.

When MSAS asks for the definitions .gcz and .cat files, the request is
diverted to the world-wide server farm operated by Akamai on behalf of
Microsoft. This server farm does not update itself as fast as the central
spynet server can change the definitions version number. It takes time for
all the Akamai servers to get updated with the new definitions ..gcz and .cat
files.

Now here is where the hardheadedness comes through. ;-)

You may see something else in the UK, but when I monitor connections
while performing an update using TCPView (from sysinternals.com) I
see only 2 established TCP connections; always the same ip
addresses; both to port 80 on the other end. One of these, the one
in Seatlle (with no rDNS - for shame Microsoft), can be resolved to
http://www.microsoft.com/athome/security/spyware/software/default.mspx
when using SamSpade.

The other address does have rDNS and is spynet.com in San Jose. It's
at this address I see occasional congestion and dropped packets, as
I documented in a subsequent post in this thread.

At no time have I seen an other ip addresses used and never have I
seen Akamai.

I would be inclined to believe during congested periods the download
attempt is unsuccessful, but MSAS doesn't retry or even acknowledge
the failure. The clue here is found under Help | About | Diagnostics
where I see "Definitions Increment Version: 90/88" on a failed
attempt.

This could be explained as a stale cache, but the evidence from
TCPView would indicate otherwise.

There is another problem causing the same update problem: the actual HTTP
requests for the .gcz and .cat files are not sent with the "no-cache" HTTP
request header, so stale versions of the .gcz and .cat files in web caches
between MSAS and the Akamai server farm will return stale versions of the
files. Memo to the MSAS developers: for the definitions files, you should
not make an Unconditional HTTP GET request: you should instead make it a
Conditional GET request, looking for a different "ETag" header, or with an
"if-modified-since" condition. Making the request Conditional will give
intervening web caches (including the MSIE Temporary Internet Files) the
right signal for whether they need to refresh their stale copies.
Agreed!

None of this is helped by the fact that MSAS never indicates to the user if
the Definitions update process has failed in any way: MSAS always appears to
indicate an update success. Users need to be told if the updates have
failed, then they won't be so puzzled that the updates are tried again next
time.

Agreed...big time!

As evidenced by "Definitions Increment Version: 90/88", or
equivalent, existence of the mismatch between the local and current
definitions is available to the program and the failure should be
indicated to the user and the version number should not be updated.

With thanks and very respectfully,
Bob Vanderveen

 

[plun]

Anonymous Bob wrote :

At no time have I seen an other ip addresses used and never have I
seen Akamai.

Hi Bob

With Ethereal you can see akadns, MS and Akamai have a special solution
between them and this was invented last year when some malware was
programmed to DDos microsoft.com as I remember.

But how it works ?

Remove your defs, start Ethereal capture and check for updates.

http://www.ethereal.com/

 

[Robin Walker [MVP]]

You may see something else in the UK, but when I monitor connections
while performing an update using TCPView (from sysinternals.com) I
see only 2 established TCP connections; always the same ip
addresses; both to port 80 on the other end. One of these, the one
in Seatlle (with no rDNS - for shame Microsoft), can be resolved to
http://www.microsoft.com/athome/security/spyware/software/default.mspx
when using SamSpade.

Because you are using TCPView, you are not getting the full picture. The
mapping to Akamai is done during the DNS lookup process.

The MSAS definition update process starts like this:

MSAS first makes an HTTP check to www.spynet.com, just to check that the
user is online. If this request fails to get an answer, MSAS returns an
error to the user. In the DNS system www.spynet.com resolves directly to IP
address 216.32.240.29.

Next MSAS makes an HTTP request to service.spynet.com, to determine the most
recent definition version number. In the DNS system, service.spynet.com is
aliased to ad.spynet.microsoft.akadns.net, which itself resolves to IP
address 207.46.236.25 when seen from the UK.

If it finds that it now needs to download new definitions files, MSAS makes
HTTP requests for the .gcz and .cat files to download.spynet.com. In the
DNS system, download.spynet.com is again aliased to
ad.spynet.microsoft.akadns.net, which again resolves to 207.46.236.25 when
seen from the UK.

Both the above IP addresses appear to be somewhere within the msn.net
network, and are routed from the UK via San Jose California, with quite high
round-trip latency.

Akamai normally does its magic by resolving the same DNS name to different
IP addresses, depending on where the caller is in the world, but I have to
say that in the special case of ad.spynet.microsoft.akadns.net, it might
resolve to the same IP address wherever you are, as of the time of posting.

Now, in this case, we cannot tell how many servers might be hiding beind the
ad.spynet.microsoft.akadns.net address. Even if it is only one (can you
imagine one server handling definitions updates for 20 million MSAS users?),
the point about the updates of the .gcz and .cat files lagging behind the
version number still holds. Even just a single IP address might represent a
server farm with load-balancing.

If you are unlucky enough to make a Definitions Update request when one but
not both of the .gcz and .cat files have been updated on whichever server
you connected to, then you will get the "Could not verify WinTrust" message
in the errors.log file, and the definition update will silently fail (but
will report it has succeeded).

 

[Anonymous Bob]

all my questions.<bEg>

I could have used Ethereal, as plun suggested, but the last time I
had to resort to that extreme I was still running W98.<g>

This is a multiboot system with 4 partitions; W98, 2 instances of
W2K, and XPP.

W98 and this instance of W2K are both highly corrupted. Although it
runs amazingly well for the shape it's in, the registry is mangled
to the point it no longer recognizes the installation cd so that I
can't do a repair. I doubt I could run Ethereal on it and the FQDN's
and the explanation you've provided make it unnecessary for me to do
so. Thank you, I'm much relieved.<G>

The second instance of W2K will eventually become my default
selection on startup and I'm slowly becoming familiar with XPP and
getting it configured into a secure system.

I have no idea what I'm going to do with W98 as that's the first
partition on the C drive and I fear losing the MBR or having the
drive letters change if I reformat it. It is still occasional useful
to answer someone's questions, but I think there's a linux
installation somewhere in my future.<g>

BTW, the ip addresses you see in the UK are the same as I see here
and given that MSAS isn't a profit center who's to say if there
isn't just one server for 20 million users.<G>

With great appreciation,
Bob Vanderveen

 

[Robin Walker [MVP]]

I have no idea what I'm going to do with W98 ...
It is still occasional useful to answer someone's questions

I recommend going over to a single installation of XP Pro SP2, and then
running all the legacy operating systems under Virtual PC.

 

[Anonymous Bob]

I recommend going over to a single installation of XP Pro SP2, and then
running all the legacy operating systems under Virtual PC.

Thanks for the thought, Robin. I've heard good things about VMWare,
but hmmmm...
cheaper than VMWare $129 vs. $199
45 free day trial

AMD 1800+ with 512MB though well within minimum specs might be a bit
on the low side.

Is it be possible to run a virtual XPP under a host XPP installed
from the same cd?

No problems with windows xp activation?

Bob Vanderveen

 

[Robin Walker [MVP]]

Is it be possible to run a virtual XPP under a host XPP installed
from the same cd?

No problems with windows xp activation?

You need a separate valid licence for each virtual XP and each real XP.

Most OEM-versions of XP are locked to the manufacturer's BIOS and therefore
will not Activate under VirtualPC or VMWare.

 

[plun]

Anonymous Bob formulated the question :

AMD 1800+ with 512MB though well within minimum specs might be a bit
on the low side.

Well this is on "the low side".
Double your memory to 1024MB and it runs much better.

You mentioned Linux before and it is really easy to run Linux
with WMWare. And also Longhorn copies found in the wild..