Ошибка 1818 удаленный вызов процедуры был отменен
Ошибка 1818 удаленный вызов процедуры был отменен
Добрый день уважаемые читатели, продолжаем наш с вами траблшутинг Active Directory в Windows Server 2012 R2, ранее я вам рассказывал, о таких ошибках как ошибка 1722 сервер RPC не доступен на контроллере домена и ошибку 14550 DfsSvc и netlogon 5781, все они не давали нормальной репликации базы данных и групповых политик в домене, что не есть хорошо, мы с ними разобрались, через какое то время при репликации, снова возникла новая ошибка, с текстом: 1818 удаленный вызов процедуры был отменен, давайте смотреть в чем дело и как это решается.
Причины ошибки 1818
Причинами, при которых у вас удаленный вызов процедуры был отменен, во время репликации Active Directory, могут выступать:
- Нестабильное сетевое соединение > я встречал случаи, что ошибка 1818, появлялась из-за, того что виртуальная машина с контроллером домена каждые 5 минут отваливалась. Проведите ее мониторинг по пингу и доступности, а лучше поставьте заббикс.
- Не правильно настроены DNS имена > об этом я уже писал в статьях про ошибки Active Directory и репликации KCC, ссылки выше. Я много раз встречал, что по неведомой мне причине, администраторы прописывали в настройках DNS сервера, адреса провайдера, а потом удивлялись почему не работает, запомните на контроллерах домена прописываем только локальные DNS сервера, а уже на самих локальных делайте форвардинг на провайдерские. Вот вам статья как настраивается форвардинг DNS запросов.
- Слетели права на папку SYSVOL > проверьте на работающем контроллере домена, какие права там выставлены и посмотрите их на сбойном.
- Проверьте не блокирует ли файрвол, нужные порты для службы Knowledge Consistency Checker (KCC)
Ошибку 1818, я получил при выполнении команды, проверяющей время последних репликаций контроллеров домена.
Исправляем ошибку 1818 удаленный вызов процедуры был отменен
И так в моем случае был не стабильный канал между контроллерами домена, и служба KCC, не успевала произвести репликацию, по установленному ей таймингу, но это исправимо. Нужно поправить параметр реестра Windows PC Replication Timeout (mins), оно по умолчанию 5 минут. Microsoft советует этот лимит увеличить до 45 минут. Открываем редактор реестра Windows Server 2012 R2 и переходим в ветку:
Создаем тут новую ключ, типа DWORD (32 бита) со значением RPC Replication Timeout (mins) и ставим ему значение 45.
После этого перезагружаете ваш контроллер домена и проверяете статус репликации Active Directory.
Windows и почти все её компоненты подвержены некоторым ошибкам. Не исключением являются службы системы. С развитием операционной системы и частичного перемещения в облако, ошибок, связанных именно с этим компонентом, становится всё больше. Одной из подобных ошибок является «Сбой при удалённом вызове процедуры».
Что означает ошибка «Сбой при удалённом вызове процедуры»
Ошибка «Сбой при удалённом вызове процедуры» означает неполадку в работе службы «Удалённый вызов процедур (RPC)». Этим сбоем «страдают» утилиты калькулятора, просмотра фотографий и прочие программы нового интерфейса Windows. Также жертвой ошибки может стать утилита DISM, управление которой проходит через командную строку.
Ошибка «Сбой при удаленном вызове процедуры» часто проявляется при попытке использования новых вшитых утилит Windows
Причиной неполадки могут выступать несколько факторов:
- работа вирусов;
- выключенная служба вредоносным ПО или самим пользователем;
- ошибки в файлах службы;
- неверные настройки реестра Windows.
В итоге все «исправительные» работы будут касаться указанной выше службы.
Способы устранения ошибки «Сбой при удалённом вызове процедуры»
Прежде чем приступать к исправлению ошибки, необходимо в обязательном порядке полностью просканировать операционную систему на наличие вирусной активности. Я для этого использую пару антивирусных программ разных разработчиков, к примеру, AVG AntiVirus Free и Panda Free Antivirus. Можно использовать и другие защитники, но для меня эти выигрывают удобством интерфейса и скоростью работы.
После проверки необходимо двигаться от простых решений к более сложным и затратным по времени.
Включение службы «Удалённый вызов процедур (RPC)»
Самое простое решение ситуации может оказаться во включении службы. Вполне возможно, что она просто отключена и это приводит к возникновению ошибки. Windows имеет специальный интерфейс, для управления и настройки служб:
- В поиске операционной системы прописываем слово services и открываем лучшее соответствие.
В поиске операционной системы прописываем слово services и открываем лучшее соответствие
- Находим строчку с названием «Удалённый вызов процедур (RPC)», кликаем по ней правой кнопкой и открываем пункт «Свойства».
Через контекстное меню открываем свойства службы «Удалённый вызов процедур (RPC)»
- Далее во вкладке «Общее» меняем фильтр «Отключена» на «Автоматически», затем сохраняем свойства кнопкой OK и перезагружаем компьютер.
Задаем тип запуска как «Автоматически» и сохраняем изменения
- Пробуем вновь запустить процесс, который раньше выдавал сбой.
Внесение поправок в значение реестра
В случае, если метод выше не помог или доступ к свойствам службы попросту недоступен, необходимо воспользоваться редактором реестра. Все настройки операционной системы собраны именно в этом месте в иерархическом порядке. Именно записи реестра определяют, какой браузер в операционной системе основной, какие утилиты открывают по умолчанию файлы с определёнными расширениями и так далее. Работа каждого отдельного параметра служб также прописана в реестре, включая и тип запуска:
- В меню «Пуск» находим и открываем папку «Средства администрирования», а в ней запускаем программу «Редактор реестра».
Мерез меню пуск открываем «Редактор реестра»
- В древе директорий слева открываем путь HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRpcSs.
Переходим в директорию с установками службы «Удалённый вызов процедур (RPC)»
- Двойным щелчком мыши открываем параметр Start, задаём его значение как 2, затем нажимаем кнопку OK.
Задаем значение 2 в параметре Start для автоматического запуска службы
- Перезапускаем систему, чтобы изменения вошли в силу, и смотрим, исчезла ли проблема.
Проверка файлов системы
Если обе инструкции выше не помогли — это значит, что проблема несколько серьёзнее, чем просто неверные настройки службы. Скорее всего, были повреждены некоторые системные файлы, включая программные оболочки RPC. В таком случае необходимо сделать сканирование и восстановление файлов системы специальной утилитой SFC. Она запускается из командной строки и сканирует Windows на предмет повреждений и несоответствий в данных ОС. И в случае выявления неисправности заменяет повреждённую информацию правильной:
- Вызываем меню Windows (комбинация клавиш Win+X или щелчок правой кнопкой по значку «Пуск»), в выпавшем списке выбираем апплет «Командная строка (администратор)».
В меню Windows выбираем апплет «Командная строка (администратор)»
- В консоли прописываем строчку sfc /scannow и запускаем программу в работу клавишей Enter.
Команда sfc /scannow запускает сканирование и восстановление системных файлов
- Не закрываем терминал, пока программа не закончит свою работу, а после перезагружаем ПК.
Видео: как провести сканирование и восстановление системных файлов
Исправить ошибку «Сбой при удалённом вызове процедуры» не сложнее, чем сходить в магазин. Достаточно провести всего несколько процедур по оздоровлению соответствующей службы Windows, и все программы системы будут работать в штатном режиме.
После перезагрузки компа не запустилась служба "Удаленный вызов процедур (RPC)". Очень многое зависит от этой службы. В итоге не работает восстановление системы, сетевое окружение, звук, Windows Installer, почти не работает консоль управления (MMC), на панели задач не показываются открытые окна и т.д. и т.п. Попытка ручного запуска приводит к ошибке "Неудается запустить . (RPC) на xxxComp. Ошибка 5: Отказано в доступе". Антивирус ничего не нашел. Два дня копаний и комп удалось вернуть к жизни.
По рекомендации Microsoft, первое, что пробовал, найти и удалить ветку реестра [HKLMSYSTEMCurrentControlSetHardware ProfilesCurrentSystemCurrentControlSetEnumROOTLEGACY_RPCSS] . Ее у меня не оказалось, возможно в результате каких-то установленных обновлений.
Далее, попытка восстановить параметры службы в реестре. Поскольку regedit.exe работал только на чтение/удаление (еще один побочный эффект), не получилось внести изменения. Да они и не нужны были, т.к. все было верно. Должно выглядеть вот так:
Значение параметра start может отличаться. Изменить реестр все же можно, но при этом нужно загрузиться с MS ERD commander.
Следующие шаги просто распишу по пунктам. Общая идея в том, что нужно заменить файлы на заведомо рабочие. Их можно взять с другой машины или из дистрибутива Windows (как я сделал).
- Запустить консоль (Пуск > Выполнить: cmd)
- cd z:i386 (там дистрибутив Windows)
- expand explorer.ex_ %TEMP%explorer.exe
- expand svchost.ex_ %TEMP%svchost.exe
- Запустить Диспетчер задач (Ctrl+Shift+Esc)
- Остановить процесс exlporer.exe
- copy %TEMP%explorer.exe %SYSTEMROOT% /y
- Остановить все процессы svchost.exe. Внимание! После этого у вас будет 60 секунд до перезагрузки машины.
- copy %TEMP%svchost.exe %systemroot%system32 /y
Этот финт тоже не дал результатов. Еще вариант: запустить проверку всех защищенных системных файлов с заменой неправильных версий правильными. В консоли выполнить:
sfc /PURGECACHE – Очистка файлового кэша и немедленная проверка файлов
sfc /SCANONCE – Разовая проверка при следующей загрузке
Не помогло.. Тогда совсем брутальный ход – восстановление параметров безопасности. Опять же в консоли:
secedit /configure /cfg %windir%
epairsecsetup.inf /db secsetup.sdb /verbose
После перезагрузки комп заработал, базовые сервисы стартовали. Появился новый косяк (а может он был с самого начала): под моей учеткой не запускался, как минимум, менеджер управления дисками и Windows Installer. Отказано в доступе. Можно через консоль восстановить права доступа к системному диску "по умолчанию":
secedit /configure /db %TEMP% emp.mdb /Cfg %WINDIR%infdefltwk.inf /areas filestore
После чего нужно в ручную определить права для каждой учетки к [c:Documents and SettingsUserXXX] или пересоздать их, смотря что проще.
В моем случае я просто назначил одинаковые права на весь системный диск, взяв за эталон доступ к каталогу [c:windows] . К эталону добавил свою учетку в домене с полными правами к диску. Может это неправильно с точки зрения безопасности, но копаться с каждым каталогом отдельно у меня времени нет.
Что еще можно было предпринять
Пока комп "болел" вот этого не было в реестре:
Возможно ручное добавление как-то бы изменило ситуацию.
Попытки ручного запуска сервиса, например через команду "net start rcpss" заканчивались ошибкой "Error 5: access denied". Я предполагаю, отказано в доступе потому, что сервис должен запускаться под учеткой системы – "NT AUTHORITY". В реестре есть такой параметр:
Я бы попытался вписать сюда админскую учетку и опять запустить сервис. Но это только идея, не дожившая до реализации.
Еще вариант: использование эксплоита KiTrap0D для получения консоли с правами системы. Об этом эксплоите писали в Хакере. Собственно бинарник здесь. Вот только у меня стоят виндовские обновки, так что похоже данный эксплоит уже не работает.
Похожие материалы: Флешка с LiveCD
Понравилась статья? Расскажите о ней друзьям: