diff --git a/decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash.md b/decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash.md
new file mode 100644
index 0000000..5eb5c60
--- /dev/null
+++ b/decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash.md
@@ -0,0 +1,90 @@
+---
+date: 2026-05-07
+type: decision
+tags: [buzharovo, server1c, 1c, troubleshooting]
+---
+
+# Бужарово 1С сервер — rmngr-loop после грязного ребута: рецепт
+
+## Контекст
+
+07.05.2026 утром локальные пользователи в Бужарово начали жаловаться на резкое замедление 1С. NetBird и удалённый доступ ни при чём — тормозило в локальной сети офиса.
+
+Сервер: `Server1C` (Win 2012 R2, 100.70.75.103 / 185.13.47.2), 1С 8.3.27.1606, MSSQL.
+
+## Что нашли
+
+Сегодня в **09:05 сервер ушёл в crash**:
+- `System / Kernel-Power Event 41` (Critical): "rebooted without cleanly shutting down — system stopped responding, crashed, or lost power"
+- `System / EventLog 6008`: "previous shutdown was unexpected"
+
+После загрузки:
+- `rmngr.exe` (менеджер кластера 1С) держит **~1.7 ядра постоянно** в idle (норма <2% одного ядра).
+- `rphost`, `sqlservr`, диски (avg sec/write 1.6 ms, queue 0.03), память (5/64 GB) — **в норме**.
+- `rac.exe localhost:1540 cluster list` → "ошибка соединения с сервером", exit -1 — **admin-канал rmngr повис**, кластером невозможно управлять извне.
+- `netbird.exe` параллельно жжёт 1.4 ядра — побочный reconnect-loop после crash, после ребута сам успокоился.
+
+## Что не помогло
+
+**Полный ребут сервера** (через `Restart-Computer`) — НЕ решает проблему. На свежезагруженном сервере с uptime=37 секунд rmngr опять на 178% одного ядра. То есть проблема воспроизводится при каждом первом запуске агента после crash.
+
+## Что помогло
+
+```powershell
+Restart-Service -Name '1C:Enterprise 8.3 Server Agent (x86-64)' -Force
+```
+
+После рестарта службы (не сервера!):
+
+| Процесс | До рестарта | После рестарта |
+|---|---|---|
+| rmngr | 178% ядра | 3% ядра |
+| rphost | 19% | 1% |
+| ragent | 0% | 1% |
+
+Все клиенты в этот момент вылетают — нужно предупредить за 2-3 минуты. Перезаход штатный.
+
+## Побочный эффект
+
+После рестарта остался орфан-процесс старого `ragent` от прошлого запуска (не слушает 1540, висит в памяти). Можно безопасно прибить:
+
+```powershell
+Get-Process ragent | Where-Object { $_.Id -ne (Get-NetTCPConnection -LocalPort 1540).OwningProcess } | Stop-Process -Force
+```
+
+## Корневая причина — открыта
+
+Почему `rmngr` зацикливается после первого запуска ragent — точно не выяснено. Гипотезы:
+1. Повреждённый кэш кластера `C:\Program Files\1cv8\srvinfo\reg_*\` после crash.
+2. Регресс в 8.3.27.1606 при восстановлении сеансов.
+3. Disabled-служба `RagentServer_8327` (старый дубликат) что-то мешает в реестре при первом старте.
+
+Если повторится — смотреть `C:\Program Files\1cv8\srvinfo\reg_*\1Cv8FTLog\` и `1Cv8Log` на ошибки.
+
+## Что сделать долгосрочно
+
+В кластере 1С сейчас **один rphost на всех локальных пользователей** — бутылочное горлышко. Через консоль администрирования сервера 1С увеличить количество рабочих процессов: 1 rphost на 8-12 сеансов. Это отдельная задача, не на горячую.
+
+## Команды диагностики (для повтора)
+
+WinRM-сессия с Mac:
+```python
+import winrm
+s = winrm.Session('http://100.70.75.103:5985/wsman',
+                  auth=('dttb','1qaz!QAZ'),
+                  transport='basic')
+```
+
+Дельта CPU за 5 сек по процессам:
+```powershell
+$names='rmngr','rphost','netbird','sqlservr','ragent'
+$first=@{}; $last=@{}
+Get-Process | ?{$names -contains $_.Name} | %{ $first[$_.Name]=$_.CPU }
+Start-Sleep 5
+Get-Process | ?{$names -contains $_.Name} | %{ $last[$_.Name]=$_.CPU }
+foreach($n in $names){ "$n delta=$($last[$n]-$first[$n])s" }
+```
+
+Если у rmngr дельта >50 за 5 секунд — диагноз "rmngr-loop" подтверждён, делать рестарт службы.
+
+См. также [[projects/dttb/server1c]].
diff --git a/projects/dttb/server1c.md b/projects/dttb/server1c.md
index f9d5661..829ee9d 100644
--- a/projects/dttb/server1c.md
+++ b/projects/dttb/server1c.md
@@ -28,3 +28,22 @@ tags: [dttb]
 - Рабочая: `1C:Enterprise 8.3 Server Agent (x86-64)` (8.3.27.1606)
 
 **Решение:** отключены лишние службы (Disabled), оставлена только x86-64.
+
+### Решено: rmngr-loop после грязного ребута (2026-05-07)
+**Симптомы:** утром локальные пользователи в Бужарово жалуются на резко тормозящую 1С. Удалённое подключение к 1С через NetBird ни при чём — проблема видна и в локальной сети.
+
+**Диагноз:**
+- Сервер ушёл в crash в 09:05 (Event 41 Kernel-Power: rebooted without cleanly shutting down + EventLog 6008: previous shutdown was unexpected).
+- После загрузки `rmngr.exe` (менеджер кластера 1С) держит ~1.7 ядра постоянно вместо штатных <2% в idle. `rphost`, `sqlservr`, диски, сеть — в норме.
+- `rac.exe localhost:1540 cluster list` отваливается с "ошибка соединения с сервером" — admin-канал rmngr повис, кластер не отвечает на управление.
+- `netbird.exe` параллельно крутит 1.4 ядра — это reconnect-loop как побочка crash, после ребута сам приходит в норму.
+
+**Рецепт:**
+1. Замерить дельту CPU через `Get-Process | %{$_.CPU}` за 5 секунд — если у `rmngr` >50% одного ядра в idle, диагноз подтверждён.
+2. **Полный ребут сервера НЕ помогает** — после загрузки rmngr опять начинает жрать CPU. На свежезагруженном сервере uptime=0.6 min: rmngr уже на 178% ядра.
+3. **Помогает рестарт службы:** `Restart-Service -Name '1C:Enterprise 8.3 Server Agent (x86-64)' -Force`. После рестарта rmngr возвращается к 3% ядра. Все активные сеансы пользователей вылетят — нужно их предупредить.
+4. После рестарта может остаться орфан-процесс `ragent` от прошлого старта (не слушает 1540, висит). Прибить вручную: `Stop-Process -Id <pid> -Force`.
+
+**Why:** причина рута rmngr-loop неясна — возможно повреждение кэша `srvinfo`, регресс 8.3.27.1606, или Disabled-служба `RagentServer_8327` мешает первому запуску ragent. Если повторится — смотреть `C:\Program Files\1cv8\srvinfo\reg_*\1Cv8FTLog\` на ошибки.
+
+**Долгосрочно:** настроить несколько `rphost` в кластере (по одному на 8-12 сеансов) — сейчас один rphost на всех локальных юзеров = бутылочное горлышко.