# Службы Xiaomi: MiService и MiDeviceService

Что за службы Xiaomi остаются в системе после удаления PC Manager, что они делают, чем
мешают XiControl и как их безопасно отключить. Нужен для поддержки («у меня сама прыгает
яркость») и для задачи XIC-87 (статус службы и кнопка отключения на вкладке «Драйверы»).

Разбор снят 2026-10-11 на Xiaomi Book Pro 14 (TM2424), MiService 4.1.1.564. Источники: логи
службы в `C:\ProgramData\MI\…`, состав каталога установки, документы форка
[Xiaomi-PC-Manager-Extended](https://github.com/Alex-Irae/Xiaomi-PC-Manager-Extended)
(`DAILY_RESIDENT.md`, `tools/oem-service.ps1`) и замер на железе (§4).

**Коротко:** XiControl ни одна из этих служб не нужна — управление идёт через WMI-интерфейс
прошивки и драйверы ядра, а они остаются на месте. MiDeviceService при этом **мешает**: на
выходе из режима Eco она откатывает яркость экрана.

---

## 1. Откуда служба и почему переживает удаление PC Manager

| Факт | Где видно |
|---|---|
| MiService — **отдельный продукт** со своей строкой в «Установке и удалении» | `Timi Personal Computing\MiService\4.1.1.564\uninstall.exe` |
| Заводская предустановка | `Channel.ini`: `Channel = preload` |
| Это **базовый слой**, а не часть PC Manager: решает, какой интерфейс поставить на модель | `mi_oobe_cfg.ini`: TM2424 → `ControlCenter`, `ControlAndAssistant` |
| Обновляет сама себя | `UpdateBroker.exe` («служба обновления ноутбука Xiaomi»), рядом лежат папки `4.1.1.542` и `4.1.1.564` |
| Windows Update её **не** ставит | SoftwareComponent-пакета Xiaomi в хранилище драйверов нет (`pnputil /enum-drivers`) |
| При сбое перезапускается | `sc qfailure MiDeviceService` → `RESTART -- Delay = 60000` |
| Защищена от остановки — но только от SYSTEM | SDDL `D:(D;;DCWP;;;SY)(…)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)…` |

PC Manager — лишь клиент этого слоя, поэтому его удаление службы не трогает.

Про права: deny-ACE запрещает **SYSTEM** менять конфигурацию (`DC`) и останавливать службу
(`WP`). У администраторов (`BA`) оба права есть — `sc.exe` из PowerShell от администратора
службу останавливает и отключает (проверено). Форк описывает и запрет для Everyone — видимо,
на другой версии службы; на TM2424 с 4.1.1.564 его нет.

## 2. Две службы — что делают

Обе работают от `LocalSystem` с типом запуска Auto.

| Служба | Файл | Что делает |
|---|---|---|
| **MiService** | `MiService.exe` | аккаунт Xiaomi и вход (в логе — uid и аватар пользователя), согласия о приватности, телеметрия OneTrack, мастер первого запуска (OOBE), сборщик BSOD, отзывы, подсказки обновлений, BiosPush |
| **MiDeviceService** | `MiDeviceService\MiDeviceService.exe` + `MiDeviceServiceEntry.dll` | всё, что связано с железом — модули ниже |

Модули MiDeviceService (по исходным файлам в её логе
`C:\ProgramData\MI\MiDeviceService\log\MiDeviceService_log.txt`):

| Модуль | Что делает |
|---|---|
| `operator_manager` | подписан на **тот же поток MIFS-событий**, что и наш `MifsEventWatcher` (`0x16` режим, `0x05` подсветка, `0x1B`, `0x23`–`0x27`). На смену режима **меняет режим питания Windows и яркость** — §3 |
| `osd_monitor` | сторож OSD: когда родной OSD установлен, поднимает его обратно, если тот закрылся |
| `driver` / `UpdateStrategyManager` | проверка драйверов и BIOS у Xiaomi — разобрана в [16-oem-driver-check.md](16-oem-driver-check.md), XiControl делает её сам |
| `CameraSetting` | при включении экрана сбрасывает эффекты камеры (AutoFrame, BackgroundConceal) |
| `noise_canceling`, `meeting_module` | шумоподавление микрофона и динамиков для созвонов (на тестовой машине выключено: `micNcMode: 0`) |
| `mi_scene_module_manager` | запускает `MiSceneRecognitionService.exe` и `MiSmartTuning.exe` |

`MiSmartTuning.exe` — «умная подстройка» под активное приложение: меняет лимит мощности CPU
(PL1), параметр Intel DTT (ODVP), частоту памяти (SAGV) и уровень DPST панели. Запускается
**только при установленном PC Manager** (в логе: `not find XiaomiPcManager app`), без него
процесса нет.

Без PC Manager `osd_monitor` работает вхолостую: каждые 3 секунды ищет OSD и пишет две строки
в лог. На тестовой машине за две недели набралось 60 тысяч строк, 4 МБ.

## 3. Чем мешает XiControl

На MIFS-событие `0x16` (смена режима производительности — нашей командой или Fn+K) модуль
`operator_manager` делает три вещи.

**Режим питания Windows** (`SetWindowsPowerSchemeByFnk`). Меняется overlay для текущего
источника питания:

| Новый режим | Overlay |
|---|---|
| Eco (`0x0A`) | `961cc777-2547-4f9d-8174-7d86181b8a7a` — «Максимальная экономия энергии» |
| Авто (`0x09`), Турбо (`0x03`) | сброс (`00000000-…`) — «Сбалансированный» |
| Тихий (`0x02`) на сети | без изменений |

**Яркость при входе в Eco** (`SetLowBrightness`). Служба запоминает текущую яркость. Сама в
наших замерах её не понижала (при 31% и 49% записи не было), порог неизвестен.

**Яркость при выходе из Eco** (`RecoveryBrightness`). Служба **безусловно** записывает
запомненное значение. Всё, что поменялось за время Eco, теряется:

- без автояркости ручная правка в Eco молча откатывается при смене режима;
- с автояркостью кривая XiControl ведёт яркость, на выходе из Eco служба возвращает старое
  значение, затем наша автояркость тянет обратно — видимый скачок.

## 4. Замер на железе

Режимы переключались из XiControl, на батарее, автояркость выключена. Каждые 250 мс
записывались яркость (`WmiMonitorBrightness`), overlay режима питания (реестр
`HKLM\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes`, `ActiveOverlayDcPowerScheme`)
и новые строки лога службы.

```
16:39:59.8  событие 0x16 = 0x0A (Eco), ac:0
16:40:00.6  overlay DC → 961cc777-…            SetWindowsPowerSchemeByFnk mode:1
16:40:01.4  SetLowBrightness(): QueryBacklight:49        ← запомнила, не понизила
16:40:05.1  яркость 49 → 20                              ← выставили мы (как ручная правка)
16:40:24.4  событие 0x16 = 0x09 (Авто)
16:40:25.2  overlay DC → сброшен                 SetWindowsPowerSchemeByFnk mode:2
16:40:25.9  RecoveryBrightness(): QueryBacklight:20 → SetBacklight:49   ← откат 20 → 49
```

Два прогона без изменения яркости дали ту же картину с записью того же значения. В логе
службы за 27.09 есть такой же откат `16 → 65`.

## 5. Что пропадёт, если отключить MiDeviceService

| Пропадёт | Замена |
|---|---|
| смена режима питания Windows вместе с режимом ноутбука | Настройки → Производительность → «Режим питания Windows» (XIC-96): Эко/Тихий → эффективность, Авто/Баланс → сбалансированный, Турбо/Полная → производительность; пока служба запущена, переключатель неактивен |
| понижение яркости в Eco и откат на выходе | не нужно — откат и есть проблема |
| сброс эффектов камеры при включении экрана | эффекты Windows Studio настраиваются в Параметрах Windows |
| шумоподавление для созвонов | — |
| проверка драйверов в родных приложениях Xiaomi | вкладка «Драйверы» в XiControl (XIC-95) |
| сторож родного OSD | у XiControl свой OSD |

Не пропадёт ничего, на чём работает XiControl: события клавиш и команды прошивки идут через
WMI-интерфейс `MiCommonInterface` и драйвер ядра, OSD и проверка драйверов свои. BIOS к тому же
приходит и через Windows Update — пакетом прошивки `wufu.inf` (класс Firmware).

MiService нам не мешает. Если не нужны аккаунт Xiaomi, телеметрия и подсказки обновлений, её
можно отключить так же — второй строкой в том же блоке XiControl.

## 6. Как отключить и вернуть

**Проще всего — в XiControl:** вкладка «Драйверы» → блок «Службы Xiaomi». Там обе службы:
MiDeviceService (мешает — её и стоит отключить) и MiService (не мешает — по желанию, или чтобы
вернуть отключённую раньше). «Отключить» — в два нажатия; XiControl запоминает тип запуска
каждой службы и по «Включить» возвращает именно его. Если службы нет, блок так и пишет —
XiControl она не нужна. Службы трогаются только по кнопке.

Вручную — PowerShell **от администратора**:

```powershell
# отключить
sc.exe config MiDeviceService start= disabled; sc.exe stop MiDeviceService
# и, по желанию, базовую службу
sc.exe config MiService start= disabled; sc.exe stop MiService
```

```powershell
# вернуть как было (исходный тип запуска обеих — Auto)
sc.exe config MiDeviceService start= auto; sc.exe config MiService start= auto
sc.exe start MiService; sc.exe start MiDeviceService
```

**Отключать, а не удалять.** `uninstall.exe` снесёт весь стек, а отдельного установщика
предустановки у пользователя нет — вернуть будет нечем. Отключение откатывается одной командой.

Форк делает то же скриптом `tools/oem-service.ps1`: сохраняет тип запуска и SDDL, временно
снимает deny-биты, отключает службу, а заодно задачу `XiaomiPCHostTask` и автозапуск
`Launch.exe --AutoRun=1` из `HKLM\…\Run`. У форка своя причина: служба поднимала родной попап
рядом с их собственным. Без PC Manager задачи и автозапуска нет, хватает двух команд выше.

Проверено на TM2424 (2026-10-11, XIC-87):

- **MiService отключённую MiDeviceService обратно не поднимает.** После перезагрузки MiService
  запущена (Auto), MiDeviceService — Stopped / Disabled, в её журнале ни строки.
- Дочерний MiSceneRecognitionService.exe переживает остановку службы и работает до перезагрузки,
  дальше его некому запускать.
- С отключённой службой смена режима больше не трогает режим питания Windows и яркость — overlay
  на входе в Eco на батарее остаётся прежним.

## 7. Открытые вопросы

- Какая служба вызывает ghost-touch тачпада при подключении зарядки. По разбору
  miPC в EC пишет `IoTSvc` (`IoTService.exe`, ставится вместе с драйвером `iotdriver.inf`);
  на тестовой машине она уже Stopped / Disabled. В логе MiDeviceService прямых записей в EC
  нет — только MIFS-вызовы.