I have a Windows 7 64-bit machine that's freezing up roughly once a month. The last five minidumps all indicate "Caused by address" ntoskrnl.exe+4b314c, and I'm trying to figure out who owns (or is triggering failed calls of) the code at that address.

Here's the !analyze -v output from the most recent mini-dump:

Microsoft (R) Windows Debugger Version 6.3.9600.17029 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\102116-50450-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.19160.amd64fre.win7sp1_gdr.160211-0600
Machine Name:
Kernel base = 0xfffff800`04201000 PsLoadedModuleList = 0xfffff800`04448730
Debug session time: Fri Oct 21 16:47:24.260 2016 (UTC - 7:00)
System Uptime: 0 days 0:00:25.275
Loading Kernel Symbols

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

Loading User Symbols
Mini Kernel Dump does not contain unloaded driver list
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa802d3f77c8, 0, 0}

Probably caused by : GenuineIntel

Followup: MachineOwner

7: kd> !analyze -v
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa802d3f77c8, Address of the WHEA_ERROR_RECORD structure.
Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

Debugging Details:

BUGCHECK_STR:  0x124_GenuineIntel





ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

fffff880`03d1d6f0 fffff800`044c5cb9 : fffffa80`2d3f77a0 fffffa80`24f7eb50 00000000`00000029 00000000`00000000 : nt!WheapCreateLiveTriageDump+0x6c
fffff880`03d1dc10 fffff800`043a4c07 : fffffa80`2d3f77a0 fffff800`0441f2d8 fffffa80`24f7eb50 00000000`00000000 : nt!WheapCreateTriageDumpFromPreviousSession+0x49
fffff880`03d1dc40 fffff800`0430bc55 : fffff800`04481ba0 00000000`00000001 fffffa80`2d456090 fffffa80`24f7eb50 : nt!WheapProcessWorkQueueItem+0x57
fffff880`03d1dc80 fffff800`0427e065 : fffff880`01776e00 fffff800`0430bc30 fffffa80`24f7eb00 00000000`00000000 : nt!WheapWorkQueueWorkerRoutine+0x25
fffff880`03d1dcb0 fffff800`0450fc6a : 00000000`00000000 fffffa80`24f7eb50 00000000`00000080 fffffa80`24eda870 : nt!ExpWorkerThread+0x111
fffff880`03d1dd40 fffff800`04266086 : fffff880`03b31180 fffffa80`24f7eb50 fffff880`03b3c1c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03d1dd80 00000000`00000000 : fffff880`03d1e000 fffff880`03d18000 fffff880`03d1d9e0 00000000`00000000 : nt!KxStartSystemThread+0x16


FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: GenuineIntel

IMAGE_NAME:  GenuineIntel




BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE_PRV


FAILURE_ID_HASH_STRING:  km:x64_0x124_genuineintel_processor_mae_prv

FAILURE_ID_HASH:  {435e2195-e498-1e77-0526-f8d7450275e5}

Followup: MachineOwner

And here is the output of !errrec fffffa802d3f77c8

7: kd> !errrec fffffa802d3f77c8
Common Platform Error Record @ fffffa802d3f77c8
Record Id     : 01d22bf56b81ac86
Severity      : Fatal (1)
Length        : 864
Creator       : Microsoft
Notify Type   : Machine Check Exception
Timestamp     : 10/21/2016 23:47:24 (UTC)
Flags         : 0x00000002 PreviousError

Section 0     : Processor Generic
Descriptor    @ fffffa802d3f7848
Section       @ fffffa802d3f7920
Offset        : 344
Length        : 192
Flags         : 0x00000001 Primary
Severity      : Fatal

Proc. Type    : x86/x64
Instr. Set    : x64
Error Type    : Micro-Architectural Error
Flags         : 0x00
CPU Version   : 0x00000000000206c0
Processor ID  : 0x0000000000000000

Section 1     : x86/x64 Processor Specific
Descriptor    @ fffffa802d3f7890
Section       @ fffffa802d3f79e0
Offset        : 536
Length        : 64
Flags         : 0x00000000
Severity      : Fatal

Local APIC Id : 0x0000000000000000
CPU Id        : c0 06 02 00 00 08 20 00 - ff e3 9e 02 ff fb eb bf
                00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
                00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

Section 2     : x86/x64 MCA
Descriptor    @ fffffa802d3f78d8
Section       @ fffffa802d3f7a20
Offset        : 600
Length        : 264
Flags         : 0x00000000
Severity      : Fatal

Error         : Unknown (Proc 0 Bank 2)
  Status      : 0xb200000000010005

This is a whitebox machine built several years ago (with parts upgraded over time to stay current). Periodically I make sure it still passes all the stress tests I can throw at it (Prime95, Memtest86, etc). I tried some brief retests with no failures, and am going to rerun full cycles overnight.

I thought the freezes originally began after I installed several pieces of software (possibly including drivers) a year or two ago, but didn't have time to investigate or troubleshoot at the time. I can't remember which software it would have been or exactly when (and to be honest, that could be unrelated or a different set of BSOD's already solved). I did go through a while back and cull software / drivers, particularly anything that might have looked suspect or appeared in other, older BSOD's (e.g. stuff like cbfs5.sys).

I've applied the most recent BIOS updates, and the latest drivers that work properly for me. (Some of the hardware is old, and in rare cases I found the newest drivers cause other problems). Most Windows updates are installed (there might be some in the last couple months that haven't been applied yet - since it's a fairly critical workstation, I take a very controlled approach to updates, creating a full backup image beforehand and doing a set of regression tests after each update cycle. As a result I'm slow to update, but generally this machine is more stable and predictable than others I maintain which are set to auto-update. That's one reason I'm putting off Win 10 for now).

Temperatures all seem reasonable.

My system is configured to write Kernel memory dumps, but for reasons unknown to me one isn't being written when this issue occurs (it occurred earlier today but my MEMORY.DMP at that path has a modified date of nearly a month ago).

The motherboard is an Asus P6T6 WS Revolution (X58 chipset) and the CPU is a 2.4GHz Hex Core Intel Xeon E5645. I have 48 GB of ECC RAM installed.

I don't have a ton of experiencing analyzing memory dumps, and would be grateful for any help/suggestions.

  • update the BISO/UEFI, run a CPU stresstest tool, maybe the CPU is damaged – magicandre1981 Oct 22 '16 at 6:28
  • I use Prime95 which hasn't uncovered a problem with it yet. Any other CPU stress tests you'd suggest? – rkagerer Oct 22 '16 at 21:14
  • also try a memory test tool like memtest86+. Also look for BIOS update or reflash the current BIOS: – magicandre1981 Oct 23 '16 at 6:51
  • Yes, I did all that. Prime95 (all three torture tests), Memtest86, Memtest86+; those were the first things I did. – rkagerer Oct 26 '16 at 23:26
  • have you checked for a BIOS update? – magicandre1981 Oct 27 '16 at 4:14

The fault, as hinted at in the error record, comes from the processor’s Machine-Check Architecture.

Some background from MSDN’s Ntdebugging blog: Interpreting a WHEA error for a MCA fault.

You can find all the gory details of MCA in Chapter 15 of the Intel Software Developer’s Manual, Volume 3B.

The useful information in the dump is the last line of the error record, which is the value of the associated IA32_MCi_STATUS model-specific register. That is documented in section of the Intel manual. Your value of 0xb200000000010005 breaks down as:

  • Bit 63: Register valid
  • Bit 61: Error uncorrected
  • Bit 60: Error enabled
  • Bit 57: Processor context corrupt
  • Bits 31–16: Model-specific error code 1
    (which does not appear to be publicly documented for your processor)
  • Bits 15–0: MCA error code 5
    (which according to Table 15‑8 in section 15.9.1 means Internal parity error)

I don’t know whether all that suggests your CPU, or motherboard, or some other hardware might be faulty. It seems unlikely to be a software issue, though, because software should not be able to cause an internal hardware error like this.

You might like to try changing your dump settings from “Small memory dump” to “Kernel memory dump” and waiting for the fault to happen again; perhaps the extra information in the larger dump file will give you some additional clues to what’s going on at the time of the crash.

  • Thanks; this is super helpful information! Based on this, do you think it's possible a memory issue could be causing it, or can we be fairly certain the culprit is the CPU or its supporting circuitry? My system is configured to create kernel dumps but for some reason I'm not getting them; will have to poke around to figure out why (don't worry I can do that on my own). Regarding the bounty, I'll wait a couple days just in case anyone else chimes in, but right now it looks like you'll get it. – rkagerer Oct 30 '16 at 13:43
  • I honestly can’t say where the fault is most likely to be. My gut feeling is that it shouldn’t be memory, because I’d expect a problem there to be detected and reported specifically as a memory fault rather than as a CPU fault. – Brian Nixon Oct 30 '16 at 15:09
  • Regarding kernel dumps: you need to make sure you have a paging file large enough to hold one (1 GB should be more than enough), AND that you have at least 25 GB free on the volume it’s to be saved on (or set HKLM\​SYSTEM\​CurrentControlSet\​Control\​CrashControl\​AlwaysKeepMemoryDump to DWORD:1). Check your Event Log around times of previous crashes for BugCheck event 1018 to see if your dump got deleted. Chapter 14 of Windows Internals, Part 2 goes into detail on all this. – Brian Nixon Oct 30 '16 at 15:10
  • Bounty awarded. Contact me at bitbounty@trashmail.com to arrange the bitcoin portion (note that email forwards to my real one and will expire Dec 1). – rkagerer Nov 1 '16 at 11:10
  • @rkagerer: That’s very generous of you. However, I don’t come to SU to make money. Please consider donating to one or more of GiveWell’s recommended charities, or another cause you consider similarly worthwhile, because there are a lot of people who need that money much more than I do. Thanks! – Brian Nixon Nov 1 '16 at 20:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.