Yikes, thats gotta be first. MS not breaking something!

Paris because she can't believe it either.

... to assume that every file is in exactly the right place and every reg key is set exactly right.

If MS has known about this issue for 4 years, seems like that's enough time to put a fix in for it. Or is it too much to ask for a good customer experience.

The discrepancy I assume is because the Windows Update method only downloads components relevant to the installed system. The CD / ISO version contains everything.

However maybe there in is a clue. Perhaps Windows Update has detected the Intel driver and therefore downloads an Intel based service pack.

MS have a little responsibility here though as I believe this was known about back to SP2, and through the beta and RC of SP3. They could have at least blocked it from installing on the problem OEM installs, and insist you need to contact the OEM (i.e. HP) to get them to provide a fix.

"Yesterday we reported one theory from Reg reader Gary who pointed out that Microsoft appears to have left key updates out of the automatic version of SP3 (316MB), given that it’s missing 238MB compared to the manual .ISO version of the service pack (554MB)."

When you download a service back from Windows Update, it only downloads that which is relevant to the machine it's being applied to. When you download an ISO which is burned to a CD and subsequently used to update all manner of different PCs, then it of course has to contain the superset of all possible updates required. Of course, for any given PC, a similar amount of the total update is applied as would be downloaded from Windows Update.

But I can't believe that NONE of their alpha or beta testing uncovered this problem.

What the hell is beta testing for if not to uncover WIDESPREAD compatibility problems?

Paris, because she will never have compatibility problems . . .

Microsoft recognised this problem when SP2 was released over 4 years ago and are only now working on a solution?

How come this was a surprise - don't they test against known problems?

Sorry....silly question........test....heh.

This isn't really a MS bash, more an observation, but I would have though MS's internal testing (and betas?) would have tested the SP against common customer configurations?

This sort of configuration sounds common enough to me (subjective I guess given the media talk surrounding it) and they knew about it in 2004, so why not specifically test such a case?

It sounds a bit like MS getting annoyed with OEMs doing that, and so deciding to screw them over. Those who insta-blame MS suddenly look bad temporarily and MS get to blame someone else, so MS look like the heroes here until they mess up the next time... got to love PR.

tis the beginning of the end, when one deflects one's error onto an assistant.

how arrogant can one be when one is aware of an issue and the resolution but continues to rely on others for correct implementation. kinda reminds me of the definition of insanity.

since ms knows what the issue is and the resolution, why didn't/don't they test for the condition and resolve during the 'service pack' routine.

They are going to take (or are currently taking) alot of flak for this, yet it dosnt take a genius to figure out whats going to happen when you install an Intel processor driver onto an AMD processor machine. Think what would happen if you took an ATI graphics card driver and installed it onto a machine with an Nvidia GFX card in it.....ok, assuming you turned off the bit where the driver would pick up the problem and not activate....your GFX card wouldnt work....now think about what generally happens to a computer when a processor dosnt work....

From what I've read the blame is with Intel for not putting decent detection with their driver (oh look, my hardware isnt here...lets um...just not load), and with the daft OEMs for being lazy.

The thing that suprises me is that it only pics the problem up on an SP update, and worked at all in the first place!

PS....I just defended MS.....I think I need to go shower...

If putting the appropriate additional files and keys into the auto-update will fix the issue, then why the blue shit haven't Microsoft done it and said "Despite this being an issue addressed four years ago, and caused by lazy OEMs, we've fixed it for you. The difference is xMB in download size, but it means your PC won't crap itself. We're great like that now."

Pointing the finger just takes time which could be spent solving the issue... Something which I find proven on an almost daily basis.

It's happening on 2 Intel boxes (Dell and Sony). Both are clean installs of XPSP2, but as soon as you install SP3 the reboot malarky begins. What Fun! It took the SP3 iso to fix it.

The way sysprep is used in most shops isn't strictly limited to "the same model" hardware. Vendors change kit too frequently to be able to maintain an image per model. So you load multiple sets of drivers on the image before sysprep, and the mini install is supposed to detect and correct these problems. Ours supports everything from a COMPAQ Evo circa 2004 through HP d220s and up to Dell 620s.

Issue still might be a bad OEM image, but if the OEM has an image that has drivers for Intel and AMD, I don't see why it shouldn't work. Granted we're an Intel only shop and have been for as long as I remember, so I have no experimental data for AMD installs.

Even if it is an OEM issue, being that it was a known problem in 2004, MS should still have been testing for it in 2008. So both the OEM and MS deserve black eyes for this.

Mine also went into BSOD meltdown and HP didn't touch mine

If you inspect the data on the XP SP3 installation disk created from the downloaded .iso file, you'll find the exact same file you get when you download the standalone XP SP3 installation file. Looks like the created installation CD does in fact contain 220+MB of data but not in the SP3 data file itself. Some of the "extra" files do look like supporting data, but an additional 220 MB???

I'd like for MS to explain what all this extra stuff is and if the installation CD is the best method why did they not say something about the difference? Oh wait, maybe it's just typical MS bloatware.

HP tells Microsoft to STFU.

My home machine suffers from this problem too, and its a Dell with an Intel P4

VLK edition of Windows XP, straight off the MS Open Licensing portal, running on a VM hosted on an Intel based PC (Virtual PC 2007). Install SP3, reboot... reboot... reboot.... reboot...

Maybe not so much an OEM issue?

All this "it's an AMD issue" is passing the buck a bit. I've tested SP3 on 4 DELLGX620's so NOT AMD chipsets and 2 of them failed, one with a 0x0000007 and the other with a constant reboot issue, grrrrrrrr

The SP3 ISO contains the Windows Symbols package & .NET which is why it is 200MB+ bigger than the normal SP3 download. The fact it is on CD is just so a few techs with a few loose marbles in their heads can put it in their CD case and show it off... look SP3... ON CD!!! That smaller one you download is pale shadow of the real thing.... <roll eyes>

If this was an issue that was previously unknown about, then I could sympathise with MS.

However, by their own admission, they knew about this issue beforehand. So they released an update, with an issue that they already knew about, and then are surprised when it causes problems?

Bizarre.

(Knowing that something like this would happen, I've held off updating anything until the issues are all resolved)

...sadly lacking. Grab the iso, burn to disk, autorun it then when asked, click on the link 'What to know before installing Service Pack 3' then be told all about the joys of SP2. Oh well...

On clean installs on 1 Dell Intel, 1 IBM Intel and 2 AMD's all have been fine on having SP3 installed.

I actually have pity for the people who bought big box for home because this is a difficult one for them to resolve.

But for all you techies having this issue? You should be ashamed. Allowing boxes onto your networks with all the bloatware they come with? If you arent ghosting when you get them or at least rebuilding them then you cant blame MS or the vendors.

Having been a techie for companies using the big boxes thats always the first thing I do. If its not modem helper (come on Dell, leave it off the laptops) £$%^ing up VPN connections then it's some other useless crap blocking some app you need on there.

Sad, because this issue has shown how many of my peer's dont know better

When the CYA excuses start flying I am reminded of my friend Lenny who said "Doesn't matter who's right, its who's left".

We can only improve what we can measure. What Microsoft can measure they can improve. Excuses generally blind the eye of the author.

Jim

I put SP3 on my fully patched up to date intel machine. I run it as a trim machine (XP, ha ha) with the minimum of extra software installed and the SP3 installer tells me it can't install SP3 as "As an extra install/update is needed first" but won't tell me what.

Well maybe it's done me a favour, so *Shrug*

Alpha testing was on brand new Microsoft approved machines...

Beta testing is happening as we speak, on millions of users...

The problem with testing software is that when the tests fail, releases get delayed. The solution is simple: Fire all the testers.

I have an HP Pavilion a1430n with an AMD64 x2 and I get the endless reboot problem (I was able to go into safe mode to uninstall SP3). Since Windows XP Pro was installed clean (w/ a complete format) off a retail CD it can't be an OEM image issue in my case.

I think I'll wait a few months to have another go at installing SP3. Maybe the ISO trick will work but I'm sick of wasting time patching Microsoft's crappy, poorly-engineered operating systems. I'll install it when they've figured out the issues for sure.

Another reason why to buy a retail copy of Windows XP.

I'm very much NOT an MS fanboi, but this kind of thing isn't limited to MS. Every time a new kernel release comes out for Ubuntu, I have reinstalling my NVidia drivers to look forward to if I wish to use the GUI. Which can range somewhere from a major annoyance to a throbbing pain in the ass depending on the kind of day I'm having...

...has to say it: Never had this problem with Linux.

Wait, you mean to say that having Intel specced drivers on a non-Intel board might cause problems??? Say it ain't so!!!

Paris, because apparently HP is just as clueless, not that that's news...

Kernel updates haven't caused a problem with my NVidia drivers since the restricted drivers manager was introduced in 7.10 (I think) - course, if you're still on the old LTS version you won't have seen this.

As for SP3 - guess I'll keep my work machine on SP2 for the time being then....

If hp follows microsoft advice it potentially leads to many Q/A lines for every machine. This cost too much for poor HP. The image is for hp taking the money out of your pocket while giving back poorly q/a'ed machines.

Well i've never had an Ubuntu upgrade run smoothly so much as i love it you're talking rubbish, wireless problems generally make me want to cry.

Perhaps I should have said this never happens with non-ubuntu Linux. Ubuntu has never been anything but a pain. Thanks for reminding me.

Can't understand why it gets so much good press. Must use the same PR firm as Microsoft.

That's a joke isn't? They are trying to say that it was a fault of OEMS? I had a computer that wouldn't accept SP 1.

If I'd had some idea this was the problem I'd still be using it and screw the upgrades. An AMD Athlon 1GB chip. Perfectly adequate for my needs.

Bastards!

Good bye AOL tonight and hello Linux tomorrow.

I received an 'in office used' Mac G5 for my desktop. The system had a standard company image with minimum configuration and was fully re-imaged before it hit my desk. After logging into the system for the first time, I was prompted to install one of the larger OS updates along with quicktime/itunes crap updates as well. Installed the updates and rebooted. After the system started to load the OS......... Kernel Panic. It seams the wrong image was used and after the update, immediate kernel panics. There was no fix, the system needed the correct image reinstalled.

I can't remember weather it was a PPC image on Intel hardware or visa versa, or if thats even possible. I seem to remember it being the reason. But that would be very similar even with the vastly different architectures.

Few comments up there about not catching this sysprep problem in beta testing. I have to mention that most corporate IT departments which would use sysprep images are probably too paranoid to beta test on such systems. If they did, it was probably on a personal system built from scratch. Given so, I would gather that there probably was not much in return from the field to Microsoft -- not nothing at all, just not much.

I have to go with Microsoft to a certain extent on this one, as well. Microsoft told OEMs about this particular problem with SP2. OEMs did not correct the issue. Seems like bad form on the part of the OEMs to not ensure there were two images in use: one for Intel, and one for AMD kit. Seriously, we bitch continuously about the bloat in Windows, but I have to wonder that a good bit of that bloat is to work around bad configurations.

On the other hand, the fact that there are such differences between AMD and Intel power management leaves the idea of standardization way back. Of course, standardization like this removes the competitiveness and nullifies the idea of a free market. Lesser of two evils?

Not withstanding problems other than the incorrect power management driver, how about the shoddy driver which does not properly detect its operating platform? Is that not Intel's fault? Or maybe it is AMD's fault for having a register in the system's power management controller which kills the system when given a value which would function just fine on an Intel box?

Two real computers -- one Intel laptop and an Intel dual-core which used to be an AMD Athlon XP+ -- and one virtual machine, none of them dead from esspeethreeitis. Thankfully. Now, the hundred or so customer computers to which SP3 will be pushed over the next couple of weeks... that could be another story.

Paris, because her box functions just fine.

"They are going to take (or are currently taking) alot of flak for this, yet it dosnt take a genius to figure out whats going to happen when you install an Intel processor driver onto an AMD processor machine. "

Uhh, it detects you aren't on an AMD machine and doesn't execute? That's what happens on all my Linux systems.. my gentoo kernels are custom, but Ubuntu kernels have AMD, Intel, Via C3, Transmeta, and a couple other power management drivers. They don't blow the system up, they check the CPU type and don't run (except the right one which does run.)

"Think what would happen if you took an ATI graphics card driver and installed it onto a machine with an Nvidia GFX card in it.....ok, assuming you turned off the bit where the driver would pick up the problem and not activate...."

Exactly the point! The driver should not activate.

"your GFX card wouldnt work....now think about what generally happens to a computer when a processor dosnt work....""

Yes. This is why the driver should run a sanity check, not just run. I won't give Microsoft too much shit for this mistake, but I do give them shit for instead of being "Ooops! Let's fix those drivers" just being "Ohhhh, that's by design, we're not fixing it it's the sysprepers fault". This kind of thing is exactly why we abandoned sysprep where I work in favor of installing Ubuntu on fresh sysytems. The preseed setup for Ubuntu isn't the easiest thing to set up, but once it's setup it just goes and goes no matter what system I throw it on (I've run it reasonably on a P2-400 up to Core Duo, including AMD systems, and ran..make it "crawled".. Xubuntu on a Pentium-120... I don't recommend that for sanity's sake.)

I also use Mandriva as well as Ubuntu, and I have to say it seems to run a little faster, and is a little more polished. And I've never had the Nvidia problem with Mandriva. Man, what an utter pain trying to get Samba to run right on it though! And it has its own quirks besides that. I suppose the point I'm trying to make is that EVERY OS has its limitations and problems. I'm sure a MAC fanboi could chime in at this point, but MAC OS has issues too, and half the sh*t I want to run just won't on a MAC. Problems are a little more palatable on a 'free' OS, but only a little. Perhaps in another 50 years computers will have become seamlessly easy to use, and taken utterly for granted. Right now I believe computers and OSes are approximately where the automobile was in the 1970s>>>a lot of progress made, but much more refinement needed.

Like lots of smart IT-savvy folks have pointed out, this can affect any platform. If you have a *nix system and decide one day you want to plug your HD into a brand-new-to-the-market RAID controller. Your machine will POST fine, and most likely even get to the boot loader OK, since that's typically a lower level INT/BIOS function to get the drive spinning to a point where the system can recognize it. Yet, when the platform loads, it may panic/blue screen since the OS can't find a driver to know how to interpret the controller. Same deal with video cards or processor architecture classes. No matter what your platform or hardware, if the OS doesn't know how to properly access the hardware, you're dead in the water.

Paris, because so many people are clueless and hop on a bandwagon without really knowing anything.

It *IS* an example of the fragility of Windows. Take a Linux HDD out of an Intel box, throw it in an AMD box and (assuming a generic, modular kernel) watch in amazement as it boots. Taking a stand-alone drive and attaching it to a RAID controller... well that *might* work but don't get your hopes up. And no putting an x86 build on to PPC will probably cause hilarity.

Latest version of OS X, take Intel mac drive, attach to PPC mac. Voila, it'll boot (allegedly).

Windows falls over due to a known issue, that apparently happens with a clean install from non-OEM media? That sounds like the Windows install routine can't figure it out.

But to sum up. SP3 makes random boxen go bang, MS blame HP, HP goes WTF? STFU! AMD go STFU, Intel go MUHAHAHA, MS return to assimilating lesser species... erm... fixing it sooner or later... or never.

Balmer, because DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS!

Try 1998... or earlier. I've been building images since then, and no way in hell would we shoehorn a image for one hardware platform onto another.

I mean, come on, that's SOE-build 101.

why Windows needs a "Processor Driver"? I have used the same ubuntu disk on my intel and amd computers and have not been required to use a specific driver for a specific processor. Am i missing something here?

All the techie news sites are reporting that Microsoft claims the reason some AMD systems suffer continuous re-boots after installing SP3 is that the manufacturer left a CPU driver file "Intelppm.sys" on the disk even for AMD systems.

I have news for them: I installed WinXP/SP2 to a clean disk on my AMD system, and that file was installed without notice or choice. In fact, when I rename it, it pops back in place after the next boot.

Guess what? That's not HP's fault, or anybody else's fault but Microsoft.

Its a lashup way of building a PC, but quick and dirty for mass production of PCs. For those who don't know its a way of taking an image of a PC and throwing a few variables at it, rather than doing a proper OS install from scratch. The right wayto do it ought to be to do a scripted install so that the machines autodetect the hardware themselves properly, but getting scripted installs to work properly over a range of hardware is such a nightmare that the technique is more or less abandoned in more recent versions of Windows. It was possible in in W2k, one of the reasons my employers still stick with it, but a full install for us (including a coupla dozen extra apps and all configuration) takes 40 minutes, as opposed to about 3 mins using an image, so you can see why its popular to do the lashup. With the later version sof Windows its becoming less and less viable.

But once you get into images you are into a mess of problems with change management, version control etc and its all to easy to get into a morass where you don't actually know what the hell you've got on the PCs, so starting a new vanilla image is so much hassle that ts impossible to consider, and thus you see the mess we are in...

I haven't got much involved with automated Linux installs, but I believe that there isn't such an emphasis on umage type installs, so the setup will tend to be slower but more reliable.

Fundamentally then the problem is down to MS' godawfl installation processes...

OK maybe I am off in this but I will try anyway.

I would be extremely surprised that you would have to have different drivers for CPU types. They *SHOULD* be all the same PERIOD. It should not make a bit of difference what type of CPU you are running on. They should all be to INTEL spec or what ever spec everyone agrees on. Not one for AMD one for INTEL or whatever. Also it should not make a bit of difference how many "core's" any CPU has. MS should program their way (in WINDOWS code) to figure out how many cores it has and run the OS to that spec. *IF* AMD and others are really the same as INTEL that should be the end of the story. I suspect they are not so that is why the extra code is needed. No matter what the case it is an MS issue. If the cpu's are not Plug compatible then either MS should declare it isn't certified or make some statement like we are not responsible if you choose to run on a non intel system.

Personally Its a toss if its an MS issue or a OEM issue but I would question the issue of compatibility if I were MS and lay the blame there. Then either the OEM has to make their systems INTEL compatible or drop out of the market. I am not saying INTEL is completely free of culpability, they should be saying its not to the OEM people as well.

OK, not a reboot situation, but equally nuts.

PC 1 is a HP with an Intel processor. Service Pack 3 installs, reboots, then refuses to do DNS lookups from that point onwards.... Uninstall Service Pack 3 and all is fine. Grrr.

PC 2 is a QBic AMD machine which it refuses to install on - it starts to, gets to the end, then says 'whoops, can't do this anymore, must install again' and takes you back to where you were.

Both of these are with the CD...

Guess this is Microsoft's way of trying to make Vista look good?

And I don't even like apple that much, but so far at work OSX 10.5 has been a better tool than windows...

Pity the machines spec makes me feel ripped off (A$2700 for a machine with no BD/DVD drive and only 200GB of HDD? - outrageous)

>>If MS has known about this issue for 4 years, seems like that's enough time to put a fix in for it. Or is it too much to ask for a good customer experience.<<

Although I'm usually one of the first to bash M$, I have to say that however much M$ seeks to idiot-proof their OS, there will always be some idiot out there to prove them wrong ! It does not help when the company "that intends to challenge IBM" pays peanuts to hire monkeys as installers for their PC division !

As a sometime head of support, I'd have to say this is not a bug !! This is an RTFM case !! So no "fix" is needed. It is also "a good customer experience" for the HP people to learn to do things more carefully or get a good bollocking and lose their annual bonus for putting their boss eye-balls deep in the doo-doo !!. Perhaps they should outsource this function to a literate third world country and save all this hassle !!

Then again, kiddies these days expect everything to be handed to them on a silver platter; so what else is new ??

Not exactly true.

AFAIK the standard kernel on Linux usually has loads of standard modules. Certainly enough for the different processor typeand so a HDD with Linux on it will usually boot whatever machine it is plugged into.

The point about some brand new hardware is that - so, ok, the kernel will not recognise it because it doesn't have a module.

But in this case there is a different processor - not a new one. Windows should be able to fail safe when loading the intelppm thing. At least some sort of basic check should be in place when loading to see what the processor is.

The problem is in not handling the error.

If it really is mainly the OEM's problem then how come MS are able to release a fix?

...is in playing with the /dev stuff. DIY device drivers !! This issue comes about because the Chief Gestapo at M$ insist that everything HAS to go through the Registry !! This is what you get for desiring no-brainer installations !! In the days of yore when everything was set up by hand....

Yes, people do hop on a bandwagon.

However - this fault was known about 4 years ago and yet didn't feature in any pre release testing of SP3. Sounds like a just cause for complaint to me, although unfortunately, through my years in IT, it is just the same lack of quality control on MS releases as usual.

As for *nix - all that you say may happen if you change the hardware, but the people experiencing this problem have changed no hardware - just applied a service pack.

If it is only a registry key as claimed, then the fix ought to be trivial - check for the hardware - not there - check for the key and remove it if found.

As it has not been already fixed, and some people seem to be experiencing it in other circumstances, I'd suggest there may be more than one thing wrong.

Paris because there may be more than one thing wrong...

"All this "it's an AMD issue" is passing the buck a bit. I've tested SP3 on 4 DELLGX620's so NOT AMD chipsets and 2 of them failed, one with a 0x0000007 and the other with a constant reboot issue, grrrrrrrr"

Oddly, I've got 16 GX620s [3ghz P4D] and they're quite happy with SP3 - but I *did* start from a clean image using the Dell OEM Windows Setup CD and installed SP3 using the network redist package, as opposed to Autotragic Updates or the ISO file.

If you haven't tried that, it might be worth checking it with a bare, clean install - and obviously checking the really simple stuff; what sort of state are the caps around the voltage regulator in, how hot is the machine running, etc.

HTH :-)

Steven R

The actual service pack file included in the .ISO is the same as the one downloaded. The extra 200MB is made up of support tools and symbols, dotnetfx and other odds & sods. For the vast majority I don't think there will be any real advantage to downloading the .ISO over the basic file.

to not rely on a registry key that they knew could be incorrect and instead just detect the CPU type?

I wouldn't have thought so,

apparantly I'm wrong.

I have an issue with linux systems, and Athlon64 X2 on an M2R32MVP board, took me about 2 days to get a kernel that boots at all, most of the modern distros wouldn't work, such that now I'm not particularly keen on doing any kernel rebuilds on it.

(Some kind of power management problem, now I have a machine that won't turn itself off on shutdown.. :( )

So, in short, you can't take a HD from another linux box and stick it in there expecting it to boot, cos it won't unless it's got the right kernel switches.

Linux has processor drivers, the equivalent is integrated into the kernel like many linux drivers. The kernel is a huge monolithic thing.

This sounds like a bug in a driver, not exactly rare on any O/S.

Yeah Ed you are off target, there is different code for different processors in a Windows installation.

You can't compare swapping a Linux disk into a machine with different hardware, and applying a windows update to a working windows pc.

The first you would expect to fail unless the hardware was identical, the second should not break a working system.

...stop using Ubuntu and give Gentoo a shot.

The actual Sp3 file, WINDOWSXP-KB936929-SP3-X86-ENU.EXE, on the ISO is 316MB, the same size as the one you download from MS. It's all the other stuff that comes on the ISO (such as DOTNETFX, support, valueadded) the increases the size of the ISO to 504MB.

Oh and don't try to Slipstream XP SP3 on a vista PC as it does not work properly (the PID becomes F##ed up)

apparently it is too difficult for an OS manufacturer to 'ping' cmos.

couldn't one simply 'query' the cmos for the processor type.

Not once in the history of Microsoft and service packs has one been released that didn't knacker SOMETHING when installed directly on to the OS. You can minimise the risk by installing SP3 on a clean XPSP2 installation, but even then the only proper way to do this is to slipstream and create yourself an XPSP3 install CD.

Typically this used to be a complete nightmare. These days we have nLite and you can have yourself a lovely XPSP3 CD in about 10 minutes.

Maybe MS should just quit supporting AMD Processors. They are lame duck anyway.

To Dan Landiss: An AMD system installs IntelPPM? I truly doubt it. I have a dual boot AMD system at home and it's on neither. Installed SP3 on one of them and it installed beautifully. No issues whatsoever.

To Anyone: Unfortunately, what 95% of the XP users forget is that every system is different. Few have thought that the constant rebooting on a non-AMD system could be something else [malware, another screwy driver, etc.] ATI Catalyst drivers have a known issue with SP3 but ATI had the updated drivers ready to go. The lazy ass buggers at HP probably have known that the IntelPPM problem could be an issue and has done nothing and still have done nothings. MS support should ask the caller "HP system with an AMD CPU? Call HP."

When they mean "like" hardware for Sysprep, it's primarily not to mix processors of different brands but also don't use a Intel Quad Core image to image a Penium 3.

Surely it would be the work of a few hours to create an image of your boot system (using Acronis True Image or some such program) before installing, then if everything went t##s up you could just restore from the image ...

Gis Bin, yes. I built the computer, I installed WinXP to fresh disk. Intelppm.sys is present, and if I rename it it reappears after a reboot.

HOWEVER... recent information is that it is not the presence of that file that matters, but instead the presence of a registry entry that loads it. I have not yet searched my registry to verify.

Personally, I don't like to use Sysprep. But I don't think there's anything really wrong with it. However, you have to understand its limitations---it was never meant to be used cross-platform. It (and for that matter, making any kind of machine image and deploying it) is meant for organizations to use when deploying large numbers of identical or near identical machines within an organization. Sysprep, and especially cloning machines via an image should never be used in such a way that the same image ends up on different model machines. You might get away with it if there's only a few differences, like video or network cards--a few drivers to reconcile perhaps. But you'd have to be crazy or incompetent to expect it to work on utterly different fundamental hardware---eg. chipsets or processors.

And just to pi@@ everyone off, I LIKE AMD processors.

"Typical MS fragility

By Anonymous Coward

Posted Tuesday 13th May 2008 12:27 GMT

.. to assume that every file is in exactly the right place and every reg key is set exactly right.

If MS has known about this issue for 4 years, seems like that's enough time to put a fix in for it. Or is it too much to ask for a good customer experience."

you know, i got as far as reading this comment and had to post a reply.....

What a fucking lame response... .. "to assume that every file is in exactly the right place and every reg key is set exactly right."..... how quick will any OS fall over as soon as a config file has a colon or a semicolon in the wrong place.... or i suppose you use that new version of linux that knows what you mean...

its not microsofts problem to make fixes and patches for other companies screwups by using the wrong sysprep files or whatever the fault was....

I am getting sick of the nonsense that goes on on here, if you can make proper posts without having to rip a company to pieces because they have managed to put themselves in a prominant position in the world.... yes, maybe they have used some unethical practices.... but only the same practaces as any other company would use if they could get away with it...

OK, I admit I am coming from a mainframe background but..... with IBM processors the OS figured out at (IPL) boot time how many processors are available there is no need for a "special" file to tell the OS what and how react. It essentially "learns" how many processors are available and then creates the environment needed for execution and continues. It is no different (in my mind) than having to tell the processor how much memory there is ahead of time. Its an extremely simple process and well known besides on how to do this. *IF* AMD is not 100 percent plug compatible then it should say so, simple as that. On the other hand if its simply an issue of MS not understanding how to program (there really should not be any difference between AMD & Intel Processors) the OS to boot up without any extremely fancy programming, then MS should be brought to court and blamed. If IBM can (with no special extra code or changes) boot up on 1 to 50 processors(with no special file) there is something basically wrong with either INTEL or the MS programming staff. There should NOT be a special file that is needed to run on a AMD processor. If they are 100 percent compatible (PCM)compatible then either they should explain to the public why they are not or go out of business. The public has a right to know if they are not 100 percent compatible. Oh yes, crossed fingers behind the back does not count. I keep hearing how the PC is taking over the MF but when I hear these arguments I know it will never happen.

The Service pack included in the ISO is exactly the same as the one downloadable from the MS site well over a week ago so who are these idiots claiming otherwise?

I did a simple md5sum of the one on the iso.

WINDOWSXP-KB936929-SP3-X86-ENU.EXE bb25707c919dd835a9d9706b5725af58

download:

windowsxp-kb936929-sp3-x86-enu_c81472f... bb25707c919dd835a9d9706b5725af58

Same.

This SP works on the 5 very different test AMD PCs we've tested it on here.