Ошибка «Процесс сервера не может быть запущен, так как указана неправильная идентификация» в Windows 7 появляется в тот момент, когда система пытается запустить COM/DCOM-сервер (например, при открытии оснастки Управление компьютером, Службы или при обращении к сетевым компонентам), но учётные данные, под которыми зарегистрирован этот сервер, не проходят проверку. Чаще всего сообщение возникает при запуске программ, использующих удалённые вызовы, при открытии консоли services.msc или при попытке подключиться к другому компьютеру по сети.
Причина почти всегда одна и та же по сути: в настройках DCOM-приложения указана учётная запись, которая либо не существует, либо имеет неверный пароль, либо не обладает нужными правами. Ниже разберём, как найти проблемный компонент и исправить идентификацию без переустановки системы.
Что означает эта ошибка и когда она возникает
Windows использует технологию COM/DCOM для взаимодействия программ и системных служб между собой. Каждое DCOM-приложение может запускаться под определённой учётной записью: системной, интерактивного пользователя или конкретного пользователя, заданного вручную. Если пароль этой учётной записи был изменён, сама запись удалена или заблокирована, попытка запуска сервера завершается ошибкой идентификации.
Типичные ситуации, в которых появляется сообщение:
- 🔧 Открытие оснасток управления: Службы, Просмотр событий, Управление компьютером;
- 🌐 Обращение к удалённому компьютеру по сети через DCOM или WMI;
- 📦 Запуск программ, устанавливающих собственные COM-серверы (системы резервного копирования, бухгалтерский софт, антивирусы);
- 👤 Смена пароля учётной записи, под которой был зарегистрирован DCOM-сервер.
⚠️ Внимание: если ошибка появилась сразу после смены пароля пользователя или переименования учётной записи — почти наверняка дело в устаревших данных идентификации DCOM-приложения. Начинайте диагностику именно с этого.
Шаг 1. Определяем, какой компонент вызывает ошибку
Прежде чем править настройки, нужно понять, какой именно DCOM-сервер не может запуститься. Самый надёжный источник информации — Журнал событий Windows.
Откройте меню «Пуск», введите eventvwr.msc и нажмите Enter. Перейдите в раздел Журналы Windows → Система и найдите события с источником DistributedCOM или просто DCOM, совпадающие по времени с появлением ошибки. В описании события обычно указан APPID / CLSID проблемного компонента — длинный код в фигурных скобках.
Запишите этот идентификатор — он понадобится на следующем шаге, чтобы найти нужное приложение в консоли служб компонентов.
Шаг 2. Проверяем службы, необходимые для работы DCOM
Ошибка идентификации иногда является следствием того, что остановлены базовые службы, обеспечивающие запуск COM-серверов. Проверьте их состояние через консоль services.msc.
- ⚙️ DCOM Server Process Launcher (DcomLaunch) — тип запуска «Автоматически», служба должна работать;
- 🔄 Remote Procedure Call (RPC) — «Автоматически», работает;
- 📡 RPC Endpoint Mapper — как правило, запускается вместе с RPC;
- 🪪 Windows Management Instrumentation (Winmgmt) — желательно «Автоматически», если ошибка связана с WMI.
Если служба остановлена и не запускается вручную, посмотрите вкладку Зависимости в её свойствах: возможно, не работает родительская служба. Изменять тип запуска RPC и DcomLaunch на «Отключена» нельзя — это приведёт к неработоспособности системы.
Шаг 3. Исправляем идентификацию в службах компонентов
Основной инструмент исправления — консоль Службы компонентов. Откройте её командой:
dcomcnfgИли через comexp.msc — в Windows 7 обе команды открывают одну и ту же оснастку. Далее пройдите по пути Службы компонентов → Компьютеры → Мой компьютер → Настройка DCOM.
Найдите в списке приложение, чей APPID совпадает с записью из журнала событий. Если имя приложения неочевидно, откройте редактор реестра (regedit) и поиском по ветке HKEY_CLASSES_ROOT\CLSID найдите скопированный идентификатор — в значении по умолчанию обычно указано понятное имя компонента.
Откройте Свойства найденного приложения и перейдите на вкладку Удостоверение (Identity). Здесь возможны три варианта настройки:
| Вариант идентификации | Когда используется | Риск ошибки |
|---|---|---|
| Интерактивный пользователь | Сервер работает в сессии вошедшего пользователя | Низкий, но сервер не запустится без входа в систему |
| Запускающий пользователь | Сервер стартует под учёткой того, кто его вызвал | Низкий, вариант по умолчанию для многих компонентов |
| Указанный пользователь | Сервер работает под фиксированной учётной записью | Высокий: смена пароля ломает запуск |
| Системная учётная запись | Только для служб, не для интерактивных приложений | Низкий, но применим не ко всем компонентам |
Если выбран вариант «Указанный пользователь» — обновите пароль в соответствующих полях или переключите идентификацию на «Интерактивный пользователь» / «Запускающий пользователь», если это допустимо для данного приложения. После изменения нажмите «Применить» и повторите действие, вызывавшее ошибку.
☑️ Проверка и исправление идентификации DCOM
⚠️ Внимание: для системных компонентов Windows кнопки на вкладке «Удостоверение» могут быть неактивны, а изменение настроек системных DCOM-приложений способно нарушить работу ОС. Меняйте идентификацию только у компонентов сторонних программ, чьё назначение вам известно.
Шаг 4. Проверяем учётную запись и права
Если DCOM-сервер зарегистрирован под конкретным пользователем, убедитесь, что сама учётная запись в порядке. Откройте lusrmgr.msc (в редакциях Windows 7 Professional и выше) и проверьте: запись не отключена, пароль не просрочен, не установлена блокировка.
Дополнительно проверьте локальные политики безопасности через secpol.msc: раздел Локальные политики → Назначение прав пользователя. Учётная запись, под которой запускается сервер, должна иметь право «Вход в качестве пакетного задания» или «Вход в качестве службы» — в зависимости от того, как стартует компонент. Отсутствие этих прав — частая причина отказа в запуске при корректном пароле.
В домашних редакциях Windows 7 (Home Premium, Starter) оснастки lusrmgr.msc и secpol.msc отсутствуют. В этом случае управление пользователями доступно через Панель управления → Учётные записи пользователей, а тонкие политики придётся проверять косвенно — например, созданием нового пользователя и повторением действия под ним.
Как проверить, связана ли ошибка с конкретным пользователем
Создайте новую учётную запись администратора, войдите под ней и повторите действие, вызывавшее ошибку. Если под новым пользователем всё работает — проблема в профиле или правах исходной учётной записи, а не в самом компоненте.
Шаг 5. Дополнительные способы устранения
Если настройки идентификации корректны, а ошибка сохраняется, стоит проверить целостность системных файлов. Откройте командную строку от имени администратора и выполните:
sfc /scannowУтилита проверит защищённые файлы Windows и при обнаружении повреждений попытается восстановить их из кэша. Процесс занимает заметное время — дождитесь завершения и перезагрузите компьютер.
Также имеет смысл переустановить программу, чей COM-сервер вызывает ошибку: при повторной установке компонент регистрируется заново, и записи идентификации обновляются автоматически. Перед переустановкой полностью удалите приложение и перезагрузитесь.
Ещё один вариант — восстановление системы на точку, созданную до появления ошибки. Это особенно эффективно, если сбой начался после установки обновлений или нового ПО. Точки восстановления доступны через Панель управления → Восстановление.
Частые вопросы
Можно ли исправить ошибку без прав администратора?
Нет. Доступ к консоли служб компонентов, изменение идентификации DCOM-приложений и запуск sfc /scannow требуют прав администратора. Без них возможна только диагностика через просмотр событий.
Ошибка возникает только при сетевом доступе к этому ПК. Что проверить?
Проверьте, что на обоих компьютерах работают службы RPC и DCOM Server Process Launcher, а учётная запись, используемая для удалённого подключения, существует на целевой машине и имеет актуальный пароль. Также убедитесь, что брандмауэр не блокирует DCOM-трафик.
После смены пароля ошибка появилась сразу. Это связано?
Да, это наиболее вероятная причина. Найдите в консоли служб компонентов приложения с типом идентификации «Указанный пользователь» и обновите в них пароль на актуальный.
Опасно ли менять настройки DCOM?
Для сторонних приложений — относительно безопасно: в худшем случае программа перестанет запускаться, и настройку можно вернуть. Изменять параметры системных компонентов Windows без чёткого понимания их роли не стоит.
Поможет ли переустановка Windows?
Поможет, но это крайняя мера. Сначала стоит пройти все шаги диагностики: проверку журнала событий, служб, идентификации компонента и целостности системных файлов. Переустановка оправдана только при массовых повреждениях системы.