Ok, Blizzard's been spitting some BS lately, telling us to UNDERCLOCK our systems so we can play World of Warcraft.
Check out this thread:
http://forums.worldofwarcraft.com/threa ... 353364&P=1
Yep. They're actually telling us to underclock our non-overclocked systems in order to play the damn game because if we don't the game would just crash 5 seconds into the game. We paid $50 for this game and $15 every month after that.
Here's a quote from the forums from their tech guy:
The logical error being made is to assume that errors specific to certain hardware combinations can in fact be fixed with changes from our end. In many cases they cannot.
A poster brought up the 1.5.1 patch that removed a faulty assert statement from the Mac build. The details of that patch are that there was a memory leak that was being detected and causing the app to quit (usually in Battlegrounds). This bug was affecting all Mac players and the fix was straightforward. The second part of that story is that the same memory leak was happening on the PC build, only it was not being reported and the game was able to keep running. This was a clear cut coding bug, the bug affected *all* users in some form (asserting on the Mac, and leaking RAM on the PC), and *all* users benefited from the fix in 1.5.1.
OK, now what about 132.
We have looked really closely at the dumps being sent in. And we have seen some really interesting correlations in that the type of error popping up is often (not always, but often) by people running the exact same combination of processor and motherboard. And in some of those cases, the user was able to make a minor tweak to their memory timing settings (or simply stop overclocking) and the 132 issue went away. I'm not advocating that you do this - our policy is not to recommend BIOS setting changes unless totally neceessary - but I can report what we have been told by users.
I have to make this super clear because this is the consensus among the majority of the programming staff: any problem that stops happening when the memory timing or processor clocking is reduced, is in all likelihood an indication of a system integrity problem, not of a bug in the game code. Bugs in game code tend to take the form described above in the 1.5.1 discussion, they are often very clear cut and affect all users. Problems occurring only on (say) AMD Athlon-XP processors on Asus A7N8X motherboards with DDR400 RAM, are generally *not* the kinds of bugs that have any fix possible in game code.
Example from this week - we look at the crash dump coming back from a user (actually several different users which makes this even more interesting). We see the processor crashed while trying to access an illegal address in RAM. The code at that point in the game and the dumped state of the registers shows that - had the CPU been operating correctly - it would have calculated a valid address, a simple sum of two values, the original value still sitting in one CPU register and the add-in value being part of the instruction stream.
We can see that the CPU register has a valid value, and that the code wanted to add a small offset to it and store the result in another register - when we examine the second register in the crash dump we see that the addition result is incorrect! We have seen this same class of failure on a handful of separate machines now, and they all had the same type of hardware.
This is the kind of situation that inevitably leads us to suspect some class of system integrity problem - either thermal, or power, timing / overclocking, or a BIOS bug. There really is no way on earth to defend against faulty processor behavior in software.
In some cases there has been a BIOS bug causing memory timing to be improperly set at boot time, and leading to faulty instructions being fed to the CPU. Bluntly when we see the CPU asked to add 500 to 1000 and it comes up with 8,001,500... it is a pretty plain indicator that a bad bit was passed from RAM to CPU, or that the CPU is operating outside of its rated speed limit, or the user is having a power or thermal problem leading to faulty chip operation. It really only takes a single bad bit or calculation like this to give you a #132 error.
With all that said, why don't each of you just post a few lines of basic system info - motherboard, CPU type and speed, RAM type and amount, and so on. (not a full DXDIAG post).
Please don't be angry at us when we discover that not all machines out there are running perfectly. Take a closer look at your settings and be willing to experiment - others have, and solved some of these types of problems.
Take note that all was OK before they added in a patch last Tuesday. How come all these problems surfaced AFTER the patch? We've never had any problems before the damn patch. And now they're telling us it's OUR fault?