1

У меня есть Windows 7 64-битная машина, которая зависает примерно раз в месяц. Все последние пять мини-дампов обозначают "Вызванный адресом" ntoskrnl.exe+4b314c, и я пытаюсь выяснить, кто владеет (или вызывает неудачные вызовы) кодом по этому адресу.

Вот это !analyze -v самого последнего мини-дампа:

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                                    *
*                                                                             *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
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.
Arguments:
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

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

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

STACK_TEXT:  
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


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: GenuineIntel

IMAGE_NAME:  GenuineIntel

DEBUG_FLR_IMAGE_TIMESTAMP:  0

IMAGE_VERSION:  

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE_PRV

BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE_PRV

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:x64_0x124_genuineintel_processor_mae_prv

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

Followup: MachineOwner

А вот и вывод !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

Это «белый ящик», созданный несколько лет назад (со временем детали обновляются, чтобы оставаться в курсе). Периодически я проверяю, проходит ли он все стресс-тесты (Prime95, Memtest86 и т.д.). Я попробовал несколько коротких повторных тестов без сбоев, и я собираюсь повторить полный цикл за одну ночь.

Я думал, что замораживания первоначально начались после того, как я установил несколько программ (возможно, включая драйверы) год или два назад, но у меня не было времени для расследования или устранения неполадок в то время. Я не могу вспомнить, какое программное обеспечение это было или когда именно (и, честно говоря, это могло быть не связано или другой набор BSOD уже решен). Некоторое время назад я проверял программное обеспечение и драйверы, особенно все, что могло показаться подозрительным или появляться в других, более старых BSOD (например, например, cbfs5.sys).

Я применил самые последние обновления BIOS и последние драйверы, которые работают для меня должным образом. (Часть оборудования устарела, и в редких случаях я обнаружил, что новейшие драйверы вызывают другие проблемы). Большинство обновлений Windows установлены (возможно, некоторые из них за последние пару месяцев еще не были применены - поскольку это довольно важная рабочая станция, я очень контролирую подход к обновлениям, заранее создавая полный резервный образ и выполняя набор регрессионные тесты после каждого цикла обновления. В результате я медленно обновляюсь, но, как правило, эта машина более стабильна и предсказуема, чем другие, поддерживаемые мной, которые настроены на автоматическое обновление. Это одна из причин, по которой я пока откладываю Win 10).

Температура кажется разумной.

Моя система настроена на запись дампов памяти ядра, но по неизвестным мне причинам не пишется, когда эта проблема возникает (сегодня это произошло раньше, но мой MEMORY.DMP по этому пути имеет дату изменения почти месяц назад).

Материнская плата представляет собой Asus P6T6 WS Revolution (чипсет X58), а процессор представляет собой шестнадцатеричное ядро 2,4 ГГц Intel Xeon E5645. У меня установлено 48 ГБ оперативной памяти ECC.

У меня нет тонны опыта анализа дампов памяти, и был бы благодарен за любую помощь / предложения.

1 ответ1

1

Отказ, на который намекают записи об ошибках, происходит из архитектуры Machine-Check процессора.

Немного предыстории из блога MSDN Ntdebugging : Интерпретация ошибки WHEA для ошибки MCA.

Вы можете найти все подробности MCA в главе 15 Руководства разработчика программного обеспечения Intel , том 3B.

Полезная информация в дампе - это последняя строка записи об ошибке, которая является значением соответствующего регистра для конкретной модели IA32_MCi_STATUS. Это описано в разделе 15.3.2.2 руководства Intel. Ваше значение 0xb200000000010005 на:

  • Бит 63: регистр действителен
  • Бит 61: ошибка не исправлена
  • Бит 60: ошибка включена
  • Бит 57: поврежден контекст процессора
  • Биты 31–16: код ошибки для конкретной модели 1
    (который не является публично документированным для вашего процессора)
  • Биты 15–0: код ошибки MCA 5
    (что в соответствии с таблицей 15-8 в разделе 15.9.1 означает внутреннюю ошибку четности)

Я не знаю, может ли все, что предполагает ваш процессор, материнскую плату или другое оборудование, быть неисправным. Тем не менее, похоже, что это проблема программного обеспечения, потому что программное обеспечение не должно вызывать внутреннюю аппаратную ошибку, подобную этой.

Возможно, вы захотите изменить настройки дампа с «Малый дамп памяти» на «Дамп памяти ядра» и подождать, пока ошибка снова возникнет; возможно, дополнительная информация в большом файле дампа даст вам некоторые дополнительные подсказки о том, что происходит во время сбоя.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .