Назад | Перейти на главную страницу

Stop-ошибка «0x0000009E» при сбое узла кластера в Windows Server 2012 R2

Полный дамп памяти: https://pastebin.com/spkLeVYL

Сообщение о сбое:

USER_MODE_HEALTH_MONITOR (9e)

One or more critical user mode components failed to satisfy a health check.
Hardware mechanisms such as watchdog timers can detect that basic kernel
services are not executing. However, resource starvation issues, including
memory leaks, lock contention, and scheduling priority misconfiguration,
may block critical user mode components without blocking DPCs or
draining the nonpaged pool.

Kernel components can extend watchdog timer functionality to user mode
by periodically monitoring critical applications. This bugcheck indicates
that a user mode health check failed in a manner such that graceful
shutdown is unlikely to succeed. It restores critical services by
rebooting and/or allowing application failover to other servers.

Arguments:

Arg1: ffffe00026e00780, Process that failed to satisfy a health check within the configured timeout

Arg2: 000000000000003c, Health monitoring timeout (seconds)

Arg3: 000000000000000a, WatchdogSourceClussvcIsAlive
    Cluster service sends heartbeat to netft every 500 millseconds.
    By default netft expects at least 1 heartbeat per second.
    If this watchdog was triggered that means clussvc is o not getting
    CPU to send heartbers.
Arg4: 0000000000000000

Что-то в пользовательском режиме привело к тому, что служба отказоустойчивой кластеризации перестала отвечать на запросы, поэтому проблема заключается в процессах пользовательского режима и общей отладке с зависанием. Кластеризация имеет обнаружение работоспособности между службой пользовательского режима и режимом ядра NetFT Водитель. Если пользовательский режим перестает отвечать, то ошибка кластеризации устанавливает флажок, чтобы принудительно выполнить аварийное переключение. А STOP 0x9e ожидается кластерное поведение. А stop 0x9e для netft.sys, что является преднамеренной проверкой ошибок, вызванной службой кластера из-за выявленного состояния взаимоблокировки.

Я нашел это в статье, мне было интересно, следует ли мне изменить действие восстановления HangRecoveryAction?

Это свойство управляет действием, которое необходимо выполнить, если процессы пользовательского режима перестали отвечать. Для HangRecoveryAction, на самом деле у нас есть 4 разных параметра, из которых 3 - по умолчанию.

0 = Disables the heartbeat and monitoring mechanism.
1 = Logs an event in the system log of the Event Viewer.
2 = Terminates the Cluster Service.
3 = Causes a Stop error (Bugcheck) on the cluster node.  <<– default for 2008

Сервер 2012 R2.