Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

129 Windows Server, AD и Роли

Event ID 129: Сброс устройства RAID-порта (Storport Reset)

Обновлено: 15.08.2026 · Официальная документация ↗

Архитектура подсистемы хранения и симптомы сброса

Событие 129 логируется источниками драйверов мини-портов хранилища (например, storahci, megasas, LSI_SAS, HpCisss3) в журнале System. Сообщение: «Был произведен сброс устройства \Device\RaidPort0 (Reset to device was issued)». Симптомы: жесткое зависание сервера (Hardware Freeze) на 1-2 минуты. В этот момент мышь может двигаться, но ни одна программа или окно не отвечает. После аппаратного сброса порта (Reset) система "отмирает", но базы данных (SQL) могут потерять подключения клиентов (Drop Connections).

Механизм возникновения (Storport)

Драйвер хранилища Windows (Storport.sys) отправляет блок команд (SRB) физическому HBA-адаптеру или RAID-контроллеру. Если контроллер не возвращает статус выполнения в течение таймаута (встроенный Watchdog), Storport считает контроллер "зависшим" и отправляет ему команду жесткого аппаратного сброса (LUN Reset или Bus Reset), чтобы вернуть к жизни. Это генерирует событие 129.

Пошаговое дерево решений (СХД и Микрокоды)

Сценарий 1: Перегрузка массива (I/O Bottleneck)

Дисковая подсистема (особенно на шпиндельных HDD дисках в RAID 5/6) просто не справляется с запрошенными IOPS. Ядро заваливает контроллер командами, а механика дисков не успевает их писать.

  • Когда происходит: Во время ночного резервного копирования (Veeam) в связке с тяжелыми отчетами SQL/1С или антивирусным сканированием.
  • Решение: Распараллелить задачи по времени. Рассмотреть переход кэша баз данных (tempdb) на NVMe / SSD накопители.

Сценарий 2: Ошибки микрокода (Firmware Bugs)

Баги в микрокоде RAID-контроллеров (особенно на старых серверах HPE SmartArray или Dell PERC) или баги кэша самих SSD (Intel/Samsung). Контроллер "давится" специфической командой TRIM или Flush.

  • Решение: Немедленно обновите Firmware (прошивку) дисков и HBA-адаптеров до последних версий из каталога вендора. Обновите драйвер .sys в самой Windows.

Сценарий 3: Настройки электропитания (ASPM / PCIe)

В целях "экологии" материнские платы отключают питание шины PCIe (Link State Power Management) при простое. Когда приходит резкий запрос I/O, контроллер "засыпает" и не успевает проснуться вовремя.

  1. Откройте powercfg.cpl (Электропитание).
  2. Выберите схему Высокая производительность (High Performance).
  3. В дополнительных параметрах отключите управление питанием состояния связи PCI Express (Off).

Типовые ошибки администраторов

  • Отказ от диагностики сети SAN: Если событие 129 указывает на iSCSI (источник iScsiPrt), вы обязаны проверить сеть. Потеря Jumbo Frames (MTU 9000), перегрузка портов свитча (Flow Control) или отсутствие MPIO — главные причины iSCSI-таймаутов.
Серверы "замерзают" под нагрузкой, парализуя работу 1С и SQL?
Таймауты аппаратных контроллеров (Storage Reset) — предвестники разрушения данных и BSOD 0x7A. Делегируйте обслуживание серверов профессионалам: мы профилируем дисковую нагрузку, обновим Firmware, настроим iSCSI/MPIO сети и избавим инфраструктуру от 'фризов'.
💡 Практика специалистов: При сбоях RAID-контроллеров (129) на локальных серверах часто виновата умирающая батарейка кэша (BBU). Контроллер понимает, что батарея мертва, отключает кэширование записи (Write-Back) и переходит в режим сквозной записи (Write-Through). Скорость записи падает в 5-10 раз, I/O забивается, и Windows начинает генерировать таймауты 129.

Частые вопросы (FAQ)

Поможет ли изменение параметров реестра TimeoutValue?

Увеличение таймаута (HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue) до 60 секунд лишь отсрочит момент сброса. Сервер будет висеть не 30 секунд, а 60 секунд. Это полезно для обхода таймаутов MPIO в кластерах (Failover), но физическую проблему 'тормозов' СХД не решает.

Приводит ли 129 к потере данных?

Да. Если RAID-контроллер не имел батарейки (BBU/FBWC) или команда не успела попасть в энергонезависимый кэш до сброса (Reset), транзакция базы данных будет повреждена (Torn Write).

Почему 129 сопровождается событием 153?

Это цепная реакция. Контроллер завис (129), из-за чего логический диск не получил ответа и попытался повторить команду ввода-вывода (153 Disk I/O Retried).

Возникает ли 129 из-за перегрева?

Редко, но возможно. При перегреве RAID-контроллера (например, отказал кулер корпуса) он начинает пропускать такты (Throttling) или зависает аппаратно.

Почему событие 129 сыпется на виртуальных машинах в облаке?

В ВМ (Hyper-V / Azure / AWS) событие 129 от источника 'storvsc' означает, что ФИЗИЧЕСКИЙ хост гипервизора перегружен I/O ('Noisy Neighbors') и не может вовремя отдать дисковые квоты вашей виртуальной машине.

Полезные материалы
Рекомендуем