What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags

View all Tags

[C#] Using Performance Counters in EXE/Script Advanced sensors




I've been creating EXE/Script Advanced sensors for PRTG in C# for some months now and I'm having trouble whenever I need to get Performance Counters values within my code.

The strange thing is that most of the times everything works fine, but sometimes some weird exceptions occur, such as:

System.InvalidOperationException: The Counter layout for the Category specified is invalid, a counter of the type:  AverageCount64, AverageTimer32, CounterMultiTimer, CounterMultiTimerInverse, CounterMultiTimer100Ns, CounterMultiTimer100NsInverse, RawFraction, or SampleFraction has to be immediately followed by any of the base counter types: AverageBase, CounterMultiBase, RawBase or SampleBase.
   at System.Diagnostics.CategorySample.GetCounterDefinitionSample(String counter)
   at System.Diagnostics.PerformanceCounter.NextSample()
   at System.Diagnostics.PerformanceCounter.NextValue()

A code example: https://pastebin.com/s4b7p1JA

These sensors run simultaneously on different PRTG devices (i.e. different host IPs/names).

Is this something you can help me with?

Thanks in advance.

c# performancecounters prtg

Created on Jan 15, 2019 3:34:28 PM

Last change on Jan 15, 2019 4:19:10 PM by  Stephan Linke [Paessler Support]

2 Replies



After looking the code example you linked in your request, I can tell you that you definitively should add try-catch phrases to

  • a) be able to determine where the error happens and
  • b) get actual control over your code and react in such situations

Once you have such try-catch statements (you can cascade them as well) you will be able to determine where exactly this happens.. if you implement a error-handler procedure in the code, you might get even more information.. in any case, you can then react to errors in the code and determine what you give back to PRTG - the result of the EXE should always be PRTG readable, no matter if the execution raised and error or not - if the error is just temp. because of what ever issues - then you might instruct PRTG to notify only after X minutes of error state.. meaning you might just lose temporary data.

Btw. - it looks like you use a EXE that PRTG is executing in short intervals to collect system counter data. Why don't you just create a EXE that initiates one time a connection to those counters and then e.g. in 30 second intervals (or what you want) re-read them (keep the session/objects alive) and fire them back to PRTG API - sensors like HTTP Push Data Advanced would help you here - you can inject information rather then have PRTG pulling them... push instead of pull more or less..

From what I see, the issue is likely more in the code then in PRTG - and if I understand it right the issue is intermittent and not constant.


Florian Rossmark


Created on Jan 15, 2019 7:41:50 PM



Thank you for your reply, Florian.

I'll follow your advice. Unfortunately I don't think that last option fits my scenario, but I'll look further into it.

Created on Jan 16, 2019 11:41:06 AM

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.