Following is a heads up. I'm still testing v3.18 and hope to release it soon.

I've done a major code refactor in an attempt to get some order back. Part of this is isolating and targeting the code used to create the desktop, window (W mode) and screen saver versions. This has really streamlined the display code and build process. There are now 6 executables in the zip file: Desktop, Window and Screen Saver for the 64 bit and 32 bit architectures. The exe file names no longer contain the architecture digits. The file properties will identify the architecture.

Over the last 12 months or so I've been noticing WMI lockups. My first thought was some kind of thread race condition and so I've refactored the WMI code to ensure each query runs in isolation with no global or common objects. This has really cleaned up that part of the code but hasn't solved the lockup problem. I added some debug code to closely trace what's happening and it turns out the lockups occur every 17-18 minutes and last for 2 minutes. While this is happening every other WMI query on all processes is locked. New queries are allowed to execute but will also be locked, unable to exit.  Because a lot of Desktop Info relies on WMI, this suddenly became a top priority.  I've done much searching and reading and it turns out it's been a problem in Windows since at least 2017 and probably much earlier. No one knows why it happens and Microsoft won't acknowledge it's a problem. I found a very old thread describing this problem exactly and their best guess is WMI does some kind of garbage collection or maintenance under certain circumstances. The frequency seems to increase as the installed RAM increases. This matches my experience of noticing the frequent lockups around the same time I increased the ram on the dev box.

So all of this has led me to explore alternatives and there is an API called PDH which returns performance counters. I tried it on a few Desktop Info items and it turns out it's pretty straight forward and fast, much faster than WMI. A typical WMI query I used to test was averaging around 300ms, the equivalent PDH takes about 16ms. So i'm now adding PDH as the default wherever performance counters are retrieved and also adding new PDH dedicated items where appropriate.

What Is PDH?

Windows Performance Data Helper (PDH) API allows developers to programmatically access performance metrics and performance counters in a Windows system. It can be used as an alternative to WMI queries for retrieving performance metrics.

The advantages are: it is, on average, 20-30 times faster than WMI, it is much easier to code and it doesn't seem to suffer from the flakiness that I'm seeing in WMI.

However, it does have it's own unique set of challenges, for the most part centered around language. I've written it to be as flexible as possible. You can specify the wildcard path in English or your local language. You specify whether to supply the output counter names in English or your local language. If PDH can't find the counters or some other issue prevents it from working, DTI will fall back to WMI where possible.

The easiest way to see your system performance counters is with Windows perfmon.exe. When you add counters you're presented with a list of objects, instances and counters. These are the counters that Desktop Info retrieves via the PDH API. There's a little bit of massaging of the counter names to make them more usable, in the same way that WMI does. For example,

"Bytes Received /sec" becomes "BytesReceivedPersec"

If I'm retro-fitting an existing item, it will continue to use the return values it always has.

You can also see the performance object and counter names in your registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib