Open Hardware Monitor Plugin [11-FEB-2011 V1.1]

[Chewtoy]

Found a bug.

When I got OHM set to read my HDD sensors, everything works great except for the fact that OHM seems to tread my DVD-drive like any other HDD. So it winds it up about every minute and then goes to a sudden stop. During this OHM freezes.

Turn HDD sensors off (Options -> untick 'Read HDD sensors') and that problem stops.
However. Now it won't read the temperatures of anything.
The same code I use to get the temp of my CPU, system and GPU is

Code: Select all

[MCPUT]
Measure=Plugin
Plugin=Plugins\OpenHardwareMonitor.dll
Hardware=#WinB#
Type=Temperatures
Sensor=CPU

[MSysT]
Measure=Plugin
Plugin=Plugins\OpenHardwareMonitor.dll
Hardware=#WinB#
Type=Temperatures
Sensor=System

[MGPUT]
Measure=Plugin
Plugin=Plugins\OpenHardwareMonitor.dll
Hardware=#GFX#
Type=Temperatures
Sensor=GPU Core

All those give me the value shown in OHM with Read HDD sensors.
But, like I said, disable that and it gives me the CPU-clockspeed, CPU-Fanspeed and CPU VCore voltage.
So that's huge bug I'd say...
Everything show up correctly in OHM, but the plugin gives me the wrong values.

If I after disableing HDD Sensors restar OHM, the measures give me: AVCC voltage, (what seems to be) CPU max temp, CPU total load as a number.

If I now restart rainmeter (and by that reloading the plugin) everything goes back to normal.

Now I choose to read the HDD sensors (just for testing) I get: CPU core #5 temp, CPU core #2 temp and Sys temp.
Restart rainmeter and it gets the right values.


So, the conclusion is that if you change what should be read by OHM, you have to restart rainmeter. A refresh all does not help.

[TD22057]

Found a bug.
So, the conclusion is that if you change what should be read by OHM, you have to restart rainmeter. A refresh all does not help.

I'm not surprised this is happening. The plugin works by doing this:

1) Enter hardware/sensor discovery mode
1a) read all the hardware and sensor configurations from OHM
1b) repeat 1a) until the same number of sensors has been read 3 times in a row (this handles OHM's finite startup and hardware/sensor discovery time). Once that happens, go to 2)

2) Only read sensor values.

When in mode 1), it requires a lot of calls to OHM and searches for pairing up the hardware and sensors. I was worried that if you do this every time the measure is updated, it will take forever so it switches to mode 2) when it can and just reads the sensor values. But - this assumes that once you start OHM up, the set of sensors and the order it reports them is fixed. Clearly this is where your problem appears as they aren't fixed.

I think the best solution which will fix the problem and still be efficient is to have the plugin see if it gets a different number of sensor values than it expects in 2) and if that occurs, trigger a "reset" and go back to mode 1) to refresh the sensor list. I can also put valid ranges on the sensor values (Load should never be above 100, Temperatures should never be above 500, etc) and if those are violated (which would indicate the wrong sensor is being read), also trigger a mode 1) refresh.

[TD22057]

Version 1.1 has been uploaded. Hopefully it fixes the build issues (it's a VSE 2008 build - not 2010) and it fixes the problem with changing OHM sensors on the fly.

[jsmorley]

Could you have FOUND a more annoying place to host the plugin? LOL

You should take a look at http://www.mediafire.com/. It's free and quite spiffy...

Getting ready to build a skin with it now. I'll report back on anything I find worth mentioning.

[jsmorley]

Looks like there are some issues that need looking into.

The skins made with the plugin seem to work fine in and of themselves. Everything displays as it should and it's very nice.

However...

If any skin using it is running, then Rainmeter becomes a bit weird and unstable. If I install any other skins using a .rmskin file, I either get a crash of Rainmeter (if the new skin has a Lua script) or a behavior where the new skin is loaded but does not display unless I refresh the skin.

I get an error like:

WARNING: (00:00:01.812) MeterWindow "OHMBars" is already active

in the Rainmeter log.

The OHM skin seems to be able to coexist with other skins fine, unless a !RainmeterActivateConfig command is sent via the command line. Then things go south.

It might be possible that PART of the the issue I am was running into is related to having two skins using the plugin.... I had a skin using it running, and then tried to install another, different, skin using it. However, it caused issue with installing .rmskins even with only one running and trying to load anything else. Lua skins and it really seem to hate each other in particular.

Latest build of Rainmeter
Windows 7 64bit

Here is a test skin if you want to play with it:

OHMBars.rmskin

[TD22057]

JS: I added a ton of debug print outs to try and figure out what's happening. I can trigger two failure modes by doing this:

- Create a skin with OHM meters in it
- Double click the OHMBars.rmskin that you supplied.

Failure mode #1: I can get a log output that has the message you saw:

WARNING: (00:00:00.281) MeterWindow "OHMBars" is already active.

This is the most common error. This message appears in log in the middle of a constructor call in my code during a call to initialize the connection to the OHM WMI server. Since the plugin code doesn't know anything about the name "OHMBars", this leads me to believe it's from another thread somewhere in Rainmeter. Given my complete lack of familiarity with Rainmeter, I don't know what I could be doing that would trigger an "is already active" message from Rainmeter. If I install the rmskin and then start Rainmeter, everything seems to work fine. Any ideas on what could be different about an rmskin install vs just a startup?

Failure mode #2: Crash of program. In this case, my extra logging shows the error message:

NOTICE: (00:00:00.218) Refreshing skin "Ted\CPU\CPU.ini"
DEBUG: (00:00:00.281) OHM: BEGIN: Init for 1
DEBUG: (00:00:00.281) OHM: BEGIN creating new SensorMgr
DEBUG: (00:00:00.281) OpenHardwareMonitor: BEGIN: SensorMgr ctor
DEBUG: (00:00:00.281) OpenHardwareMonitor: BEGIN: CoInit
DEBUG: (00:00:00.281) OpenHardwareMonitor: END: CoInit
DEBUG: (00:00:00.281) OpenHardwareMonitor: BEGIN: WMI init
DEBUG: (00:00:00.281) OpenHardwareMonitor: Creating locator object
DEBUG: (00:00:00.281) OpenHardwareMonitor: Creating service object
NOTICE: (00:00:00.296) Refreshing skin "OHMBars\OHMBars.ini"
DEBUG: (00:00:00.328) OHM: BEGIN: Init for 2
DEBUG: (00:00:00.343) OHM: BEGIN creating new SensorMgr
DEBUG: (00:00:00.343) OpenHardwareMonitor: BEGIN: SensorMgr ctor
DEBUG: (00:00:00.343) OpenHardwareMonitor: BEGIN: CoInit
DEBUG: (00:00:00.343) OpenHardwareMonitor: END: CoInit
DEBUG: (00:00:00.343) OpenHardwareMonitor: BEGIN: WMI init
DEBUG: (00:00:00.343) OpenHardwareMonitor: Creating locator object
DEBUG: (00:00:00.343) OpenHardwareMonitor: Creating service object
DEBUG: (00:00:00.343) OpenHardwareMonitor: finished call to connectServer
WARNING: (00:00:00.343) OpenHardwareMonitor: Failed to connect to Open Hardware Monitor WMI service.
OpenHardwareMonitor: System Error: An outgoing call cannot be made since the application is dispatching an input-synchronous call.
DEBUG: (00:00:00.343) OpenHardwareMonitor: END: WMI init
DEBUG: (00:00:00.343) OHM: END creating new SensorMgr

The relevant code fragment is this:

Code: Select all

   log( 0, L"Creating service object" );

   // Connect to the OHM namespace
   HRESULT hr = m_locator->ConnectServer( L"root\\OpenHardwareMonitor",
                                  NULL, // current user
                                  NULL, // password
                                  0, // locale,
                                  NULL, // security
                                  0, // authority
                                  0, // context
                                  &m_service );
   log( 0, L"   finished call to connectServer" );
   if ( FAILED( hr ) )
   {
      m_service = 0;
      log( hr, L"Failed to connect to Open Hardware Monitor WMI service." );
   }

What's weird to me about this is that the first WMI connectServer call never returns but then another DLL init call is made. The SensorMgr is a static object pointer in the DLL so it should only ever be initialized once which is what seems to be causing the problem. The log messages right after connectServer() never trigger in the first init call. That leads me to believe that either Windows is throwing an exception that I'm not catching (didn't think windows routines ever did that) or that Rainmeter is running a separate thread for each skin. The plugin isn't set up to handle multiple threads moving through the init code (or any other code) at the same time.

In summary: it looks like I'm making a call to connectServer() which doesn't return and somehow Rainmeter is calling the init routine again at the same time which triggers the error.

Any help/thoughts/tips would be greatly appreciated...

[jsmorley]

"Any ideas on what could be different about an rmskin install vs just a startup?"

Well, we are already WAY above my pay grade as far as the Rainmeter C++ code goes I'm afraid.

The only thing I can offer that might add illumination is that the difference is: With a .rmskin, Rainstaller is starting Rainmeter, then activating the skin in question with a !bang to Rainmeter.exe "!RainmeterActivateConfig ConfigName SkinName.ini", whereas when you start Rainmeter with the skin already in Rainmeter.ini, no !bang is involved.

[TD22057]

Small update:

From a more careful study of the print out, I was able to find the prints that happen after the connectServer call for skin #1. It looks like what's happening is this:

Code: Select all

- Initialize skin #1
   - no SensorMgr, create one
   - initialize WMI
   - connect to WMI server
   - [call doesn't return]
- Initialize skin #2
   - no SensorMgr, create one
   - initialize WMI
   - connect to WMI server
   - finished WMI setup [failed - already in use]
- Finished skin #2 init
- Setup skin #2 measures
- skin #1 connect to WMI server finished (succeeded)
- start reading skin #1 measures
- crash

So somehow the skin #2 init process is happening while skin #1 is initializing the same DLL. Any ideas how this is possible?

Thanks,
Ted

[jsmorley]

I think we are going to need to see if spx can take a quick look at this... He is our strongest Rainmeter Code / C++ person.

[TD22057]

Minor (mostly worthless) update: I dug around the C++ code a little bit and failure mode #1 that I described with the "already active message" is a wild goose chase. This was caused by me deleting the OHMBars directory from the skins folder but not removing it from the Rainmeter.ini file where it was marked as active. That triggered the installer to report the already active message.

Which still leaves the crashes...