Performance Counters in Windows - Measure Process, CPU, Network, Disk Usage

[Ascend4nt]

Jack:

Hmm.. I run Win 7 x64 mostly nowadays, and there is no problem with that code on my machine.

This message shouldn't show up if pdh.dll is working as it should, and the network counters are reporting performance information as they should:

There are still * wildcards left after a call to PdhExpandWildCardPathW!

*Perhaps* there are no network adapters showing up in your virtual environment? That would make the most sense.

In any case, the code is working as it should, and returning an error where it should (and reporting that info to you in the console as well), so the code itself is fine. Most likely its the virtual OS you are using, or lack of any virtual adapters.

I would suggest 'VMWare Workstation' as the best O/S-emulator out there (or the free VMWare Player).. it works flawlessly in emulating most every O/S I've thrown at it, and I have done a lot of cross-O/S testing/debugging using it.

Edited May 16, 2011 by Ascend4nt

[JackDinn]

I would suggest 'VMWare Workstation' as the best O/S-emulator out there (or the free VMWare Player).. it works flawlessly in emulating most every O/S I've thrown at it, and I have done a lot of cross-O/S testing/debugging using it.

Looks like your right , VMWare does simulate flawlessly as i installed win7 on this comp as a dual boot last night and im still getting the same problem as my VMWare win7x86 is showing.

I defiantly have a network adapter on all OS's installed on this comp. i have checked the .dll exists and that there are network adapters on all os's (Virtual or otherwise)

so far iv only tested on 1 comp, on a virtual os win7 x86 and a standard installation on win7 x86 , i'll try to get it tested on another comp with win7 x86 when i get the opportunity.

many thx for your quick response

Edited May 16, 2011 by JackDinn

[Ascend4nt]

Hmm.. Jack, try running 'TestPDH_PerformanceCounters' and experiment with the different counters. Also see what shows up for "Network Interface" and what is reported.

Since I've tried this on multiple O/S's and haven't experienced the problems you are, I have no way of knowing what's really happening on your PC.. so thanks for experimenting with this.

Also.. do a search on 'Win32_PerfFormattedData_Tcpip_NetworkInterface' in the forums and try out the different UDF's people have written. That's using the same performance counters, but through the slower WMI interface.

[JackDinn]

well iv had a little play with your first suggestions and found that the problem lays with the last network adapter on the list of instances of selected object. "Local area Connection*9". The other 2 work fine (which is a good sigh) but if i try with that adapter or "all" i get the "There are still * wildcards left after a call to PdhExpandWildCardPathW!" error. I really dont know what it means by connection*9 I dont know where it gets the "9" from ?

So heres a screen shot of what im talking about & the console output from trying to display that last instance.

CPU count result:1
_PDH_BrowseCounters() call, PDH DLL 'handle' (or just 'pdh.dll'):1
Selected Counter from _PDH_Browse_Counters:\Network Interface(Local Area Connection* 9)\*
_PDH_GetCounterList() call, $sCounterWildcardPath='\Network Interface(Local Area Connection* 9)\*', PDH DLL 'handle' (or just 'pdh.dll'):1
_PDH_GetCounterList: PdhExpandWildCardPathW 2nd Call successful, 1st reported Bufsize (adjusted+1 on Win2K systems):1520, 2nd call's Bufsize (should match):1520
There are still * wildcards left after a call to PdhExpandWildCardPathW!
Original wildcard path:\Network Interface(Local Area Connection* 9)\*
_PDH_GetCounterList() call time:9.36683293547085 ms

Many thx.

[Ascend4nt]

Huh, that is weird! Since '*' represents wildcards, and in Vista+, the wildcards can be placed within individual parts of the counter path, it doesn't quite make sense why a counter would be reported with a '*' in its name. But it does give us a reason why the code isn't working - my sanity-check on return from the API call needs to be removed, or changed to allow an 'ignore' parameter.

If you look for this in _PDH_PerformanceCounters.au3, you can comment out this section in _PDH_GetCounterList():

; Is there *still* wildcards left in the pattern?? Then it will not work, not even with further expansion
    If StringInStr($sCounterList,'*',1) Then
        ; DEBUG
        _PDH_DebugWrite("There are still * wildcards left after a call to PdhExpandWildCardPathW!"&@CRLF& _
            "Original wildcard path:"&$sCounterWildcardPath)    ;&", Results:"&@CRLF& _
            ;StringReplace($sCounterList,ChrW(0),@CRLF))
        Return SetError(1,0,$aCounterList)
    EndIf

After commenting that out, it should now work for you.

In the meantime, I'll have to think a bit on which conditions I should or shouldn't be checking for wildcard returns (if at all).

*edit: wildcard sanity-check fix is in the latest version (5/22/2011) - uses a more reliable method

Edited May 23, 2011 by Ascend4nt

[JackDinn]

That got it working , thx,

Maybe i could get it to check if the "*" is in the name of the returned adapter list and then reject that adaptor as it shows up in the list on the netmeter im building , i didn't click on it to see what would happen (maybe i should have done).

I wonder why my comp causes this error , my VM win7 is a brand new installation so it cant really be anything to do with that must be the comps network card somehow.

I was wondering what problems could the removal of your filter cause on other comps ?

Anyhow , thx for your help and great work

cheers.

Edited May 19, 2011 by JackDinn

[Ascend4nt]

New updates:

- New UDF: PDH_HardDiskUsageExample.au3

- _PDH_PerformanceCounters.au3 UDF changes:

- Added:

_PDH_RegistryCheck(), _PDH_RegistryEnable(), and _PDH_RegistryDisable() -> to allow checking & altering Performance Counter availability on local OR Remote PC. Note that ADMIN rights are req'd for making changes.

- Changed:

_PDH_Init() & _PDH_UnInit altered to work with new Registry modification code

_PDH_Init() now takes 3 optional parameters regarding Registry state (force registry on, restore on exit, PC Name)

_PDH_BrowseCounters() - added new parameters to allow customization, now allows multiple selections to be returned in an array

- Fixed:

_PDH_BrowseCounters() - default title was not showing for Win7

_PDH_GetCounterList() - Wildcard sanity-check fixed for special cases where a * is part of the Instance name

[JackDinn]

Many thx Ascend4nt , your speedy work is highly appreciated

Shall check out what you've done (with my particular problem) later today.

Thx.

[Revolter]

hmmm ... don't know why but it's not showing the Memory used by a process right ... i'm using Windows 7 32x

[Ascend4nt]

hmmm ... don't know why but it's not showing the Memory used by a process right ... i'm using Windows 7 32x

You're going to have to be a bit more specific. Is one of the included modules not reporting memory, or your own code? If its the former, let me know which module & the output log from Scite. If its your own code, please post the relevant bits. Thanks

[Revolter]

i used the "TestPDH_TaskManager.au3" file and the "Mem Usage" is different from the one that "Windows Task Manager" shows

[Ascend4nt]

That's because 'TestPDH_TaskManager.au3' takes a snapshot and is a static non-updating UDF. If you check the first post you'll see I commented a couple of times about that needing work, and this is one of the notes listed (in the 1st post) for that particular UDF:

NOTES:

- The screen does NOT update, and the UDF is a MESS. This is due to a number of reasons - the biggest one being laziness on my behalf. Plus I need to figure out how best to manage ListView changes.

Since Task Manager itself continually updates its stats, the memory will only match at the moment 'TestPDH_TaskManager' is run (or for processes that aren't actively doing anything requiring memory allocation).

You will see however, if you run TestPDH_PerformanceCounters, and choose 'Process\Working Set', that it reports real-time information for memory. Unfortunately, it doesn't convert the value into KB, so you'd have to do that bit of math yourself.

Maybe in a future release I'll leave the TaskManager example out, or put a MsgBox up stating this information.. or if I'm willing to rewrite it and tackle the management of list changes, I'll release an 'active' version.

Otherwise, for now its just there for a simple example of what can be done. Sorry!

[Revolter]

That's because 'TestPDH_TaskManager.au3' takes a snapshot and is a static non-updating UDF. If you check the first post you'll see I commented a couple of times about that needing work, and this is one of the notes listed (in the 1st post) for that particular UDF:

Since Task Manager itself continually updates its stats, the memory will only match at the moment 'TestPDH_TaskManager' is run (or for processes that aren't actively doing anything requiring memory allocation).

You will see however, if you run TestPDH_PerformanceCounters, and choose 'Process\Working Set', that it reports real-time information for memory. Unfortunately, it doesn't convert the value into KB, so you'd have to do that bit of math yourself.

Maybe in a future release I'll leave the TaskManager example out, or put a MsgBox up stating this information.. or if I'm willing to rewrite it and tackle the management of list changes, I'll release an 'active' version.

Otherwise, for now its just there for a simple example of what can be done. Sorry!

I figured it out that it's static but the difference is very big and I opened windows task manager and searched for a process whos memory doesn't change and the "TestPDH_TaskManager"was still showing it wrong.

For example:

BumpTop: (win) 37.388 K ... (test) 48.476 K

plugin-container.exe: (win) 8.064 K ... (test) 13.400 K

YahooMessenger.exe: (win) 31.968 K ... (test) 40.864 K

*win = Windows Task Manager

*test = TestPDH_TaskManager

Unfortunately, it doesn't convert the value into KB, so you'd have to do that bit of math yourself.

... i need to divide it by 1024?

[Ascend4nt]

I figured it out that it's static but the difference is very big and I opened windows task manager and searched for a process whos memory doesn't change and the "TestPDH_TaskManager"was still showing it wrong.

As I said, it grabs memory usage at the time it runs, once. Make sure you are looking at 'Working Set (Memory)', not 'Memory (Private Working Set)' in Task manager on Windows 7.

... i need to divide it by 1024?

Yep (for the values you see in 'TestPDH_PerformanceCounters' when using memory counters). You can code this yourself, or look at some of the example code. _ProcessAll* functions allow adding automatic division for individual counters.

*edit: clarification on division info

Edited May 28, 2011 by Ascend4nt

[Revolter]

Make sure you are looking at 'Working Set (Memory)', not 'Memory (Private Working Set)'

that was the problem .... thank you ... i was indeed looking at the (Private Working Set)

[Dizzy]

Hi Ascend4nt,

thanks for sharing this great code.

On my Win7 HP i'll get errors:

Error calling PdhGetFormattedCounterValue at index #11, Handle:0x040B5218, Return:C0000BC6 CStatus:C0000BBA

Error calling PdhGetFormattedCounterValue at index #12, Handle:0x04AB10B8, Return:C0000BC6 CStatus:C0000BBA

Error calling PdhGetFormattedCounterValue at index #13, Handle:0x04AB11C0, Return:C0000BC6 CStatus:C0000BBA

Error calling PdhGetFormattedCounterValue at index #14, Handle:0x04AB12C8, Return:C0000BC6 CStatus:C0000BBA

Error calling PdhGetFormattedCounterValue at index #15, Handle:0x04AB13D0, Return:C0000BC6 CStatus:C0000BBA

PdhCloseQuery DLL call successful

PdhCloseQuery DLL call successful

And the overall percent is not correct (as you can see in the screenshots).

Do you have an idea?

Greats

Dizzy

[Ascend4nt]

And the overall percent is not correct (as you can see in the screenshots).

Do you have an idea?

Hmm, that does look wrong. It should read around '6 %' for the 1st and around '4 %' for the 2nd. I'm not sure why its reporting the wrong info for you. Try TestPDH_PerformanceCounters to see what it reports. Wait for the update though, as there is a bug in that module I found today.

Also, ignore those other errors - that's due to a call to gather performance #'s before the counters are ready. They need a little initialization time. The new update will include what I call a 'baseline-sleep' model before gathering info on certain performance counters. This is what I should have been following from the start, but I didn't like adding too long of a sleep in. It seems that 1/4 second is good enough, and that's what I'm setting all the examples to.

[Ascend4nt]

Okay, UDFs are updated again. The console output should now be much cleaner due to differing Debug-output modes, and the 'baseline-sleep' model I should have been using since long ago (gets rid of alot of nagging error messages). Here's the whole list of changes:

5/28/2011:

- Fixed: Bug introduced in last version: Single-item selection in 'Browse Counters Dialog' returning cut-off strings.

- Fixed: _ProcessAll* UDF function had misspelling

- Fixed: The 'Browse Counters Dialog' doesn't display instances in some weird cases. TestPDH_PerformanceCounters now deals with this properly

- Change: TestPDH_TaskManager title reflects static nature of UDF.

- Change: Removed PC Name parameter from _PDH_Init(). Don't know what I was thinking.

- Change: DEBUG information defaults to error-only mode now. Set $PDH_DEBUG to 2 to show ALL Debug info

- Change: All examples (save for one) now follow the 'baseline-sleep' model for collecting data (not always needed)

- Added: _PDH_ObjectBaseCollectQueryData(), _PDH_ProcessObjectCollectQueryData(), & _PDH_ProcessAllCollectQueryData() (to better support baseline-sleep)

[kiboost]

Hi,

I have a problem looking for getting only full cpu usage. It works perfeclty, apart the script grow in ram approximately 20Ko per minute when executed every 2sec.

Any idea to stop this behavior ?

#include "..\PDHPerfCounters\_PDH_PerformanceCounters.au3"
Global $hPDHQuery,$hCPUCounter,$iCPUUsage

Func _PDH_countcpu()
_PDH_Init()
$hPDHQuery = _PDH_GetNewQueryHandle()
$hCPUCounter = _PDH_AddCounter($hPDHQuery,":238\6\(_Total)")
_PDH_CollectQueryData($hPDHQuery) ; collect the query information once (1st collection may fail, so we'll discard it)
Sleep(50)
While 1
  $iCPUUsage = _PDH_UpdateCounter($hPDHQuery,$hCPUCounter)  ; collect query info and then grab counter value
  If Not @error Then ExitLoop
  Sleep(50)
WEnd
_PDH_UnInit($hPDHQuery)
;ConsoleWrite("CPU Usage = "&$iCPUUsage&@CRLF)
EndFunc
While 1
_PDH_countcpu()
Sleep(2000)
WEnd

[kiboost]

ok found a solution for the ram.

But pdh functions seems to works only in admin account Script doesn't work as user that isn't in AD administrators. odd.