none
Перегружается компьютер RRS feed

  • Вопрос

  • Привет всем.

    Сначала я с этим своим вопросом обратился сюда. Но там меня перенаправили сюда.

    Сама проблема.

    Ночью, в процессе компиляции проекта (VS2012, C++), перегрузился компьютер (Win10 Pro Rus x64, 6950X/128GB). Это уже не первый раз, но предыдущий такой случай был относительно давно и тоже при запуске компилятора (с ключиком /MP - то есть, компиляция идет параллельно в 20-ти процессах).

    Сборка проекта идет около минуты. Но таких запусков выполняется несколько сотен (разные компиляторы (VS2010-2017), конфигурации и платформы).

    Был создан дамп памяти. Вот он и полные сведения о системе:

    http://dropmefiles.com/Pruiz (ссылка действительна 2 недели)

    Сам компьютер относительно новый (меньше года). Не разогнан (в биосе все настройки Auto). Все железо свежее. Windows обновлен до упора. Тесты памяти (и не только) гонял - все в норме.

    Кто виноват и что делать? :)


    • Изменено Kovalenko_Dmitry 19 сентября 2017 г. 6:05 поправил ссылку на MS Community Forum
    18 сентября 2017 г. 17:40

Ответы

  • Данная ошибка означает, что процессор завис при выполнении прерывания с уровнем выше Clock Timer (13 в x64), т.е.:

    Interprocessor interrupt, Power failure, или High level interrupt

    Соответственно это может быть как аппаратная, так и программная проблема. См. например эту статью о методах исследования (если бы вы смогли повторить что-то из этого, было бы кстати). Для начала хотя бы получить несколько дампов и посмотреть, что между ними общего. 

    • Помечено в качестве ответа Kovalenko_Dmitry 19 сентября 2017 г. 9:19
    19 сентября 2017 г. 9:01
  • Сам компьютер относительно новый (меньше года). Не разогнан (в биосе все настройки Auto). Все железо свежее. Windows обновлен до упора. Тесты памяти (и не только) гонял - все в норме.

    Кто виноват и что делать? :)


    Проблема была в битой оперативной памяти (сумел воспроизвести). После изъятия битых планок (пару месяцев назад) вроде все стало работать без проблем.
    • Помечено в качестве ответа Kovalenko_Dmitry 20 февраля 2018 г. 5:45
    20 февраля 2018 г. 5:45
  • С выключенным HT компьютер начал работать стабильно.

    Больше синего экрана не было.

    С момента последнего включения прошло больше 77 дней. 

    Полет нормальный.

    • Помечено в качестве ответа Kovalenko_Dmitry 28 июля 2018 г. 6:15
    28 июля 2018 г. 6:15
  • Обновлю топик :)

    В мае 2019 поставил новый биос к матери - 1903.

    Пока полет нормальный.

    Похоже починили HT.

    • Помечено в качестве ответа Kovalenko_Dmitry 29 июля 2019 г. 4:28
    29 июля 2019 г. 4:28

Все ответы

  • Дополнение.

    В системном журнале Windows про этот сбой есть такая запись:

    Предыдущее завершение работы системы в 23:34:20 на ‎17.‎09.‎2017 было неожиданным.

    Акронис (True Image) запускается в час ночи. То есть он в этот момент не работал.

    Думаю, в этот момент система грузилась только компиляторами студии.

    ---Блок питания у компьютера - 1200 ватт. Максимальная нагрузка, которую я наблюдал при компиляции - ~200 ватт).

    Есть бесперебойник - APC Smart 1500. Батарейкам около полугода.

    Так что в плане питания - все хорошо.

    18 сентября 2017 г. 17:58
  • "что делать"

    анализ дампов через WinDbg. Выявлять какой модуль в каждом случае падает и с какой ошибкой.  

    19 сентября 2017 г. 5:43
  • "что делать"

    анализ дампов через WinDbg. Выявлять какой модуль в каждом случае падает и с какой ошибкой.  

    Вот, что по поводу этого дампа говорит WinDBG:

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


    Loading Dump File [D:\Users\Dima\091817-17109-01.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: srv*
    Executable search path is: 
    Windows 10 Kernel Version 15063 MP (20 procs) Free x64
    Product: WinNt, suite: TerminalServer SingleUserTS
    Machine Name:
    Kernel base = 0xfffff802`9ea94000 PsLoadedModuleList = 0xfffff802`9ede05c0
    Debug session time: Mon Sep 18 00:13:13.277 2017 (UTC + 3:00)
    System Uptime: 1 days 14:01:43.359
    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
    Loading unloaded module list
    ..........
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 101, {a, 0, ffff9001803c0180, a}

    Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

    Followup:     MachineOwner
    ---------

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

    CLOCK_WATCHDOG_TIMEOUT (101)
    An expected clock interrupt was not received on a secondary processor in an
    MP system within the allocated interval. This indicates that the specified
    processor is hung and not processing interrupts.
    Arguments:
    Arg1: 000000000000000a, Clock interrupt time out interval in nominal clock ticks.
    Arg2: 0000000000000000, 0.
    Arg3: ffff9001803c0180, The PRCB address of the hung processor.
    Arg4: 000000000000000a, The index of the hung processor.

    Debugging Details:
    ------------------


    DUMP_CLASS: 1

    DUMP_QUALIFIER: 400

    BUILD_VERSION_STRING:  10.0.15063.608 (WinBuild.160101.0800)

    DUMP_TYPE:  2

    DUMP_FILE_ATTRIBUTES: 0x8
      Kernel Generated Triage Dump

    BUGCHECK_P1: a

    BUGCHECK_P2: 0

    BUGCHECK_P3: ffff9001803c0180

    BUGCHECK_P4: a

    BUGCHECK_STR:  CLOCK_WATCHDOG_TIMEOUT_14_PROC

    CPU_COUNT: 14

    CPU_MHZ: bb6

    CPU_VENDOR:  GenuineIntel

    CPU_FAMILY: 6

    CPU_MODEL: 4f

    CPU_STEPPING: 1

    CPU_MICROCODE: 6,4f,1,0 (F,M,S,R)  SIG: B00001C'00000000 (cache) B00001C'00000000 (init)

    CUSTOMER_CRASH_COUNT:  1

    PROCESS_NAME:  cl.exe

    CURRENT_IRQL:  d

    ANALYSIS_SESSION_HOST:  HOME4

    ANALYSIS_SESSION_TIME:  09-18-2017 07:19:01.0231

    ANALYSIS_VERSION: 10.0.14321.1024 amd64fre

    STACK_TEXT:  
    ffff9001`7fbbcbc8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx


    STACK_COMMAND:  kb

    THREAD_SHA1_HASH_MOD_FUNC:  81a83ae0317433a47fcc36991983df3b6e638b71

    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  6e16edd8c7dd677734fdbcd2397a2e35e9fae964

    THREAD_SHA1_HASH_MOD:  76cd06466d098060a9eb26e5fd2a25cb1f3fe0a3

    SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: Unknown_Module

    IMAGE_NAME:  Unknown_Image

    DEBUG_FLR_IMAGE_TIMESTAMP:  0

    BUCKET_ID:  ZEROED_STACK_CLOCK_WATCHDOG_TIMEOUT_14_PROC

    DEFAULT_BUCKET_ID:  ZEROED_STACK_CLOCK_WATCHDOG_TIMEOUT_14_PROC

    PRIMARY_PROBLEM_CLASS:  ZEROED_STACK

    FAILURE_BUCKET_ID:  ZEROED_STACK_CLOCK_WATCHDOG_TIMEOUT_14_PROC

    TARGET_TIME:  2017-09-17T21:13:13.000Z

    OSBUILD:  15063

    OSSERVICEPACK:  608

    SERVICEPACK_NUMBER: 0

    OS_REVISION: 0

    SUITE_MASK:  272

    PRODUCT_TYPE:  1

    OSPLATFORM_TYPE:  x64

    OSNAME:  Windows 10

    OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

    OS_LOCALE:  

    USER_LCID:  0

    OSBUILD_TIMESTAMP:  2017-09-05 07:09:34

    BUILDDATESTAMP_STR:  160101.0800

    BUILDLAB_STR:  WinBuild

    BUILDOSVER_STR:  10.0.15063.608

    ANALYSIS_SESSION_ELAPSED_TIME: 8a9

    ANALYSIS_SOURCE:  KM

    FAILURE_ID_HASH_STRING:  km:zeroed_stack_clock_watchdog_timeout_14_proc

    FAILURE_ID_HASH:  {64798f87-9084-fdbb-e6b8-480dd780dfd9}

    Followup:     MachineOwner


    19 сентября 2017 г. 6:07
  • Увы, это не какой либо модуль или драйвер. У вас скорее всего проблемы с железом которое зависает до срабатывания сторожевого таймера. Скорее всего проблема проявляется при нагрузке.

    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x101---clock-watchdog-timeout

    Что можно сделать:

    - Обновление BIOS

    - Сброс настроек BIOS в самые безопасные.

    - Заменить процессор/матплату. Если железо свежее то ремонт по гарантии.



    This posting is provided "AS IS" with no warranties, and confers no rights.

    19 сентября 2017 г. 7:16
    Модератор
  • Биос матери обновлен до последней версии.

    Недавно обновлял прошивку у SSD и поставил новый Samsung Magician (5.1).

    Насчет замены процессора и матплаты - не уверен, что это поможет. У уже меня была схожая проблема в 2008-2010 годах на компьютере с Vista/Q6600. Там очень долго все друг к другу притиралось. Но потом до 2016 работало как часы :)

    Когда серьезные проблема с матерью - компьютер просто вырубается. Такое у меня тоже было (с замученным ноутбуком). А здесь вроде как цивилизованный сбой с созданием дампа памяти.

    Тут вот одна мысль появилась. Под подозрением CPUID HWMonitor. Он (точнее его драйвер) как-то раз упоминался в крашдампе и я перестал им пользоваться. А недавно снова стал его юзать. И он, скорее всего, был запущен, когда шла компиляция. Надо его вообще с компьютера удалить.

    Из подобных вещей установлен еще Corsair Link (настраивал СВО процессора). Будет следующим, если компьютер снова перегрузится.


    19 сентября 2017 г. 8:16
  • Ну попытка не пытка, конечно следует все ненужное убрать. Но ядра от софта обычно не виснут. 

    Может так же быть что то в этом роде:

    https://www.theregister.co.uk/2017/06/25/intel_skylake_kaby_lake_hyperthreading/


    This posting is provided "AS IS" with no warranties, and confers no rights.

    19 сентября 2017 г. 8:24
    Модератор
  • Debian's advisory notes that Intel has documented the bug and corrected the cockup in a microcode update for Core 6th generation, Core 7thgeneration, Xeon v5 and v6, and Core 6th generation X series.

    Это типа, что получается - мой 6950X тоже попал под раздачу? :(

    Я про это слышал, но не вникал.

    Спасибо, буду знать.

    19 сентября 2017 г. 8:50
  • Данная ошибка означает, что процессор завис при выполнении прерывания с уровнем выше Clock Timer (13 в x64), т.е.:

    Interprocessor interrupt, Power failure, или High level interrupt

    Соответственно это может быть как аппаратная, так и программная проблема. См. например эту статью о методах исследования (если бы вы смогли повторить что-то из этого, было бы кстати). Для начала хотя бы получить несколько дампов и посмотреть, что между ними общего. 

    • Помечено в качестве ответа Kovalenko_Dmitry 19 сентября 2017 г. 9:19
    19 сентября 2017 г. 9:01
  • Данная ошибка означает, что процессор завис при выполнении прерывания с уровнем выше Clock Timer (13 в x64), т.е.:

    Interprocessor interrupt, Power failure, или High level interrupt

    Соответственно это может быть как аппаратная, так и программная проблема. См. например эту статью о методах исследования (если бы вы смогли повторить что-то из этого, было бы кстати). Для начала хотя бы получить несколько дампов и посмотреть, что между ними общего. 

    Я видел эту статью. Насчет повторить - хорошая шутка :)

    Насчет дампов - жаль, я стер предыдущие дампы (очистку диска запускал).

    Вообщем, что делать - ясно. Ждем следующего сбоя.

    19 сентября 2017 г. 9:19
  • "Насчет повторить - хорошая шутка"

    Не все (понятно что на 10 ядрах задолбаетесь), хотя бы в части выполнения команды !thread на проблемный процессор - 10-й в вашем случае, чтобы узнать какой поток он выполнял в момент зависания. 

    19 сентября 2017 г. 9:35
  • Сам компьютер относительно новый (меньше года). Не разогнан (в биосе все настройки Auto). Все железо свежее. Windows обновлен до упора. Тесты памяти (и не только) гонял - все в норме.

    Кто виноват и что делать? :)


    Проблема была в битой оперативной памяти (сумел воспроизвести). После изъятия битых планок (пару месяцев назад) вроде все стало работать без проблем.
    • Помечено в качестве ответа Kovalenko_Dmitry 20 февраля 2018 г. 5:45
    20 февраля 2018 г. 5:45
  • Возобновлю эту тему.

    Компьютер снова перегрузился в процессе компиляции (VS2010). Правда, теперь в дампе фигурирует не cl.exe, а mspdbsrv.exe.

    Система продержалась 34 дня (постоянная нагрузка, был один hybernate)  - я уже начал считать, что проблем со стабильностью больше нет :)

    Память вроде уже отутюжена тестами вдоль и поперек.

    Решил отключить HT.

    --------- Сведения о последнем падении:

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


    Loading Dump File [D:\Users\Dima\040418-23406-01.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: srv*
    Executable search path is: 
    Windows 10 Kernel Version 16299 MP (20 procs) Free x64
    Product: WinNt, suite: TerminalServer SingleUserTS
    Machine Name:
    Kernel base = 0xfffff801`e000e000 PsLoadedModuleList = 0xfffff801`e0375110
    Debug session time: Wed Apr  4 15:34:30.738 2018 (UTC + 3:00)
    System Uptime: 34 days 4:10:32.578
    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
    Loading unloaded module list
    ..................................................
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 101, {a, 0, ffff858011080180, 13}

    Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

    Followup:     MachineOwner
    ---------

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

    CLOCK_WATCHDOG_TIMEOUT (101)
    An expected clock interrupt was not received on a secondary processor in an
    MP system within the allocated interval. This indicates that the specified
    processor is hung and not processing interrupts.
    Arguments:
    Arg1: 000000000000000a, Clock interrupt time out interval in nominal clock ticks.
    Arg2: 0000000000000000, 0.
    Arg3: ffff858011080180, The PRCB address of the hung processor.
    Arg4: 0000000000000013, The index of the hung processor.

    Debugging Details:
    ------------------


    DUMP_CLASS: 1

    DUMP_QUALIFIER: 400

    BUILD_VERSION_STRING:  10.0.16299.248 (WinBuild.160101.0800)

    DUMP_TYPE:  2

    DUMP_FILE_ATTRIBUTES: 0x8
      Kernel Generated Triage Dump

    BUGCHECK_P1: a

    BUGCHECK_P2: 0

    BUGCHECK_P3: ffff858011080180

    BUGCHECK_P4: 13

    BUGCHECK_STR:  CLOCK_WATCHDOG_TIMEOUT_14_PROC

    CPU_COUNT: 14

    CPU_MHZ: bb8

    CPU_VENDOR:  GenuineIntel

    CPU_FAMILY: 6

    CPU_MODEL: 4f

    CPU_STEPPING: 1

    CPU_MICROCODE: 6,4f,1,0 (F,M,S,R)  SIG: B00001C'00000000 (cache) B00001C'00000000 (init)

    CUSTOMER_CRASH_COUNT:  1

    PROCESS_NAME:  mspdbsrv.exe

    CURRENT_IRQL:  d

    ANALYSIS_SESSION_HOST:  HOME4

    ANALYSIS_SESSION_TIME:  04-07-2018 10:12:09.0152

    ANALYSIS_VERSION: 10.0.15063.468 amd64fre

    STACK_TEXT:  
    ffff8580`100b9bc8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx


    STACK_COMMAND:  kb

    THREAD_SHA1_HASH_MOD_FUNC:  81a83ae0317433a47fcc36991983df3b6e638b71

    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  6e16edd8c7dd677734fdbcd2397a2e35e9fae964

    THREAD_SHA1_HASH_MOD:  76cd06466d098060a9eb26e5fd2a25cb1f3fe0a3

    SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: Unknown_Module

    IMAGE_NAME:  Unknown_Image

    DEBUG_FLR_IMAGE_TIMESTAMP:  0

    BUCKET_ID:  ZEROED_STACK_CLOCK_WATCHDOG_TIMEOUT_14_PROC

    DEFAULT_BUCKET_ID:  ZEROED_STACK_CLOCK_WATCHDOG_TIMEOUT_14_PROC

    PRIMARY_PROBLEM_CLASS:  ZEROED_STACK

    FAILURE_BUCKET_ID:  ZEROED_STACK_CLOCK_WATCHDOG_TIMEOUT_14_PROC

    TARGET_TIME:  2018-04-04T12:34:30.000Z

    OSBUILD:  16299

    OSSERVICEPACK:  248

    SERVICEPACK_NUMBER: 0

    OS_REVISION: 0

    SUITE_MASK:  272

    PRODUCT_TYPE:  1

    OSPLATFORM_TYPE:  x64

    OSNAME:  Windows 10

    OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

    OS_LOCALE:  

    USER_LCID:  0

    OSBUILD_TIMESTAMP:  2018-02-10 07:34:33

    BUILDDATESTAMP_STR:  160101.0800

    BUILDLAB_STR:  WinBuild

    BUILDOSVER_STR:  10.0.16299.248

    ANALYSIS_SESSION_ELAPSED_TIME:  581

    ANALYSIS_SOURCE:  KM

    FAILURE_ID_HASH_STRING:  km:zeroed_stack_clock_watchdog_timeout_14_proc

    FAILURE_ID_HASH:  {64798f87-9084-fdbb-e6b8-480dd780dfd9}

    Followup:     MachineOwner
    ---------

    7 апреля 2018 г. 7:17
  • С выключенным HT компьютер начал работать стабильно.

    Больше синего экрана не было.

    С момента последнего включения прошло больше 77 дней. 

    Полет нормальный.

    • Помечено в качестве ответа Kovalenko_Dmitry 28 июля 2018 г. 6:15
    28 июля 2018 г. 6:15
  • Обновлю топик :)

    В мае 2019 поставил новый биос к матери - 1903.

    Пока полет нормальный.

    Похоже починили HT.

    • Помечено в качестве ответа Kovalenko_Dmitry 29 июля 2019 г. 4:28
    29 июля 2019 г. 4:28