WHEA issues during OCCT upgrades for XEON/EEC RAM without overclocking
WHEA issues during OCCT upgrades for XEON/EEC RAM without overclocking
I'm still uncertain whether the issue lies with the CPU or RAM. I assumed it was the CPU because I just swapped in a new one, but I'm not entirely sure. My machine is a Dell Precision T3610. About a month prior, I upgraded its RAM to an 8x16GB DDR3 ECC setup. After several memory checks, I didn't see any faults. Yesterday, I swapped in a used 2667 v2 CPU from eBay (not overclocked—probably the system can't be overclocked). I ran multiple memory tests using Memtest86 and Memtest86+, both completed without errors. After a full overnight run, I booted into Windows and performed various Prime95 tests on CPU, RAM, and stress scenarios (some with and some without Furmark). All came back clean. Then I updated my BIOS to the latest version and ran a RAM test—still no issues. Finally, I applied the newest OCCT updates and ran a RAM diagnostic; everything passed. I also checked the CPU with Extreme benchmarking, which revealed a WHEA error. The Event Viewer logged an event about a corrected hardware issue in memory, with no specifics. I tried running OCCT’s 2021 Linpack test using default RAM usage, but it still reported the same WHEA error. Both attempts to run the test with full RAM allocation failed, but on the third try it succeeded without errors. This pattern suggests something might be amiss. Could it be the CPU or the RAM? I searched online, but most advice focused on overclocking risks and BIOS limitations. It seems most users report WHEA errors only after overclocking or unstable BIOS settings, not during normal operation. Still, the repeated failures point to a potential hardware concern. I'm left wondering if this used CPU survived all tests yet failed under stress, or if the RAM is the culprit. The fact that my system ran flawlessly for a month without issues makes me cautious, especially since I didn’t adjust any settings or overclock.
This could relate to a chipset or CPU compatibility problem. Some models seem more likely to work without issues than others, based on cross-references for Xeons. Chipsets generally only work with a limited set of processors. Do you know the chipset model of your system? If the E5-1620 v2 was your original CPU, it likely corresponds to an Intel C602 chipset, which supports a 2667 but not the v2 version. https://www.cpu-upgrade.com/mb-Intel_(ch...C602J.html Updated October 30, 2022 by An0maly_76 Added more details
According to HWiNFO64, the motherboard is a "DELL 09M8Y8" with an "Intel C600/X79 (Patsburg)" chipset.
Missing C600 info, but the X79 compatibility list is available. *looks at notes* The C602 appears to list both chips as supported. *smirks* Yet C600 seems to be missing? Updated October 30, 2022 by An0maly_76 Added more details
to rule out the CPU being the culprit - have you tried swapping the 1620v2 back in and running that same test? could be a faulty memory channel or something on the new processor that didn't show up under p95. also, dell has not validated 26xx CPUs with this board, so beware of that. this is a workstation machine, hence why it's only validated with 16xx chips. 26xx chips are supported by the chipset (intel didn't really care at this point).
That was the additional argument I intended to highlight. The H61 is compatible with i7-3770, whereas the POS Lenovo board I owned only worked with certain models up to i7-2600. That said, the 2600 isn't that problematic—it's just that top manufacturers often push boundaries in ways that can be frustrating. Edited October 30, 2022 by An0maly_76 Updated, more info
I need this setup by Sunday since I can't easily swap the CPUs back quickly. The cooler is really difficult to clean, I'm running out of cleaning supplies, and the special paste I used is no longer available. If the CPU connection is faulty, then the error would occur every time and wouldn't be fixable if the signal is physically blocked. I didn’t run OCCT during my first installation with the old CPU, but I saw a few small "WHEA Event 2" entries around the time I first installed it, probably during Prime95 tests. That was a concern if the CPU wouldn’t work properly. But this system seems popular enough that many people buy used CPUs and upgrade later. You can find more info here: https://greenpcgamers.forumbee.com/t/634...rade-guide. The built-in diagnostics on this Dell model didn’t detect any issues, even in through test mode. Why aren’t the WHEA errors showing up in Memtest86 or Memtest86+?
It's completely reasonable to feel uneasy about stability. My approach would be to eliminate DIMMs until the issue disappears, or to remove all RAM and reinstall them gradually. If I'm still unsure, I'd simply continue functioning normally. Reflecting on this, it might actually be a RAM problem—something I haven't tested deeply before. Why does it only show up in Linpack? That's a good point—it could relate to heat or workload, possibly both. The CPUs from this generation are quite similar, so manufacturer claims shouldn't be too concerning.
It was detected during OCCT's CPU evaluation, not just Linpack. That was the sole app showing an issue, and it triggered Event 47 if it caused a problem. Prime95 seems to produce multiple Event 2 WHEA alerts with minimal details, yet it never logged any errors or warnings itself. Of course, since I didn’t boot into Windows during testing, I’m uncertain whether Memtest86/Memtest86+ would have reported similar issues—they likely would, given their purpose. Oddly, OCCT’s RAM check came up clean, but the second time I ran Linpack after an error it didn’t repeat. So it’s not something I can consistently reproduce. Using Prime95 appears effective for generating many WHEA warnings, though I lack guidance on which memory slots to test first.