Rpc

15 декабря 2011

Fix: не запускается служба «Удаленный вызов процедур (RPC)»

версия для печати

После перезагрузки компа не запустилась служба «Удаленный вызов процедур (RPC)«. Очень многое зависит от этой службы. В итоге не работает восстановление системы, сетевое окружение, звук, Windows Installer, почти не работает консоль управления (MMC), на панели задач не показываются открытые окна и т.д. и т.п. Попытка ручного запуска приводит к ошибке «Неудается запустить …(RPC) на xxxComp. Ошибка 5: Отказано в доступе«. Антивирус ничего не нашел. Два дня копаний и комп удалось вернуть к жизни.

По рекомендации Microsoft, первое, что пробовал, найти и удалить ветку реестра [HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current\System\CurrentControlSet\Enum\ROOT\LEGACY_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%\repair\secsetup.inf /db secsetup.sdb /verbose

После перезагрузки комп заработал, базовые сервисы стартовали. Появился новый косяк (а может он был с самого начала): под моей учеткой не запускался, как минимум, менеджер управления дисками и Windows Installer. Отказано в доступе. Можно через консоль восстановить права доступа к системному диску «по умолчанию»:

secedit /configure /db %TEMP%\temp.mdb /Cfg %WINDIR%\inf\defltwk.inf /areas filestore

После чего нужно в ручную определить права для каждой учетки к [c:\Documents and Settings\UserXXX] или пересоздать их, смотря что проще.

В моем случае я просто назначил одинаковые права на весь системный диск, взяв за эталон доступ к каталогу [c:\windows].

К эталону добавил свою учетку в домене с полными правами к диску. Может это неправильно с точки зрения безопасности, но копаться с каждым каталогом отдельно у меня времени нет.

Что еще можно было предпринять

Пока комп «болел» вот этого не было в реестре:

Возможно ручное добавление как-то бы изменило ситуацию.

Попытки ручного запуска сервиса, например через команду «net start rcpss» заканчивались ошибкой «Error 5: access denied«.

Я предполагаю, отказано в доступе потому, что сервис должен запускаться под учеткой системы — «NT AUTHORITY». В реестре есть такой параметр:

Я бы попытался вписать сюда админскую учетку и опять запустить сервис.

Но это только идея, не дожившая до реализации.

Еще вариант: использование эксплоита KiTrap0D для получения консоли с правами системы. Об этом эксплоите писали в Хакере. Собственно бинарник здесь. Вот только у меня стоят виндовские обновки, так что похоже данный эксплоит уже не работает.

[1oo%, EoF]

Похожие материалы: Флешка с LiveCD
Понравилась статья? Расскажите о ней друзьям:

На главную : Раньше : Позже

Метки:WinXP, администрирование, терапия



Комментарии

Для работы модуля комментариев включите javaScript

Показать/скрыть правилаВ комментариях не приветствуется:
1. Создание нескольких комментариев подряд от имени одного пользователя. Старайтесь излагать свою мысль в одном сообщении, цитируйте фрагменты других комментариев или обращайтесь непосредственно к их авторам;
2. «Переход на личности», оскорбления, мат. Акцент на возрастные, национальные, половые признаки;
3. Провокационные сообщения;
4. КРИК, т.е. неуместное использование заглавных букв;
5. Излишние эмоции, выраженные большим количеством смайликов. Комментарии, состоящие только из смайликов;
6. Сообщения, не несущие смысловой информации. Если ничего сказать, лучше не пишите вообще;
8. Любая форма рекламы. Ссылки, не имеющие отношения с теме поста;
9. И главное: правила русского языка никто не отменял, пользуйтесь.

У админов есть право полностью или частично удалить комментарий, нарущающий эти правила.

Я создал свою частную сеть Ethereum blockchain. С разных серверов я могу подключиться к сети и добавить ее в сеть без проблем.

Как я запускаю свой сервер:

Как вы видите, RPC-порт открыт:

Внутри моей консоли geth:

— это порт RPC моего локального программного обеспечения узла Ethereum. Но в моем браузере на я вижу следующую ошибку:

Внутри консоли geth, где я запускаю свой загрузочный узел; Я использую следующий код для связи с моим локальным узлом:

Но возвращает false .

[Q] Я знаю, что есть много документации, связанной с подключением к веб-узлу с локальным узлом, и я следил за всеми предложениями.

Но я не могу исправить проблему подключения к web3, с которой я столкнулся.

Как я могу исправить эту проблему? Спасибо за ваше драгоценное время и помощь.

Я сделал предложения по следующим вопросам: Как подключить веб-сайт к geth-узлу? , https://forum.ethereum.org/discussion/3414/step-by-step-guide-to-connect-a-web-site-to-a-geth-node , https://gitter.im/ethereum /web3.js/archives/2015/12/31 .

   Михей

 

30.12.05 — 18:50

Вот собственно все

 
 
   у лю 427

 

1 — 30.12.05 — 20:55

ремоуте процедуре салл — удаленный вызов процедур P.S. лень англицкий переключать
   Ковычки

 

2 — 30.12.05 — 21:18

(0) Иди уже горилку пить и сало трескать…
Потом раскажем…

   Samosval

 

3 — 30.12.05 — 21:32

хорошая и нужная штука.

   ШтушаКутуша

 

4 — 30.12.05 — 22:09

хорошая и нужная штука.

   Темный Эльф

 

5 — 30.12.05 — 22:16

Наверное опять бластер. (0) — если видишь сообщение «сервер RPC недоступен», то с вероятностью 95% у тебя шарится вирус MSBlast.

Пошукай у Веба, Каспера или Микрософта — в общем с Микрософта заплатку качать придется. Если у тебя 5%, то просто перезапусти службу RPC(Remote procedure calls — Удаленный вызов процедур)

   у лю 427

 

6 — 30.12.05 — 22:40

(5) Скорее всего…

   Варвар

 

7 — 31.12.05 — 02:12

плохая и безполезная штука.

 

Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа.
Фредерик Брукс-младший

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.

Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.

Описание WEB-сервисов, XML-RPC

Что такое WEB-сервис и с чего начиналось его развитие ? Ещё задолго до появления понятия WEB-сервисов уже существовали технологии взаимодействия удаленных приложений. Согласно этим технологиям одна программа может вызвать какой-либо метод в другой программе, запущенной на удаленном компьютере. Сокращенно это называется удаленный вызов процедур RPC (Remote Procedure Calling). Однако формат обмена данными при классической модели RPC (DCOM, CORBA) бинарный. А следовательно, работать с данными сложнее и он не слишком подходит, если надо организовать работу распределенной системы, где между отдельными участками сети стоят firewall/прокси-серверы. Технология DCOM реализована только для Windows-систем, CORBA же функционирует на разных платформах, но наиболее полноценна ее реализация на J2EE. Недостатком CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который проходит через firewall. Значит, всегда найдется такая конфигурация сети/платформ, что реализация распределенной системы будет очень затруднительна.

Концепция WEB-сервиса связана с созданием такого RPC, который можно включить в HTTP пакеты. Таким образом началась разработка стандарта, определяющего процесс взаимодействия приложений по протоколу HTTP, чтобы приложения могли функционировать на разных аппаратно-программных платформах и использовать различные технологии и языки разработки. С появлением WEB-сервисов началось развитие сервис-ориентированной архитектуры веб-приложений SOA (Service Oriented Architecture). Наибольшее распространение получили следующие протоколы реализации WEB-сервисов :

XML-RPC XML-вызов удалённых процедур
SOAP Simple Object Access Protocol
REST Representational State Transfer

Практический пример создания клиента WEB-сервиса SOAP с отправкой сообщений и получением ответов представлен здесь.

Приведем очень упрощенный пример. Приложение, обрабатывая данные на локальной машине, вызывает некоторый метод. Если реализация этого метода присутствует в программе, то он (процедура/функция) принимает параметры, выполняет действие и возвращает результирующие данные. Но если этот метод является удаленным вызовом, то необходимо знать, где он будет исполняться. Запрос на выполнение метода вместе с параметрами записывается в виде XML-документа и по протоколу HTTP передается по сети на другой компьютер, где из XML-документа извлекается имя метода и его параметры. После завершения работы метода формируется ответ, который передается компьютеру, пославшему запрос. По этому принципу функционируют все системы, и различия в реализации и процедуре обмена не оказывают существенного влияния на его суть.

Применение XML для описания данных существенно упрощает разработку распределенных приложений, снижаются требования к клиенту и серверу. Программы разбора (парсинга) XML сейчас существуют практически для всех операционных систем и на всех языках программирования.

Протокол WEB-сервиса XML-RPC

Протокол WEB-сервиса XML-RPC, разработанный Дэйвом Винером из компании «UserLand Software» в сотрудничестве с Майкрософт в 1998 году, использует в качестве транспортого механизма протокол HTTP и в качестве формата передаваемых данных XML. Это снимает ограничения, налагаемые как на конфигурацию сети, так и на маршрут следования пакетов. Вызовы XML-RPC представляют собой простой тип данных text/xml и свободно проходят сквозь шлюзы везде, где допускается ретрансляция http-трафика. Однако корпорация Майкрософт вскоре сочла этот протокол слишком упрощённым, и начала расширять его функциональность. После нескольких циклов по расширению функциональности, появилась система, ныне известная как SOAP.

Сообщения XML-RPC передаются методом POST протокола HTTP и бывают трех типов: запрос, ответ и сообщение об ошибке.

Пример запроса, вызов метода CheckWord

POST /RPC2 HTTP/1.0 User-Agent: MyAPP-Word/5.1.2 (WinNT) Host: server.localnet.com Content-Type: text/xml Content-length: 172 <? xml version="1.0"?> <methodCall> <methodName>CheckWord</methodName> <params> <param> <value> <string>Спецификация</string> </value> </param> </params> </methodCall>

Сначала определяется стандартный заголовок http-запроса, MIME-тип данных (Content-Type) которых должен быть text/xml. Размер Content-length должен присутствовать обязательно и иметь корректное значение, равное длине передаваемого сообщения.

Корневой узел определяется тегом <methodCall> и не допускает вложенности, а следовательно в запросе можно вызвать только один метод. Тегом <methodName> определяется название вызываемого метода. Формат названия метода предполагает необязательное наименование класса и наименование метода, разделенные точкой. Можно также включить путь и наименование программы. В примере вызывается метод CheckWord некоторого объекта.

В секцию <params> включают передаваемые параметры, которых может быть несколько и которые описываются тегом <param>. Значение параметра включено в тег <value>. В примере методу передается один параметр в виде текстовой строки «Спецификация», заключенное тегом <string>. Согласно спецификации XML все теги должны иметь соответствующие закрывающие элементы. XML-RPC не включает одиночных тегов.

Типы данных

Для передачи методу параметров и получение возвращаемых значений протокол XML-RPC определяет два сложных и семь простых типов данных, которые используются в реальных языках программирования. Сложные типы данных, например, как объекты, нужно заменять структурами или передавать в двоичном виде.

Тип данных Описание Пример
array Массив значений
Массивы описываются секцией <array> и включают один элемент <data>. Значения массива описываются тегом <value>. Элементом массива могут выступать любые типы, а также массивы — что позволяет описывать многомерные массивы.
<array> <data> <value> <string> Текстовая строка </string> </value> <value><i2>1234</i2></value> <value><i1>15</i1></value> </data> </array>
struct Структура данных
Структура определяется корневым элементом <struct>, включающего произвольное количество элементов <member>, которые определяют отдельный элемент структуры. Элемент структуры описывается двумя тегами: наименование <name> и значение <value>.
<struct> <member> <name>qty</name> <value><i4>12</i4></value> </member> <member> <name>price</name> <value><i7>23</i7></value> </member> </struct>
string Текстовая строка
ASCII-строка символов определяется тегом <string>. В качестве символов нельзя использовать служебные знаки HTML "<" и "&"; их следует передавать кодами &lt; и &amp; соответственно.
<string>XML-RPC</string>
integer Целые числа
Целочисленные значения определяются тегом <i4> или <int> и представляются 4-байтовыми целыми числами со знаком. Отрицательное значение определяется знаком "-".
<i4>123</i4>
boolean Логическое значение
Логический тип данных определяется тегом <boolean> и может принимать значения 0 (false) или 1 (true).

Можно использовать как 1/0, так и true/false соответственно.

<boolean>1</boolean>
date/time Дата и время
Значение даты и времени определяется тегом <dateTime.iso8601>.
<dateTime.iso8601>19980717T14:08:55</dateTime.iso8601>
double Числа с плавающей точкой
Вещественные значения задаются тегом <double> и представляют собой числа с плавающей точкой двойной точности. Пробелы недопустимы.
<double>-12.34</double>
base64 Кодированные данные
Двоичные данные передаются в закодированном виде и описываются тегом <base64>.
<base64>eW91IGNhbid0IHJlYWQgdGhpcyE=</base64>

Пример ответа на вызов метода CheckWord

HTTP/1.1 200 OK Connection: close Content-Length: 166 Content-Type: text/xml Date: Fri, 17 Jul 1998 19:55:08 GMT Server: MyWordCheckSerwer/5.1.2-WinNT <? xml version="1.0"?> <methodResponse> <params> <param> <value> <boolean>true</boolean> </value> </param> </params> </methodResponse>

Ответ включает стандартный http заголовок сервера. MIME-тип данных должен быть text/xml, длина Content-Length должна обязательно присутствовать и иметь значение, равное длине передаваемого сообщения.

Корневой узел ответа начинается с тега <methodResponse> и не допускает вложенности. Теги <params> и <param> аналогичны запросу и включают один или более элементов <value>, которые содержат возвращенное методом значение.

Если сервер отвечает HTTP-кодом 200 ОК, то это значит, что запрос успешно обработан. Т.е. данные по сети переданы корректно и сервер сумел их обработать. Но метод может вернуть ошибку, которая не будет связана с протоколом, а будет ошибкой бизнес-логики приложения. В этом случае передается соответствующее сообщение и структура, которая описывает код ошибки. Пример возвращения кода ошибки :

<methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value> <int>2</int> </value> </member> <member> <name>faultString</name> <value> <string>Too many рarameters</string> </value> </member> </struct> </value> </fault> </methodResponse>

В примере ошибка передается в виде структуры из двух элементов: первый элемент содержит код ошибки 2, а второй элемент описывает ошибку.

Добавить комментарий

Закрыть меню