Actually, it's the newest version of the FahCore_78.exe that addresses the instability issues with using the SSE extentions with some XP and MP procs. It preferentially starts folding by using the 3DNow! extentions instead of SSE extentions and will fold around 15-20% slower while using 3DNow!. Only a small percentage of AMD procs seem to be affected by this so if you have an XP that folds reliably while using the SSE extentions, you can force the core to use SSE instead of 3DNow!. The 3.25 beta client was brought out so that forcing the use of SSE would stay persistant while folding multiple WU's, which the 3.24 version wouldn't do. The 3.24 client would only do the first WU after starting it with SSE being forced and would revert to using 3DNow! on subsequent WU's, so Stanford came out with the beta 3.25 client to get around this problem. The way that you switch the use of extentions(for now at least) is to use the -forceasm flag in your startup shortcut on the beta 3.25 client.
Personally, I have run into this problem with 1 proc of my farm not liking the way that Stanford is using the SSE extentions and will hard lock, even at stock speeds and relaxed mem timings. It is the only XP that I'm having any particular problems with using the SSE extentions, so I keep it using 3DNow! and I upped the overclock to near max for that proc to help make up the folding speed difference.
grv, the proc I am having problems with is an oem XP2400 and my Tbred 2100 doesn't seem to have any particular problems with SSE and neither do the 3 Tbred A XP1700 or the Tbred B XP1700 in my farm.