XP Service Pack Slows Programs

AEton writes "Vnunet and others are reporting that Windows XP's Service Pack 1 has introduced a flaw into the operating system. Changes to memory handling code result in programs which often allocate memory (which is many of them) can take up to ten times longer than normal to start. Microsoft has acknowledged the problem in Q815411, and while a patch is available by request from Microsoft Product Services, it will not be widely released until Service Pack 2."

Comments

The fix will cost you

[Rick the Red]

You have to pay for Microsoft Product Support Services. From Knowledge Base Article 815411: "In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem." May be canceled. Or maybe not. So it's entirely up to Microsoft whether or not to charge you for the fix to a problem they admit having! Of all the nerve.

Avoid Service Pack 1, or better yet, avoid Windows.

Re:The fix will cost you

[IIRCAFAIKIANAL]

I have come across zip files that would only open in winzip. And he could very well mean a self-extracting archive.

Honestly, how is this flamebait insightful? Parent was more insightful despite the possible (or probable) typo regarding the format of the file.

This place is going to hell, I swear. If we're going to quibble about minor mistakes instead of focusing on the thrust of the arguments, then I could waste another three lines pointing out the ones you made in your post.

Where you can find this patch...

[phreak404]

Here: http://www.neowin.net/comments.php?id=9815&categor y=main

Re:Where you can find this patch...

[jafisherton]

Click this instead of copying and pasting. http://www.neowin.net/comments.php?id=9815&categor y=main

I'm sure no one is interested but...

[JSmooth]

Here's a link to the file:

http://home.t-online.de/home/520092137223-0001/x p/ Q815411_WXP_SP2_x86_ENU.exe

Have seen this

[IanBevan]

We have seen this exact behaviour when benchmarking our heap management product. Although our software is targetted at multithreaded software and multiprocessor machines, we've been surprised to see it improve performance of non-multithreaded programs by so much on XP. We've seen it speed up single threaded applications on Windows 2000 too, but not by so much.

And please, before somebody gets started with a flame war, WinHeap is not open source (although there is a source code license available), but it is free for non-profit use.

Re:Show me the mirror!

[TBone]

And I answer my own question... :) http://www.warp2search.net/article.php?sid=11377

More mirrors for Patch

[N8F8]

Q815411_WXP_SP2_x86_ENU.exe

Q815411_WXP_SP2_x86_ENU.exe

Q815411_WXP_SP2_x86_ENU.exe

That explains it

[jkirby]

This explains why my Acrobat reader is crawling. I installed the fix and now all is back to normal.

Downloads/Patches Right Here -- i386/Alpha

[mattyohe]

Just because im a nice guy...

http://www.paricom.com/matt/xphotfix/

Re:w2k is effected as well

[randyest]

Yes, I have, a lot! I even have some very informal and unscientific benchmark results (counting 1-mississippi, 2-mississippi, . . after the double click until load) because not long before SP1 came along I was testing my system to see if changing my BIOS RAM timing made any diff on prg load times. It didn't, but I scratched the MS times (that's the state abbrev for mississippi, BTW, which I am quite tired of typing already) on some paper that, as they so often do, stayed on my desk past it's useful life.

After installing SP1 I immediately noticed longer load times. The load times are all, consistently, still the same, and noticeably longer than XP (pro, BTW) before SP1, which I used for almost a year (more?). I really started to take for granted sub-1s ie load times. Sigh. Anyway, here are the data:

ie: 1 MS max, every time. with SP1: 3-4 MS, depending on what else is up

adobe premiere 6.5: 7-9 MS, with SP1: 18-25 MS

excel xp with a 16MB spreadsheet (loaded from a shortcut to the sheet file): 20-25 MS. with SP1: 60-90 MS.

DVArchive (replay tv simulator, all in JAVA 1.4.1, a very slow-loading monkey): 30-35 MS. with SP1: 90-100 or tired of counting MS.

This sucks. Especially now that I know why, for the following reason. Before, I simply attributed the slow down to the mysterious hardware and software gremlins (and I'm an ASIC designer -- we know better than most just how real these critters really are -- ask me about typical chip testing coverage (90-98%), or to compare the MS bugs we cry about to the insane, random bugs in million-dollar EDA software from Cadence and Synopsys), but now I know that an upgrade that ostensibly should have improved system performance has instead worsened it, I'm bummed. Worse, there were some hassles with my (legit) corp key for XP with SP1, causing me quite a bit of hassle getting the thing installed to begin with.

OK, maybe SP1 made it more secure, or less crash-prone (wasn't bad before though, and doesn't seem better now), or something. Yes, I'll tell myself that -- something improved. I'm just not sure exactly what it is.

RTFriendlyKBA

[hackwrench]

This particular fix requires calling Technical support to get. It's even in the Slashdot article!

THE FIX DOES NOT COST ANYTHING -- DOWNLOAD LINKS

[mattyohe]

What you can do is call 1-800-936-4900 which is Microsoft's Hotfix Line.. Tell them the Q article and they will pull it up and send a link in your email.

But I have already done this for you.. And I didn't forget you alpha users!

http://www.paricom.com/matt/xphotfix

One other major problem

[AsnFkr]

I work in a local computer repair shop, and 30% or so of the computers we load SP1 on stop booting properly. No safe mode, no VGA mode, just a wipe and reload. They boot then restart as soon as they should be getting to the desktop, caught in a eternal loop. Unless it is specifically requested by the user, I definatly don't load it. Thats just the major of many other problems we have come across with SP1.

Re:THE FIX DOES NOT COST ANYTHING -- DOWNLOAD LINK

[SonicBurst]

Not to be an ass or anything, but XP doesn't run on alphas. If you take a careful look at the patch file, you'll see ia64 in the file name. 2 completely different architectures.

Re:More /. FUD.

[Mattsson]

Well... Actually, it's not /. FUD.

1.
It's being reported in other places than /.
I first read about it in the newspaper...

2.
It's being reported on Microsofts own website.
So maybe it's microsoft FUD? =)

3.
The problem actually exists. (Thus is not FUD)
It doesn't appear on *every* XP computer with SP1, but some actually load programs at 1/10 the speed that they did without SP1.

Even on /. some bad news about Microsoft turns out to be true. =)

DHCP Problems persist as well

[citking]

SP1 for XP was supposed to address the DHCP problem that Microsoft has had with XP Home. Being a tech guy for a college, I can tell you that the DHCP issue was never corrected and people had to end up upgrading to XP Pro or upgrade to 2000 (yes, XP Home to 2000 is an upgrade, IMHO).

Re:quality

[Anonymous Coward]

You don't pay attention to the generally sorry state of QA in general for commercial programs and their service packs. From personal experience with companies who shall remain nameless, several customers actually fear service packs coming out. Sure, they're required. Sure, they often fix long-standing bugs. Sure, they might add needed functionality. But from what I've seen, the QA process is often along the lines of rubberstamping the release in order to meet an arbitrary deadline set by someone who thinks it's more of a negative impact to delay a release by a week than it is to make sure said release works, let alone works well.

Case in point, Anonymous Company recently released a service pack on-time which had supposedly been through QA. What happened when customers installed it? Their systems relying on this software suddenly stopped working, or started corrupting data. How could this have slipped past QA? Simple. QA in most places is usually composed of people who can't figure out how to map a network drive when given the complete \\machine\path\to\map along with the necessary username and password. And yet these are the people who are supposed to make sure everything works before being released, risking the wrath of management if they say "No, we can't do that."

(Posted anonymously to protect the guilty)

Re:HAHA

[Anonymous Coward]

There's a faster keygen out there. TheBlueList works by generating random keys and checking for validity, you know - oh, and its random routine is messed up so it has the tendency to generate the same group of keys at the beginning (leave it running for a couple of days, count duplicates, THEN take one that wasn't duplicated). There are flaws in the key algorithm which allow for more intelligent guesses - not much more intelligent, but the quasi-random routine in the new keygen's better. That keygen works at about three keys a minute on an Athlon XP 2200+.

Of course, I can't give a link here, so you'll have to go searching.

Re:640K is enough

[ReadParse]

That's an urban legend.

For all you naysayers out there....

[John Courtland]

I've just installed the hotfix and it has made quite a difference on my 433MHz w/ 256MB RAM laptop. Trillian and my wireless network monitor both start up noticably faster, and Opera starts faster as well. I would say I notice a speedup of a few seconds for the network and maybe 1-2 seconds for Trillian, maybe 4 for Opera.

malloc/free broken under NT...Memory Management???

[lent]

malloc() and free(), the first two dynamic memory management functions that most C programmers learn, were broken back in Windows NT.


If you ever had an application ported from UNIX to NT that wasn't a memory hog under UNIX but slowly ate its way through virtual memory on NT, this is most likely why.

Microsoft sneakily added the _heapmin() function to combine contiugous small free'd blocks into big chunks of memory.
Unfortunately, free(), malloc()'s happy buddy, had been combining free blocks on each call to free() since the dawn of the C programming language.
My guess is Microsoft got better performance on benchmarks by essentially not freeing memory!
If you look at K&R "The C Programming Language", Kernighan & Ritchie implement malloc and free

free() itself is the last thing. It scans the free list, starting at freep, looking for the place to insert the free block. This is either between two existing blocks or at the end of the list. In any case, if the block being freed is adjacent to either neighbor, the adjacent blocks are combined. The only troubles are keeping the pointers pointing to the right things and the sizes correct.

Hey but don't take my word for it. Intel has warned you about this for a while, [p.61 of 101].

NOTE for MSVC users: As in any C application, the standard C calls malloc() and free() may be used to manage memory. If you are using the Microsoft Visual C++ compiler, it is VERY IMPORTANT to note a scarcely documented fact of the Win32 API, in that free() does not actually free the memory that is being accessed (as it does in most standard C compilers). MSVC will free the pointer to the memory but will not actually release the physical memory. To release the physical memory a call to the Windows extension function _heapmin() must be made. This function should be documented in Win32 API documentation but it may be noted that it is difficult to find a reference to it otherwise. If the application uses free() and malloc() but not _heapmin() then virtual memory issues will arise during extended use of the application.

But Mircosoft "fixed" it in MSVC 4.0 and up.

Note [New feature hides ugly bug]In Visual C++ Version 4.0, the underlying heap structure was moved to the C run-time libraries to support the new debugging features. As a result, the only Win32 platform that is supported by _heapmin is Windows NT. The function returns -1 and sets errno to ENOSYS, when it is called by any other Win32 platform. [But what happens if you run an old VC < 4.0 compiled binary? Probably the old function gets called]

In a related move, Microsoft has quietly added to the Windows SDK that the color red, formerly 622 - 760nm, shall be redefined with the values 455 - 492nm (formerly known as blue). Programs from other platforms should add a call to the _PutOnRoseColoredGlasses() function to avoid compatibility problems. :-)