It is currently October 26th, 2021, 10:45 am

Silent crash

Report bugs with the Rainmeter application and suggest features.
User avatar
Yincognito
Rainmeter Sage
Posts: 4071
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Silent crash

Post by Yincognito »

dhmolson wrote: July 30th, 2021, 10:25 pm I am now having an issue with the read/write speeds in the ForceX System Monitor 3 HDD_5 skin not showing. They just show 0 all the time, even when I know my drives are reading or writing data. Any ideas?

EDIT: I looked into it and I think the issue is that the ForceX skins use the deprecated PerfMon plugin. I am trying to edit the skin myself to make it use the newer UsageMonitor plugin instead but I have very little experience writing Rainmeter skins. Can anyone help?
They work fine for me so they should work for you as well, but if you really want it...
Any measure like this from your HDD_5.ini (where N is your drive number):

Code: Select all

[Mse_DriveNAccess]
Measure=Plugin
Plugin=Plugins\PerfMon.dll
PerfMonObject=LogicalDisk
PerfMonCounter="Disk Bytes/sec"
PerfMonInstance="#driveN#"
becomes:

Code: Select all

[Mse_DriveNAccessValues]
Measure=Plugin
Plugin=UsageMonitor
Category=LogicalDisk
Counter=Disk Bytes/sec
Name=#driveN#

[Mse_DriveNAccess]
Measure=Calc
Formula=Mse_DriveNAccessValues
As you can see, the conversion is quite easily done. Normally it should be even easier to do, but because an UsageMonitor measure yields different string and number values and the associated String meters automatically use the string value for display, a second (Calc) measure is needed to specifically use the number values in the associated meters, so that the autoscaling can be performed. I chose to name the original UsageMonitor measure differently instead of the Calc measure so that no modification will be required in the meters (which will continue to use Mse_DriveNAccess for their MeasureName options, just like before).
dhmolson
Posts: 16
Joined: July 26th, 2021, 10:59 pm

Re: Silent crash

Post by dhmolson »

Yincognito wrote: July 31st, 2021, 1:29 am They work fine for me so they should work for you as well, but if you really want it...
Any measure like this from your HDD_5.ini (where N is your drive number):

Code: Select all

[Mse_DriveNAccess]
Measure=Plugin
Plugin=Plugins\PerfMon.dll
PerfMonObject=LogicalDisk
PerfMonCounter="Disk Bytes/sec"
PerfMonInstance="#driveN#"
becomes:

Code: Select all

[Mse_DriveNAccessValues]
Measure=Plugin
Plugin=UsageMonitor
Category=LogicalDisk
Counter=Disk Bytes/sec
Name=#driveN#

[Mse_DriveNAccess]
Measure=Calc
Formula=Mse_DriveNAccessValues
As you can see, the conversion is quite easily done. Normally it should be even easier to do, but because an UsageMonitor measure yields different string and number values and the associated String meters automatically use the string value for display, a second (Calc) measure is needed to specifically use the number values in the associated meters, so that the autoscaling can be performed. I chose to name the original UsageMonitor measure differently instead of the Calc measure so that no modification will be required in the meters (which will continue to use Mse_DriveNAccess for their MeasureName options, just like before).
Thank you so much for your help! I really appreciate you putting in the time to help me not only make the conversion but also understand how it works. Unfortunately, the drives still showed no activity in the skin. I opened up perfmon.msc and sure enough, it gave me the following error message:
Performance Monitor Error.PNG
I did a quick Google search and found this article explaining how to fix the issue:
https://social.technet.microsoft.com/wiki/contents/articles/19374.windows-performance-monitor-unable-to-add-these-counters.aspx
Now the skin works! The graphs for disk activity look strange though; the line goes all the way to the top if there is any activity, and if there is no activity then the line goes to the bottom. Before all this, the graph used to go up and down in different amounts based upon how heavily the disk was being used. For example, 20kbps would only make the graph go up a little bit, whereas 20mbps would make the graph go up more. Does this have anything to do with swapping the PerfMon plugin for the UsageMonitor plugin?
You do not have the required permissions to view the files attached to this post.
User avatar
balala
Rainmeter Sage
Posts: 13345
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Silent crash

Post by balala »

dhmolson wrote: July 31st, 2021, 3:12 am Thank you so much for your help! I really appreciate you putting in the time to help me not only make the conversion but also understand how it works. Unfortunately, the drives still showed no activity in the skin. I opened up perfmon.msc and sure enough, it gave me the following error message: Performance Monitor Error.PNG
I did a quick Google search and found this article explaining how to fix the issue:
https://social.technet.microsoft.com/wiki/contents/articles/19374.windows-performance-monitor-unable-to-add-these-counters.aspx
Now the skin works! The graphs for disk activity look strange though; the line goes all the way to the top if there is any activity, and if there is no activity then the line goes to the bottom. Before all this, the graph used to go up and down in different amounts based upon how heavily the disk was being used. For example, 20kbps would only make the graph go up a little bit, whereas 20mbps would make the graph go up more. Does this have anything to do with swapping the PerfMon plugin for the UsageMonitor plugin?
There are some cases hen the Performance Monitor encounters some problems. Here is a description on how to deal with such problems. Not sure if this helps, but probably it worth a try.
dhmolson
Posts: 16
Joined: July 26th, 2021, 10:59 pm

Re: Silent crash

Post by dhmolson »

balala wrote: July 31st, 2021, 11:53 am There are some cases hen the Performance Monitor encounters some problems. Here is a description on how to deal with such problems. Not sure if this helps, but probably it worth a try.
I have followed all the steps outlined in the post you linked, but the ForceX System Monitor's HDD skin is still showing a graph that only displays whether or not there is disk activity, and does not reflect how much disk activity is happening. Here is a screenshot of the skin in action to make sure it is clear what I mean:
ForceX HDD Skin.PNG
You do not have the required permissions to view the files attached to this post.
User avatar
SilverAzide
Rainmeter Sage
Posts: 1629
Joined: March 23rd, 2015, 5:26 pm

Re: Silent crash

Post by SilverAzide »

dhmolson wrote: July 31st, 2021, 12:48 pm I have followed all the steps outlined in the post you linked, but the ForceX System Monitor's HDD skin is still showing a graph that only displays whether or not there is disk activity, and does not reflect how much disk activity is happening. Here is a screenshot of the skin in action to make sure it is clear what I mean: ForceX HDD Skin.PNG
Now that you've repaired your Performance Counter database, I'm curious if the ModernGadgets skins are still crashing Rainmeter... :???:
Gadgets Wiki GitHub More Gadgets...
dhmolson
Posts: 16
Joined: July 26th, 2021, 10:59 pm

Re: Silent crash

Post by dhmolson »

SilverAzide wrote: July 31st, 2021, 3:27 pm Now that you've repaired your Performance Counter database, I'm curious if the ModernGadgets skins are still crashing Rainmeter... :???:
I haven't had any of the silent crashes due to ModernGadgets since I updated to the Rainmeter 4.4.0.3508 beta (and also updated ModernGadgets to 1.7.0). The only crashes I've had since updating seemed to be due to the ForceX System Monitor HDD skin. Since repairing the Performance Counter database I have not had any crashes at all. The only issue I'm having now is this strange issue with the ForceX System Monitor HDD skin with the graphs.
dhmolson
Posts: 16
Joined: July 26th, 2021, 10:59 pm

Re: Silent crash

Post by dhmolson »

I think I found the issue with the ForceX System Monitor HDD skin that was causing the graphs to act strangely. Here is a portion of the skin:

Code: Select all

------------------------------------ HDD 1 Access Graph

[Rl_Drive1Access_txt]
Meter=STRING
MeasureName=Mse_Drive1Access
X=(30 + #SidePadding#)
Y=18r
FontColor=#font1#
FontSize=7
FontFace=#Font1Name#
AntiAlias=#AA#
AutoScale=1
NumOfDecimals=1

[Rl_Drive1Access1]
Meter=Line
MeasureName=Mse_Drive1Access
X=(65 + #SidePadding#)
Y=0r
H=16
W=192
LineCount=1
LineColor=#color4#
AutoScale=1
AntiAlias=#AA#

[Rl_Drive1Access2]
Meter=Line
MeasureName=Mse_Drive1Access
X=0r
Y=0r
H=16
W=192
LineCount=1
LineColor=#color5#
AutoScale=1
AntiAlias=#AA#
In Rl_DriveNAccess1 and Rl_DriveNAccess2 AutoScale was set to 0. When I set them to 1, the graphs began to scale properly. I'm not sure why it was set to 0 in the first place.
User avatar
balala
Rainmeter Sage
Posts: 13345
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Silent crash

Post by balala »

dhmolson wrote: July 31st, 2021, 6:10 pm In Rl_DriveNAccess1 and Rl_DriveNAccess2 AutoScale was set to 0. When I set them to 1, the graphs began to scale properly. I'm not sure why it was set to 0 in the first place.
Glad if you got it working as expected. These settings depends on the author, so probably the author of ForceX skin thought it better this way.
User avatar
Yincognito
Rainmeter Sage
Posts: 4071
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Silent crash

Post by Yincognito »

dhmolson wrote: July 31st, 2021, 6:10 pm I think I found the issue with the ForceX System Monitor HDD skin that was causing the graphs to act strangely. Here is a portion of the skin:

Code: Select all

------------------------------------ HDD 1 Access Graph

[Rl_Drive1Access_txt]
Meter=STRING
MeasureName=Mse_Drive1Access
X=(30 + #SidePadding#)
Y=18r
FontColor=#font1#
FontSize=7
FontFace=#Font1Name#
AntiAlias=#AA#
AutoScale=1
NumOfDecimals=1

[Rl_Drive1Access1]
Meter=Line
MeasureName=Mse_Drive1Access
X=(65 + #SidePadding#)
Y=0r
H=16
W=192
LineCount=1
LineColor=#color4#
AutoScale=1
AntiAlias=#AA#

[Rl_Drive1Access2]
Meter=Line
MeasureName=Mse_Drive1Access
X=0r
Y=0r
H=16
W=192
LineCount=1
LineColor=#color5#
AutoScale=1
AntiAlias=#AA#
In Rl_DriveNAccess1 and Rl_DriveNAccess2 AutoScale was set to 0. When I set them to 1, the graphs began to scale properly. I'm not sure why it was set to 0 in the first place.
That was only a side of the issue, but if you want stuff to behave as it used to before, this is not the solution. Setting AutoScale=1 will make the graph to "fluctuate" vertically, depending on the maximum VISIBLE value of the graph, unlike the previous behavior of depending on the maximum EVER value of the graph. This might or might not be what you want. If it's not, adding:

Code: Select all

MaxValue=[Mse_DriveNAccessValues:MaxValue]
DynamicVariables=1
to every of your [Mse_DriveNAccess] measure (where N is your drive number, just like above) will use the past behavior for these meters. Yes, as you suspected, the issue was due to the quirks in using UsageMonitor: because we created a Calc measure to help with the autoscaling in the String meters, the MaxValue of the original UsageMonitor measure (which was very much set properly) has been "lost". Therefore, the above 2 lines retrieve that back.

P.S. This is an alternative to what you did, and normally should not be used at the same time with the other approach.
P.S.S. Sorry for not replying earlier, I've been busy with other things till now.
dhmolson
Posts: 16
Joined: July 26th, 2021, 10:59 pm

Re: Silent crash

Post by dhmolson »

Yincognito wrote: July 31st, 2021, 7:04 pm That was only a side of the issue, but if you want stuff to behave as it used to before, this is not the solution. Setting AutoScale=1 will make the graph to "fluctuate" vertically, depending on the maximum VISIBLE value of the graph, unlike the previous behavior of depending on the maximum EVER value of the graph. This might or might not be what you want. If it's not, adding:

Code: Select all

MaxValue=[Mse_DriveNAccessValues:MaxValue]
DynamicVariables=1
to every of your [Mse_DriveNAccess] measure (where N is your drive number, just like above) will use the past behavior for these meters. Yes, as you suspected, the issue was due to the quirks in using UsageMonitor: because we created a Calc measure to help with the autoscaling in the String meters, the MaxValue of the original UsageMonitor measure (which was very much set properly) has been "lost". Therefore, the above 2 lines retrieve that back.

P.S. This is an alternative to what you did, and normally should not be used at the same time with the other approach.
P.S.S. Sorry for not replying earlier, I've been busy with other things till now.
Awesome, I thought it was acting a little differently than before! Thanks so much for all of your help!