30 November, 2018 at 4:44 am #1084
I noticed that with the latest versions (1.10.0-1.10.2) the cpu occupation is constant as if DesktopInfo were constantly
to query data regardless of the intervals set in the ini file, while this does not happen with version 1.9.2 and earlier. Moreover,
and I do not know if the two problems are connected, sometimes it hangs as if it did not respond (the background turns black)
and then start again after a few seconds. The problem occurs with both Windows 7 Home / Pro and Windows 10 Pro.
This is my ini file:
# see the readme.txt file for detailed information
# position on the screen
# total width
# width of the left column, -1 = auto
# background color
# background transparency, 100 = totally transparent
# right click context menu, 1 = allow, 0 = disallow
# allow user to drag with the mouse, 1 = allow, 0 = disallow
# language file
# how often, in seconds, to check ini file for changes
# debug logging
WMI=active:1,interval:0,lid:audiocontroller,namespace:root\cimv2,query:Win32_SoundDevice where Caption like ‘%Realtek%’,display:%Caption%
CPUUSAGE=active:1,interval:5,color:BD811B,chart:line linear 100 1 BD811B,threshold1:1 95 0000FF,count:8,display:Total: %1%
PROCESSCOUNT=active:1,interval:5,threshold1:1 90 0000FF,display:%1
TOPPROCESSCPU=active:1,interval:5,threshold1:3 90 0000FF,display:%1 (pid:%2) %3%
TOPPROCESSMEM=active:1,interval:5,display:%1 (pid:%2) %3[1.0b]B
PHYSICALRAM=active:1,interval:5,color:BD811B,threshold1:3 90 0000FF,display:%1[2.0m]MiB / %2[2.0m]MiB (%3% used)
VIRTUALMEMORY=active:1,interval:5,threshold1:3 90 0000FF,display:%1[2.0m]MiB / %2[2.0m]MiB (%3% used)
PAGEFILE=active:1,interval:5,threshold1:3 90 0000FF,display:%1[2.0m]MiB / %2[2.0m]MiB (%3% used)
FIXEDDISK=active:1,interval:60,color:BD811B,threshold1:8 -10 0000FF,count:2,display:%1: %4[4.2b]B / %5[4.2b]B (%8% free),filter:
Can you tell me something about it?
30 November, 2018 at 9:14 am #1087
In the wmi query you should use double quotes in the where clause.
I get zero percent cpu when I run your ini in v1.10.2 and it runs without a problem. It’s possible the quotes thing could be the cause. See if that fixes it. Otherwise, you should resort to the standard debug method of disabling items until it stops misbehaving.0
3 December, 2018 at 11:41 pm #1103
Finally I managed to do some tests, as regards the problem of temporary block in which it seems not to respond (with the background that turns black) the cause is the CPUUSAGE parameter, and the problem occurs at startup or when you update manually or following some event (eg by inserting a usb drive).
The other problem of the continuous use of the CPU depends on the parameter FIXEDDISK, but this behavior started only in the PC that I use at work, where I launch DesktopInfo with the SYSTEM user to have visibility of all the processes in memory with the parameters TOPPROCESSCPU and TOPPROCESSMEM, but I do not know if this can be the problem.
Let me know if you need more information.0
4 December, 2018 at 8:00 am #1105
5 December, 2018 at 2:59 am #1110
I have attached the log where, however, no problem is detected. I have also attached an animated gif that I created from my desktop that shows the strange behavior of DesktopInfo that I have described.
5 December, 2018 at 3:07 am #1112
5 December, 2018 at 10:01 am #1114
does it correct itself? how long does it take from startup to when it settles down?0
5 December, 2018 at 7:29 pm #1117
Yes, it correct itself in about 5-6 seconds from the startup, and this behavior is repeated every time an event causes the update of the DesktopInfo window (eg the insertion of a usb disk). If, on the other hand, the CPUUSAGE parameter is disabled, it no longer does so.0
5 December, 2018 at 10:54 pm #1118
Ok. so it sounds like the CPUUSAGE is triggering a heavy cpu load for up to 5 seconds and, judging by your gif, it is related to a wmi query which is weird because there are no wmi calls in cpuusage.
I haven’t been able to reproduce it here.0
6 December, 2018 at 9:50 am #1120
I have to make further checks but it seems that the problem is related to the (not) loading of the language file. I will do other tests to be sure.0
8 December, 2018 at 3:29 am #1132
9 January, 2019 at 6:53 pm #1321
I would be interested to know if this is still a problem with v1.11 or v1.12 with the threading in place.0
10 January, 2019 at 5:48 am #1322
I’ll let you know as soon as I can try version 1.120