Vmsvc error in the rpc receive loop

VMware: Error in the RPC receive loop: RpcIn: Unable to send.

After upgrading a Terminal Server or Terminal Server-based Citrix XenApp virtual machine to VMware Tools 5.x, you experience these symptoms:

In the Windows Application Event log, you see this error reported multiple times in quick succession (log spew):

[ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.

Cause

This issue occurs when the VMware Tools daemon (vmtoolsd) handles more than two Terminal Sessions. When a user connects to a Windows virtual machine, each terminal session should have one vmtoolsd running; however, vmtoolsd is limited to only two sessions running simultaneously. Thus the Windows Application Event log fills up with warning messages similar to this until the total connection count is >2 per session:
[vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send

This is correct:

Workaround

To work around this issue, disable VMware Tools logging to the Event Log and general virtual machine logging to the vmware.log file for the virtual machine.

To disable VMware Tools application event logging:

1. Open the tools.conf file using a text editor. The tools.conf file is located at:
   • Windows XP and Windows Server 2000/2003:
     C:Documents and SettingsAll UsersApplication DataVMwareVMware Tools
   • Windows Vista, Windows 7, and Windows Server 2008:
     C:ProgramDataVMwareVMware Tools
   • Linux:
     /etc/vmware-tools/tools.conf
2. Add this section to the tools.conf file:[logging]
   vmusr.level = error
   vmsvc.level = error
3. Save and close the file.
4. Restart the VMTools service (Administrative Tools >Services).
   Note: If there are users logged in to more than one session, restarting the VMTools service may not be sufficient. You may have to kill the vmtoolsd.exe process for all instances.

sanderdaems

Sander Daems is founder and author of this blog and working as a Lead (Sr.) Consultant by UNICA ICT Solutions. Sander has 15+ years experience in IT, primary focus: virtualization and modern worksplace.

Follow Me:

Источник

IT analyses blog

High technologies on simple business language and some useful tricks for techie geeks.

30 July 2013

Error in the RPC receive loop: RpcIn: Unable to send

The RPC errors mentioned above is caused because of missing vmtools configuration file (tools.conf) within VMware Tools directory. Once you put the configuration file in place and restart the VMTools service, everything seems to be OK.
This procedure is preferred in production environment because guest reboot is not required. You may resolve the problem by simply uninstall/install vmtools but you must schedule VM guest restart at your convenience.

Create tools.conf in the location for:
— MS Windows 2K/XP2K3
C:Documents and SettingsAll UsersApplication DataVMwareVMware Toolstools.conf

— Windows Vista/7/2K8, and 2012:
C:ProgramDataVMwareVMware Toolstools.conf

— Linux:
/etc/vmware-tools/tools.conf

Put the following into the file:

[logging]
log = true

# Enable tools service logging to vmware.log
vmsvc.level = debug
vmsvc.handler = vmx

# Enable new “vmusr” service logging to vmware.log
vmusr.level = error
vmusr.handler = vmx

# Enable “Volume Shadow Copy” service logging to vmware.log
vmvss.level = debug
vmvss.handler = vmx

Then restart VM Tools

— Windows command prompt:
c:Usersuser1> net stop VMtools && net start VMtools

— Linux:
$sudo /etc/init.d/vmware-tools restart

I’ve used this simple VBscript below to copy tools.conf to the appropriate location and restart vmtools service. Use it standalone, for mass deployments — by MS Group Policy, VMware Guest Console or whatever you decide.

‘Copy file: source — destination
Dim FSO
Set FSO = CreateObject(«Scripting.FileSystemObject»)
FSO.CopyFile «\NASPATH_TO tools.conf», «C:Documents and SettingsAll UsersApplication DataVMwareVMware Tools»

‘ Stop & Start Service’
Dim objWMIService, objItem, objService
Dim colListOfServices, strComputer, strService, intSleep
strComputer = «.»
intSleep = 10000
‘ Caution -> strService is case sensitive!
strService = » ‘VMtools’ »
Set objWMIService = GetObject(«winmgmts:» _
& «!\» _
& strComputer & «rootcimv2»)
Set colListOfServices = objWMIService.ExecQuery _
(«Select * from Win32_Service Where Name =»_
& strService & » «)
For Each objService in colListOfServices
objService.StopService()
WSCript.Sleep intSleep
objService.StartService()
Next
WScript.Quit

Thanks man! This solved the problem which was present on a bunch of our Exchange servers

Источник

Vmsvc error in the rpc receive loop

UPDATE: VMWare has posted a patch shortly after I blogged about this. I have not tried this patch yet, but it appears to correct this problem, thanks to s7s for the heads up.

I encountered a new error recently with the latest version on the VMWare tools. On one of my Windows 2008 R2 servers, I had thousands of Event 1000

Of course, my first inclination was to search the knowledge base and forums for anyone else that had/has this issue. VMWare has posted KB Article 2036350 that provides a workaround to this issue. VMWare claims is a known issue and provides a workaround for your usage, the workaround is to disable logging within the VMTools until a fix is issued. In putting the workaround in place, it seems that I could not find the tools.conf file that the Error level needs to be changed in, and it appears this is another bug where installing/upgrading the VMTools does not create the tools.conf file.

Like I said, I was using Windows 2008 R2, so the file should be located under C:ProgramDataVMwareVMware Tools. In my testing procedure, I determined that the RPC errors mentioned above seem to be cause by the tools configuration missing from the server, once you put the configuration in place and restart the VMTools service, all seems to be well.

Below are the contents of the tools.conf file, all you need to do is copy this and paste it into a text file, rename/save it as tools.conf and put the file in the correct location. Once the file is in place, restart the VMTools service.

tools.conf contents:

tools.conf file location:

Windows 2000, XP, and 2003:

C:Documents and SettingsAll UsersApplication DataVMwareVMware Toolstools.conf

Windows Vista, 7, 2008, and 2012:

I do not know if this works in linux as well, but I do not see why it wouldn’t.

I hope this corrects the issue you are reading this for and you can go about your day and have cake …..

Источник

We recently upgrade our ESXI hosts to 5.1

On a few of the VM’s we are getting the below error message.

[warning] [vmuser:vmusr] Error in the RPC receive loop: RpcIn: Unable to send

I need to know the root cause and a solution that we can use that will not require any downtime.

This is a known issue.

There is a fix, but unfortunately, it does require a server reboot. However, if you use vMotion, you won’t have any downtime.

I checked that link before posting here. this is what i get when i follow the url.

We’re sorry, but this Document is not currently available

ASKER CERTIFIED SOLUTION

Take me to the page that displays We’re sorry, but this Document is not currently available

Also when searching Vmware KB

Your search — Error in the RPC receive loop: Rpci: Unable to send — did not match any documents.
No pages were found containing «Error in the RPC receive loop: Rpci: Unable to send».

Suggestions:
Make sure all words are spelled correctly.
Try different keywords.
Try more general keywords.

has the solution you are talking about in it. I am testing now.

Change made. Will see if it works. Looks like it only happens durring times of high volume.

It seems that the upgrade didn’t create the file tools.conf
You can create it like this:

[logging]
log = true

# Enable tools service logging to vmware.log
vmsvc.level = debug
vmsvc.handler = vmx

# Enable new «vmusr» service logging to vmware.log
vmusr.level = error
vmusr.handler = vmx

# Enable «Volume Shadow Copy» service logging to vmware.log
vmvss.level = debug
vmvss.handler = vmx

Save it as tools.conf in the appropriate folder for the guest OS.

Windows XP and Windows Server 2000/2003
C:Documents and SettingsAll UsersApplication DataVMwareVMware Toolstools.conf

Windows Vista, Windows 7, and Windows Server 2008
C:ProgramDataVMwareVMwa re Toolstools.conf

Linux, Solaris, and FreeBSD
/etc/vmware-tools/tools.co nf

After saving and closing, restart the Tools service.

Источник

Vmsvc error in the rpc receive loop

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз мы с вами разобрали замечательную утилиту командной строки robocopy, и с ее помощью научились создавать точные копии папок, двигать их в нужное расположение и многое другое. В сегодняшней публикации я покажу вам, как устранять ошибку «Сервер RPC недоступен (The rpc server is unavailable)», покажу примеры, когда ее мониторинг очень важен в работе корпоративных сервисов.

Для чего нужна служба «Удаленный вызов процедур (RPC)»

Удаленный вызов процедур (RPC) — это протокол, который одна программа может использовать для запроса услуги у программы, расположенной на другом компьютере в сети, без необходимости разбираться в деталях сети. RPC используется для вызова других процессов на удаленных системах, таких как локальная система. Вызов процедуры также иногда называют вызовом функции или вызовом подпрограммы .

RPC использует модель клиент-сервер. Запрашивающая программа — это клиент, а программа, предоставляющая услуги, — это сервер. Подобно обычному или локальному вызову процедуры, RPC — это синхронная операция, требующая приостановки запрашивающей программы до тех пор, пока не будут возвращены результаты удаленной процедуры. Однако использование облегченных процессов или потоков, которые совместно используют одно и то же адресное пространство, позволяет одновременно выполнять несколько RPC.

Язык определения интерфейса (IDL) — язык спецификации, используемый для описания интерфейса прикладного программирования (API) программного компонента — обычно используется в программном обеспечении удаленного вызова процедур. В этом случае IDL обеспечивает мост между машинами на обоих концах связи, которые могут использовать разные операционные системы (ОС) и компьютерные языки.

Процедура сообщения RPC

Когда программные операторы, использующие структуру RPC, компилируются в исполняемую программу, в скомпилированный код включается заглушка, которая выступает в качестве представителя кода удаленной процедуры. Когда программа запускается и выполняется вызов процедуры, заглушка получает запрос и пересылает его клиентской программе и времени выполнения на локальном компьютере. При первом вызове клиентской заглушки она связывается с сервером имен, чтобы определить транспортный адрес, по которому находится сервер.

Программа среды выполнения клиента знает, как обращаться к удаленному компьютеру и серверному приложению, и отправляет сообщение по сети, которое запрашивает удаленную процедуру. Точно так же сервер включает исполняющую программу и заглушку, которая взаимодействует с самой удаленной процедурой. Протоколы ответа-запроса возвращаются таким же образом.

Данная служба есть в любой операционной системе Windows, начиная от Windows 7 и заканчивая Windows 11 и в любой из Windows Server редакции.

Как работает RPC?

Когда вызывается служба RPC (удаленный вызов процедуры), вызывающая среда приостанавливается, параметры процедуры передаются по сети в среду, в которой должна выполняться процедура, а затем процедура выполняется в этой среде. Когда процедура завершается, результаты передаются обратно в вызывающую среду, где выполнение возобновляется, как если бы оно возвращалось из обычного вызова процедуры.

Во время RPC выполняются следующие шаги:

1. Клиент вызывает клиентскую заглушку. Вызов представляет собой вызов локальной процедуры с параметрами, помещенными в стек обычным способом.
2. Клиентская заглушка упаковывает параметры процедуры в сообщение и выполняет системный вызов для отправки сообщения. Упаковка параметров процедуры называется маршалингом.
3. Локальная ОС клиента отправляет сообщение с клиентского компьютера на удаленный сервер.
4. Серверная ОС передает входящие пакеты на серверную заглушку.
5. Заглушка сервера распаковывает параметры из сообщения — это называется демаршалингом .
6. Когда серверная процедура завершается, она возвращается к серверной заглушке, которая маршалирует возвращаемые значения в сообщение. Затем заглушка сервера передает сообщение на транспортный уровень.
7. Транспортный уровень отправляет полученное сообщение обратно на клиентский транспортный уровень, который возвращает сообщение клиентской заглушке.
8. Клиентская заглушка не упорядочивает возвращаемые параметры, и выполнение возвращается вызывающей стороне.

Если вы видите ошибку «Сервер RPC недоступен” (The RPC server is unavailable)», то у вас точно недоступен порт 135. Это может быть критичным для ряда ситуации. Например вы не сможете сохранить настройки RDS фермы, если у одного из хостов RDSH есть проблемы с RPC, то вы будите видеть ошибку «Could not change the connection state for server», вы не сможете перевести его в режим обслуживания (Drain Mode)

Или в приложении Terminal Services Manager будет ошибка при попытке получения данных «Сервер RPC недоступен«.

Так же RPC может быть причиной проблемы в репликации контроллеров домена, где в логах Windows будет фигурировать ошибка ID 1722. Это очень не приятный момент, который может привести к большим проблемам.

Типы RPC

Существует пять типов RPC:

1. Обычный метод работы, при котором клиент выполняет вызов и не продолжает работу до тех пор, пока сервер не вернет ответ.
2. Клиент звонит и продолжает свою обработку. Сервер не отвечает.
3. Средство для отправки нескольких клиентских неблокирующих вызовов в одном пакете.
4. У клиентов RPC есть средство широковещательной рассылки, т. е. Они могут отправлять сообщения на множество серверов, а затем получать все полученные ответы.
5. Клиент делает неблокирующий вызов клиент/сервер; сервер сигнализирует о завершении вызова путем вызова процедуры, связанной с клиентом.

Почему может не работать служба RPC

1. Удаленный компьютер с которым идет взаимодействие выключен
2. На удаленном сервере не запущена или перестала работать служба RPC
3. Подключение по RPC происходит не к тому серверу (Может быть проблема с DNS или IP адресом)
4. Есть блокировки между клиентом и сервером на фаэрволе
5. Используются некорректные настройки сетевого подключение на клиенте или сервере

Преимущества удаленного вызова процедур

К преимуществам удаленного вызова процедур можно отнести следующее:

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

Недостатки RPC

Некоторые из недостатков RPC включают следующее:

• Клиент и сервер используют разные среды выполнения для своих соответствующих подпрограмм, и использование ресурсов, например файлов, также является более сложным. Следовательно, системы RPC не подходят для передачи больших объемов данных.
• RPC очень уязвим для сбоев, потому что он включает в себя систему связи, другую машину и другой процесс.
• Единого стандарта для RPC не существует; это может быть реализовано множеством способов.
• RPC основан только на взаимодействии и, как таковой, не предлагает гибкости, когда дело касается аппаратной архитектуры.

Проверка доступности службы RPC

• Как я и писал выше, в первую очередь вы должны убедиться, что удаленный компьютер к которому вы делаете проверку RPC доступен по сети. Для этого элементарно откройте командную строку или оболочку PowerShell и воспользуйтесь командой Ping, NSlookup, Test-NetConnection. Я буду производить проверку службы удаленного вызова в PowerShell. Выполним для начала команду Ping. Мой удаленный сервер называется SVT201S01.root.pyatilistnik.org. Пишем команду:

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

• Далее выполните Nslookup, чтобы удостовериться, что нужное вам имя компьютера преобразовывается в нужный IP-адрес. Выполните:

Небольшой пример из практики, предположим, что вы мигрировали сервер в другую подсеть, в итоге в DNS должна быть изменена соответствующая запись, но Windows это поймет не сразу, так как у нее есть свой локальный кэш, он живет 15 минут, поэтому если при проверке DNS имени вам выдается не тот IP-адрес, вам необходимо произвести очистку кэша DNS.

• Далее я вам советую проверить отвечает ли порт. Напоминаю, что служба RPC Endpoint Mapper слушает порт под номером 135. В PowerShell введите команду:

Если удаленный RPC порт доступен вы в в строке TcpTestSucceeded будет стоять статус «True».

Если будет порт закрыт или блокируется, то ошибка «Сервер RPC недоступен (The rpc server is unavailable)» вам обеспечена. Поняв, что порт не отвечает, нужно удостовериться, что трафик от клиента до сервера не блокирует фаервол. По умолчанию в любой версии Windows есть встроенный брандмауэр. На время тестирования и поиска причины, я советую его выключить для всех профилей. Сделаем мы это через командную строку:

Данная команда выключит брандмауэр на всех трех профилях сетевой карты.

Далее если порт 135 стал доступен, то можно делать правила на удаленном сервере. Напоминаю, что нужно сделать правило для трех служб:

1. Remote Procedure Call (RPC) — Удаленный вызов процедур (RPC)
2. RPC Endpoint Mapper — Сопоставитель конечных точек RPC
3. COM Server Process Launcher — Модуль запуска процессов DCOM-сервера

Еще хочу отметить, что если у вас есть сторонние антивирусные решения, например Касперский, то там так же есть встроенный сетевой экран, где так же нужно будет создать необходимые, разрешающие правила, которые корректно будут обрабатывать трафик динамических RPC портов.

Проверка работы служб RPC

Следующим шагом является проверка состояния службы на нужном вам сервере или компьютере. Проверять следует три службы:

1. Remote Procedure Call (RPC) — Удаленный вызов процедур (RPC)
2. RPC Endpoint Mapper — Сопоставитель конечных точек RPC
3. COM Server Process Launcher — Модуль запуска процессов DCOM-сервера

В оболочке PowerShell выполните команду:

Для удаленного выполнения Enter-PSSession svt2019s01 далее Get-Service RpcSs,RpcEptMapper,DcomLaunch| Select DisplayName,Status,StartType

Напоминаю, что в команде svt2019s01, это имя удаленного сервера. Как видно из примера, все службы RPC запущены и имею автоматический тип запуска.

Если службы не запущены, то откройте оснастку «services.msc’, зайдите в свойства службы и выставите автозапуск и попробуйте запустить вручную.

Если по каким, то причинам вы не можете запустить службу из оснастки, то можно это сделать через реестр (Кстати реестр можно править и удаленно). Для этого есть несколько веток, но для начала откройте окно «Выполнить» и введите regedit.

• Модуль запуска процессов DCOM-сервера — HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDcomLaunch
• Сопоставитель конечных точек RPC — HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesRpcEptMapper
• Удаленный вызов процедур (RPC) — ветка реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesRpcSs

В каждом из этих расположений есть ключик «Start«, выставите ему значение «2«, это будет означать автоматический запуск службы.

Дополнительные сетевые проверки

В некоторых случаях причиной ошибок с доступностью RPC выступает сбой на сетевых адаптерах. Помогает сброс сетевых настроек и перезагрузка. В сети с Active Directory, старайтесь, чтобы на всех ваших сетевых адаптерах в свойствах были выставлены обе галки IPV4 и IPV6, особенно это актуально для контроллеров домена, где вы легко можете получать ошибку 1722. Еще может помочь отключение протокола Teredo у IPv6. В командной строке выполните:

Источник

UPDATE:  VMWare has posted a patch shortly after I blogged about this.  I have not tried this patch yet, but it appears to correct this problem, thanks to s7s for the heads up.

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2035778

I encountered a new error recently with the latest version on the VMWare tools.  On one of my Windows 2008 R2 servers, I had thousands of Event 1000

[warning] [vmuser:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.

Of course, my first inclination was to search the knowledge base and forums for anyone else that had/has this issue.  VMWare has posted KB Article 2036350 that provides a workaround to this issue.  VMWare claims is a known issue and provides a workaround for your usage, the workaround is to disable logging within the VMTools until a fix is issued.  In putting the workaround in place, it seems that I could not find the tools.conf file that the Error level needs to be changed in, and it appears this is another bug where installing/upgrading the VMTools does not create the tools.conf file.

Like I said, I was using Windows 2008 R2, so the file should be located under C:ProgramDataVMwareVMware Tools.  In my testing procedure, I determined that the RPC errors mentioned above seem to be cause by the tools configuration missing from the server, once you put the configuration in place and restart the VMTools service, all seems to be well.

Below are the contents of the tools.conf file, all you need to do is copy this and paste it into a text file, rename/save it as tools.conf and put the file in the correct location. Once the file is in place, restart the VMTools service.

tools.conf contents:

[logging]
log = true

# Enable tools service logging to vmware.log
vmsvc.level = debug
vmsvc.handler = vmx

# Enable new "vmusr" service logging to vmware.log
vmusr.level = error
vmusr.handler = vmx

# Enable "Volume Shadow Copy" service logging to vmware.log
vmvss.level = debug
vmvss.handler = vmx

tools.conf file location:

Windows 2000, XP, and 2003:

C:Documents and SettingsAll UsersApplication DataVMwareVMware Toolstools.conf

Windows Vista, 7, 2008, and 2012:

C:ProgramDataVMwareVMware Toolstools.conf

I do not know if this works in linux as well, but I do not see why it wouldn’t.

I hope this corrects the issue you are reading this for and you can go about your day and have cake …..