Ошибка счетчика производительности 0x800007d0

A couple (2 or 3) times a day, a lot of Perfcounter IIS Application pool sensors give the message Down (Unable to connect the specified computer, or the computer is offline. (Performance Counter error 0x800007D0))
At that moments the monitored servers are running normally without having issues. I already have tried re-adding the IIS Application Pool sensors, but the issue is still there. I monitor all the application pools except _Total.

PRTG is running on a physical server and there are no other issues with sensors.

Does anyone have an idea how to solve this?

iis
perfcounter
prtg

I’m having a problem where sometimes my code will function correctly, but other times it will fail.

This is the first bit of PDH related code that I run:

const std::wstring pidWildcardPath = L"\Process(*)\ID Process";
DWORD bufferSize = 0;
LPTSTR paths = NULL;

PDH_STATUS status = PdhExpandCounterPath(
    pidWildcardPath.c_str(),
    paths,
    &bufferSize);
checkPDHStatus(status, PDH_MORE_DATA, L"Expected request for more data.");

The result of the PdhExpandCounterPath function call is 0x800007D0 (PDH_CSTATUS_NO_MACHINE). The checkPDHStatus function is a simple function that I wrote that asserts that the status is equal to the second parameter. In this case, I expect the result to be PDH_MORE_DATA because paths is NULL and bufferSize is 0. The goal of this call is to determine the size of the buffer I must allocate to store all of the results for a subsequent call to PdhExpandCounterPath. This is described in the PDH documentation under the Remarks section.

The list of PDH error codes describes PDH_MORE_DATA as «Unable to connect to the specified computer, or the computer is offline.» As you can see by the performance counter path in the code above, I am not even trying to connect to a different computer than my own.

It is interesting the way that this code fails. Sometimes it works fine and then other times, it will fail on multiple back-to-back executions of my application. I have #include <pdh.h> in my header file and I have a section in my property sheet for this DLL that looks like this:

<Tool
    Name="VCLinkerTool"
    AdditionalDependencies="pdh.lib"
/>

I’m not sure if it matters, but this program is built by Visual Studio 2005 and run on Windows XP. Am I doing something incorrectly?

---

I’m a co-worker of Dave’s and have discovered the following during my investigation:

the code above runs fine when run from a logged-in interactive session
the code runs fine when initiated as a Scheduled Task AND the user is logged in at the time the scheduled task is fired off
the code FAILS only when run as a Scheduled Task AND the user is NOT logged in at the time the task starts
the code continues to fail if the user logs in after the failing task has started but while it is still running (because it is looping «endlessly» until it gets a PDH_MORE_DATA status back).
In the failing instances, the following environment variables have not been established/set for the program: APPDATA, HOMEDRIVE and HOMEPATH … I don’t think this is a problem. However, the failing program also lacks the SeCreateGlobalPrivilege from its token; the passing programs all have this privilege in the token and PERFMON shows it as «Default Enabled». The other difference is that failing program has the NT_AUTHBATCH user group in the token, while the passing program has NT_AUTHINTERACTIVE instead … all other user groups and privileges are the same for both cases. I think the global privilege is coming from the interactive login, but don’t know if it has any bearing on PDH operation.

I cannot find anything in the Performance Counter/PDH documentation that talks about needing any special permissions or privileges for this functionality to succeed. Is the global privilege required to use Performance Counters ?

Or is there some other context/environment difference between running Scheduled Tasks (as a specific user) when that user is/isn’t logged in at the time the task starts, that would account for the PDH call succeeding/failing respectively ?

• Remove From My Forums

В сети: не удается получить данные счетчиков производительности

• Вопрос

• Как вообще выключить эти счетчики или как от ошибки избавиться?!

Ответы

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

  По умолчанию счетчики производительности отключены. Управляемые серверы с операционными системами, выпущенными вслед за Windows Server 2003, для которых не были запущены счетчики производительности, обычно показывают сообщения об ошибках состояния управления
  Сетевой режим – счетчики производительности не запущены на плитке
  Серверы страниц роли или группы. Чтобы включить счетчики производительности для управляемых серверов, на странице
  Все серверы щелкните правой кнопкой мыши записи на плитке
  Производительность, где показано значение Состояние счетчика (Выключен), а затем выберите
  Запустить счетчики производительности. Счетчики производительности можно также запустить, щелкнув правой кнопкой мыши записи для серверов на плитке
  Серверы, находящейся на страницах роли или группы, а затем щелкнув
  Запустить счетчики производительности.

  http://technet.microsoft.com/ru-ru/library/hh831394.aspx

  Почитайте раздел управления, там много полезного написано.

  • Помечено в качестве ответа

    20 марта 2013 г. 8:22

nublet

Novice

Posts: 5

Liked: never

Joined: Jul 03, 2013 1:59 am

Full Name: Nublet

Contact:

VeeamOne Collect Performance Data 0x800007D0

Hi Guys

We have an issue with collecting performance data on our backup infrastructure. It fails then it is successful. I’m not 100% sure about this so im here for some advise.

Our error is:

Resolved by event:VeeamBpPerfCollectionFailedResolvedEvent
Event description: Performance data for object NAS has been collected successfully
Initiated by: Veeam ONE Monitor (BackupServer)

Summary: Veeam ONE server failed to collect performance data from the specified backup server
Cause: There might be multiple reasons for this: backup server or backup infrastructure component might not be accessible, remote registry is not enabled or WMI service is not running
Resolution: Make sure remote registry is enabled and WMI service is up and running on the server where backup performance data is collected from

Thanks

---

Shestakov

Expert

Posts: 7328

Liked: 780 times

Joined: May 21, 2014 11:03 am

Full Name: Nikita Shestakov

Location: Prague

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by Shestakov » Jun 17, 2016 12:05 pm

Hi Nublet,
Looks like Veeam ONE had problems collecting performance data about one of backup repositories from Backup server, but the issue has been resolved automatically.
Check if Veeam ONE Monitor shows performance data of the repositories. If everything is ok, no action is required.
If the alarm triggers again and again it`s worth contacting the support team.
Thanks!

---

---

Vitaliy S.

VP, Product Management

Posts: 26515

Liked: 2590 times

Joined: Mar 30, 2009 9:13 am

Full Name: Vitaliy Safarov

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by Vitaliy S. » Jun 21, 2016 3:49 pm

Yes, server restart can cause this, however I see that you’re using NAS as a backup target, right? Are you using CIFS repository as a backup target or this is a NAS mounted to your backup server? BTW, what version of Veeam ONE are you using?

---

nublet

Novice

Posts: 5

Liked: never

Joined: Jul 03, 2013 1:59 am

Full Name: Nublet

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by nublet » Jun 21, 2016 11:36 pm

It looks like its been resolved, not showing the error anymore.

We are running the latest version which is 9.
NAS is shared via iSCSI.

Everything appears to be working, but intermittently we get the error.

I will continue to monitor this..

---

nublet

Novice

Posts: 5

Liked: never

Joined: Jul 03, 2013 1:59 am

Full Name: Nublet

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by nublet » Jun 22, 2016 12:23 am

Unfortunately the error is still showing. It is giving an error of

Failed to collect performance data [Backup] HRESULT: 0x800007D0

I need this to disappear, what’s causing this? Do I need to increase more resources on the source server?

We have VeeamOne installed elsewhere and works ok but not for this client.

Thanks

---

Vitaliy S.

VP, Product Management

Posts: 26515

Liked: 2590 times

Joined: Mar 30, 2009 9:13 am

Full Name: Vitaliy Safarov

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by Vitaliy S. » Jun 22, 2016 11:40 am

When does this event occur? At any particular time or event? Do you have a support case opened for this as our support team might find something related in the debug log files?

---

Shestakov

Expert

Posts: 7328

Liked: 780 times

Joined: May 21, 2014 11:03 am

Full Name: Nikita Shestakov

Location: Prague

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by Shestakov » Jun 22, 2016 11:45 am

The issue is probably related to unstable connection between Veeam Backup server and Veeam ONE. Do you have them installed on the same subnet/LAN?
Increasing server performance is not going to resolve the issue. I would also recommend contacting support team.

---

---

rreed

Expert

Posts: 354

Liked: 72 times

Joined: Jun 30, 2015 6:06 pm

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by rreed » Oct 24, 2016 2:05 pm

We get the same thing our environment; collecting tape server and proxy data. Happens every day, sometimes a few times a day. ONE/VBR installed on same server. Tape/proxies are seperate VM’s. Just installed ONE the other day to demo. Looks like we’re not collecting any data at all, or very little at best. I would especially like to have good data on my tape server anyways.

VMware 6
Veeam B&R v9
Dell DR4100’s
EMC DD2200’s
EMC DD620’s
Dell TL2000 via PE430 (SAS)

---

---

rreed

Expert

Posts: 354

Liked: 72 times

Joined: Jun 30, 2015 6:06 pm

Contact:

Re: VeeamOne Collect Performance Data 0x800007D0

Post

by rreed » Oct 24, 2016 2:18 pm

Not yet, I’ve just installed it the other day (boy, quite a bit different from previous version) and just now started to get settled in and tidied up. I will get one going soon as I can.

VMware 6
Veeam B&R v9
Dell DR4100’s
EMC DD2200’s
EMC DD620’s
Dell TL2000 via PE430 (SAS)

---

---

Who is online

Users browsing this forum: No registered users and 3 guests

Summary

After starting Confluence, these messages get logged repeatedly in short intervals, filling up the logs:

2020-06-19 13:34:31,804 WARN [diagnostics-os-thread] [util.platform.windows.PerfDataUtil] addCounter Failed to add PDH Counter: MemoryPages Input/sec, Error code: 0x800007D0

Environment

Confluence is running on a Windows environment.

Cause

These log entries are related to the Windows Performance Monitor tool, which the Confluence Diagnostic module uses in order to gather information from the operating system, to provide OS-related warning messages on the logs (such as low disk space, low free memory, etc). Error 0x800007D0 means the performance monitor tools could not be accessed by Confluence.

Solution

If the Confluence user (the user that’s starting the Confluence service) can’t access the OS’s performance monitoring tools, that error will usually be displayed. The usual solution for these cases, is to add the service user which runs Confluence to the local group «Performance Monitor Users«, as per the Resolution section of this article from Microsoft’s documentation:

• https://support.microsoft.com/en-us/help/969639/error-message-when-you-try-to-access-the-performance-monitor-perfmon-e

Ошибка:  

Counters.cpp : 112 (0xc0000bb8) – Не удалось добавить счетчик производительности

Решение:

1. Переименовать в коде именя счетчиков с английского наименования на русское (если используется русская локализация MS SQL Server). Измененные функции «ИмяСчетчикаКоличествоВзаимоблокировокMSSQL» и «ИмяСчетчикаКоличествоОжиданийMSSQL» есть в архиве.
2. Счетчики в Performance Monitor могут называться и не так как в архиве, тогда пункт 1 не сработает, т.к. вам нужно будет вписать свое имя счетчиков. В этом случае нужно посмотреть точное полное название счетчика здесь: Точное название счетчика нужно смотреть в «Управление компьютером > Производительность > Средства наблюдения > Системный монитор». Спасибо за дополнение ZhiharevDmitriy
3. При установке 32-битного MS SQL Server на 64-битную Windows счетчики производительности не отображаются в PerfMon и их невозможно добавить из 1С. 
   Утилита System Monitor (Perfmon), включенная в состав Windows x64 и используемая по умолчанию, также является 64­разрядным приложением. Microsoft не предоставляет возможности собирать информацию от 32­разрядных счетчиков 64­разрядной утилитой System Monitor (Perfmon). Но нет ли у нас и 32­разрядной версии? Да, она присутствует, поделенная на две части, одна из которых слегка замаскирована, а другая скрыта намного глубже!. Подробно решение описано здесь. Спасибо пользователю cheburashka за описание данной ошибки и решения.
4. Не использовать показатели «Количество взаимоблокировок» или «Количество таймаутов»

Описание:

Если выбрать показатель «Количество взаимоблокировок» или «Количество таймаутов», то ЦУП добавляет счетчики SQL Server в системный монитор (PerfMon), что бы получить эту информацию. Если добавить счетчики не получается, возникает данная ошибка.

——————————————

——————————————

Ошибка:

MSSQL.cpp : 79 ( 0x36b7: The requested lookup key was not found in any active activation context. ) — SQL Server connection failed.

Она же только на русском:

.MSSQL.cpp : 79 ( 0x36b7: Указанный ключ соответствия не обнаружен ни в одном из активных контекстов активации. ) — SQL Server connection failed

Решение:

1. Пользователю ОС под которым запущен клиент ЦУП и пользователю ОС под которым запущен сервер 1С на котором размещается база ЦУП, нужно дать права «Alter trace» в SQL Server, просто откройте инструкцию на шаге настройки «Трассировки» и сделайте все по шагам еще раз, только сделать это нужно для двху пользователей.
2. Проверить, что у пользователя под которым запущен сервер СУБД есть доступ на чтение и на запись в указанный каталог трассировки.

Описание:

Возникает при анализе взаимоблокировок. 

——————————————

Ошибка:
Ошибка при вызове метода контекста (ПрочитатьXML)
{ОбщийМодуль.АнализБлокировок1С.Модуль(975)}: Преобразование значения к типу Число не может быть выполнено

Решение:
заменить код функции «ПодготовитьБлокировки», есть в архиве.

Описание:
Ничего особенного, просто ошибка в коде

——————————————

Ошибка:
Ошибка аутентификации при попытке входа в базу ЦУП в терминале, на отдельной машине все запускается и ошибки нет

Решение:
Установить релиз платформы не ниже 8.2.15.257

Описание:
COMConnector не может найти ключ защиты из-за ошибки в платформе
Ошибка платформы «10080827 Получение лицензии объектом V82.COMConnector»

——————————————

Ошибка:
Microsoft OLE DB Provider for SQL Server: SHOWPLAN permission denied in database ‘tempdb’.

Решение:
Выполнить в СУБД команду
USE tempdb
GO
GRANT SHOWPLAN TO
GO

Описание:
У пользователя SQL, под которым запущена исследуемая база, нет прав на получение плана запроса.

—————————————— 

Ошибка:
Иногда не удается пройти шаг включения ТЖ

Решение:

1. Синхронизировать время на сервере ЦУП и на сервере исследуемой базы
2. Возможна ошибка из-за летнего времени, описана здесь
3. В файле conf.cfg не указано значение параметра ConfLocation. Для 8.3 там должно быть указано C:Program Files (x86)1cv8conf или C:Program Files1cv8conf в зависимости от разрядности платформы.

Описание:
При создании ТЖ сравнивается время файлов, если оно не совпадает ЦУП «думает» что ТЖ не создан.

——————————————

Ошибка:

{ОбщийМодуль.АнализБлокировок1С.Модуль(392)}: Ошибка при вызове метода контекста (Выполнить): {(8, 27)}: Не задано значение параметра «НачалоТранзакции»И ТЖ.МоментВремени МЕЖДУ <>&НачалоТранзакции И &МоментВремениЖертвы

Решение:

Ошибка в коде процедуры «ПодготовитьПредпологаемыхВиновников», исправленная процедура есть в архиве.

Описание:

ЦУП попытался проанализировать «отрывок» транзакции, данные по которой полностью не записались в базу, например ЦУП выключили в середине транзакции.

 ——————————————

Ошибка:

Не собираются оперативные показатели

Решение:

1. Не назначена роль processadmin для пользователя под которым запускается сервер 1С исследуемой базы (чаще всего)

2. «Портится» COM объект «ИБ» в процедуре ПолучитьСоединенияИБ (очень редко но бывает) — т.е. в отладчике объект есть и свойства у него есть, но при попытке использовать метод GetInfoBaseConnections получается лажа. В моей практике было всего пару раз, ловится только через отладчик. В этом случае надо заменить функцию ПолучитьСоединенияИБ, текстом из вложения. Причина не ясна.

——————————————

Ошибка:
{ОбщийМодуль.АнализБлокировок1С.Модуль(941)}: Индекс находится за границами массива

Решение:

Исправить строку 923 ОМ. АнализБлокировок1С

// заплатка на случай если СоставБлокировки[СчИзмерения] получается что-то типа "Счет-фактура 0000001 от 01.01.2001"
Если Найти(СоставБлокировки[СчИзмерения], "=") = 0 Тогда
Продолжить;
КонецЕсли;

Так же нужно исправить функцию БлокировкаРазобрана в том же модуле, вместо 

Структура = Новый Структура("РежимБлокировки, Ресурс", Выборка.РежимБлокировки, Выборка.Ресурс);

Нужно написать:

Структура = Новый Структура("Режим, РежимБлокировки, Ресурс", Выборка.РежимБлокировки, Выборка.РежимБлокировки, Выборка.Ресурс);

Описание:

Ошибка в коде, не предусмотрена ситуация когда есть пробелы в значениях свойств события TLOCK

——————————————

Ошибка:

Невозможно пройти мастер на шаге настройки ТЖ в том случае, если используется более одного сервера в кластере.

Решение:

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

——————————————

Ошибка: 

При анализе возникает сообщение:  Нет проблем с производительностью. 

Хотя вы точно знаете что они есть, видите что в логах есть данные о медленных запросах и т.д.

Решение:

Один из вариантов решения описан в комменатрии (39) от Bad_Developer

Подробное решение проблемы есть там же в прикрепленном файле. 

——————————————

Ошибка:

При анализе взаимоблокировок появляется ошибка “Ошибка при вызове метода контекста (РазделитьФайл)”. 

Решение:

Установить пользователю, под которым запущен сервер 1С:Предприятие с ЦУП, полные права на локальную папку Temp, в которой разбираются результаты анализа. 

Описание:

Как водится с ЦУПом — очередные заморочки с правами. Спасибо пользователю h00k за описание ошибки и решение.

——————————————

Ошибка:

При анализе появляется сообщение «Анализ проблем на выбранном участке не может быть выполнен…»

В мониторе анализе замеры отображаются с восклицательным знаком, ошибка «Ошибка при вызове конструктора (COMОбъект)»

Пока зафиксирована только для 8.3 

Решение:

Т.к. сервер 1С — 64-битный, а comcntr.dll — 32, просто зарегистрировать ее через regsvr32 было недостаточно.
Т.е. на клиенте объект COMConnector создавался по той причине, что и клиент и компонента 32-битные. 

В рамках фонового задания — объект создается уже вызовом сервера — а тут уже срабатывает следующая пакость — дело в том что на 64-ных ОС сделано разделение реестра, и в зависимости от разрядности вызывающего процесса он получает от ОС разные ветки регистрации — результат сервер не видит зарегистрированную 32-ю компоненту. 

Решение проблемы весьма простое — опубликовать данную компоненту как COM+ приложение, т.е. через оснастку «Component Services» 
Просто делаем там дополнительную ветку V83COMConnector — и прописываем внутрь нашу dll. 

Единственный минус — при обновлении платформы нельзя забывать перепрописать dll из нового релиза, а то предположительно можно получить много сюрпризов. 

Описание:

В процедуре ПолучитьComСоединительПриложения() не отрабатывает конструкция Новый COMОбъект(ПолучитьВерсиюCom() + «.COMConnector»), т.е. попытка создать COM-объект V83.COMConnector 

Спасибо H1nt за описание ошибки и решения проблемы.

——————————————

Ошибка:

Происходит зависание при разборе данных о блокировках.

Решение:

Заменить функцию «РазделитьСтроку» в общем модуле «КипОбщий». Код новой функции приведен ниже

Функция РазделитьСтроку(ИсходнаяСтрока, Разделитель, ПустыеСтроки = Ложь) Экспорт

Результат = Новый Массив;
ИсходнаяСтрока2 = ИсходнаяСтрока;
Если ПустыеСтроки = Ложь Тогда
ПустыеСтроки = ?(Разделитель = " ", Истина, Ложь);
Если ПустаяСтрока(ИсходнаяСтрока2) Тогда
Если Разделитель = " " Тогда
Результат.Добавить("");
КонецЕсли;
Возврат Результат;
КонецЕсли;
КонецЕсли;

Позиция = Найти(ИсходнаяСтрока2, Разделитель);
Пока Позиция > 0 Цикл
Подстрока = Лев(ИсходнаяСтрока2, Позиция - 1);
Если Не ПустыеСтроки Или Не ПустаяСтрока(Подстрока) Тогда
Подстрока = СокрЛП(Подстрока);
Результат.Добавить(Подстрока);
КонецЕсли;
ИсходнаяСтрока2 = Сред(ИсходнаяСтрока2, Позиция + СтрДлина(Разделитель));
Позиция = Найти(ИсходнаяСтрока2, Разделитель);
КонецЦикла;

Если Не ПустыеСтроки Или Не ПустаяСтрока(ИсходнаяСтрока2) Тогда
ИсходнаяСтрока2 = СокрЛП(ИсходнаяСтрока2);
Результат.Добавить(ИсходнаяСтрока2);
КонецЕсли;

Возврат Результат;


КонецФункции // РазделитьСтроку()

Описание:

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

Спасибо wondkind за описание ошибки и решения проблемы.

——————————————

Можно ускорить разбор данных исправив неоптимальный запрос, как бы стрнно это не звучало 🙂

Необходимо в ОМ.Анализ в функции ВыгрузитьДанные, переписать запрос с использованием временной таблицы вместо подзапроса.

Ускорение будет весьма ощутимо, чем больше данных было собрано, тем сильнее будет эффект.

Так же прошу обратить внимание на содержательный комментарий (18) от пользователя serno

Там приводится пример ускорения еще одного запроса в ЦУП 

Если у вас есть примеры других ошибок в ЦУП (но не по вине неправильной настройки) пишите в комментариях к статье, буду актуализировать.

P.S. Спасибо Саликову Алексею, за решение некоторых ошибок, описанных в этой статье.