Multiple instances under multiple user setup cause ~20% CPU usage

[githubyouser]

My computer seems to be running a lot "hotter" recently, with the fan running almost constantly. I checked Task Manager and realized that Monitorian just seems to be sitting there eating CPU cycles.

It jumps up and down, but Monitorian uses between 20-30% of CPU constantly. I've been watching it for several minutes now, and it hasn't slowed down. I finally killed the process, because it's kinda problematic. Interestingly, if I then restart Monitorian it settles down to 0% CPU usage after the initial spike for checking monitors. I suspect that sleeping/resuming is what causes the runaway CPU usage.

I've also been experiencing mouse delays/stutters at login and never made the connection, but after searching through the issues here for performance issues, I see that that's also something that's been reported, so Monitorian might be relevant to that issue as well.

If you need any additional info, I'll be happy to supply it, please just let me know. Thank you for making this software available for free! I use it all the time and 99% of the time I never even think about it, it just works. :)

Specs:
Windows 11
Monitorian 4.9.1.0
ASUS TUF laptop
CPU: AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
Acer SA242Y external monitor (HDMI)

[emoacht]

Thank you for reporting.
I think I have never experienced such high CPU usage.
I have no idea but operation.log may help. How to produce the log is explained in Reporting section of readme.

[MagicAndre1981]

Use ETW to capture a trace with wpr.exe from an elevated command prompt (wpr -start CPU ENTER wait until usage dropped and run wpr -stop %USERPROFILE%\MonitorianPlusCPUUsage.etl -compress ENTER) and analyze it with Windows Performance Analyzer (WPA.exe).

[githubyouser]

Thank you for reporting. I think I have never experienced such high CPU usage. I have no idea but operation.log may help. How to produce the log is explained in Reporting section of readme.

Thanks, I've enabled Reporting, but I haven't seen the issue again yet. I've seen it at least twice in the past week or so, so hopefully I'll be able to catch it next time it happens.

[githubyouser]

So I left my laptop running and stepped away to eat supper (probably about an hour). When I returned, I could hear the CPU fans running as soon as I stepped into the room. The laptop and HDMI monitor were both sleeping and awoke as soon as I moved the mouse. I checked Task Manager, and sure enough Monitorian is using the CPU constantly again. Here's a copy of the operation.log

[githubyouser]

Use ETW to capture a trace with wpr.exe from an elevated command prompt (wpr -start CPU ENTER wait until usage dropped and run wpr -stop %USERPROFILE%\MonitorianPlusCPUUsage.etl -compress ENTER) and analyze it with Windows Performance Analyzer (WPA.exe).

Thanks, @MagicAndre1981 I tried running this for a while and then stopping it. It says "the trace was successfully saved" but no .etl file can be found in the directory. :( Not sure what to do about that.

[emoacht]

Thank you for the log.
I found the OS constantly fired display settings changed event.
So this issue happens when your PC suspends?

[MagicAndre1981]

look in your user folder C:\Users<USERNAME> , but it looks like emoacht already found the cause.

[githubyouser]

Thank you for the log. I found the OS constantly fired display settings changed event. So this issue happens when your PC suspends?

Thanks for looking into this for me! The display was asleep, but the computer itself was still awake, because the CPU was running hard.

[MagicAndre1981]

if you found the ETL file does it show anything usefull in callstack of monitorian?

[githubyouser]

if you found the ETL file does it show anything usefull in callstack of monitorian?

No ETL file is created. I tried twice. Not sure what else to try.

[MagicAndre1981]

hm, wired. You can replace %USERPROFILE% with a fixed path like C:\ETLTraces\ for example.

[emoacht]

@githubyouser So does it happen when the display is turned off but the system has not suspended yet?

[githubyouser]

@githubyouser So does it happen when the display is turned off but the system has not suspended yet?

Yes, that's correct. It just happened yesterday again, but I didn't have a chance to do anything about it because I was busy with other things.

[emoacht]

@githubyouser Thank you for the confirmation.
Ant additional information?

[githubyouser]

Hi @emoacht I haven't noticed it again till today. Then when I logged in to my other user account on the PC, I noticed almost right away that the fans were running hard and sure enough, Monitorian is chewing up ~30% of the CPU again. I tried running the trace again and saving to a different location as @MagicAndre1981 suggested, and this time I got an ETL file! It's 750MB. I took a look at it, but I don't really know what to look for. Any ideas?

[emoacht]

I am not an expert of that tool.
If you can identify names of methods that were called during the period, it might be helpful to understand what is happening.

[MagicAndre1981]

load the debug symbols (PDBs) and expand the full stack of minitorian to see what is called. On the point where the % Weight splitts you have the causing function call.

[githubyouser]

I just realized that I've been chasing a red herring. The cause of Monitorian's CPU usage is not sleeping, but switching between user accounts in Windows! I have 2 non admin user accounts on my PC and I regularly switch between them. (They both run Monitorian on login). If I don't log out but just switch to the other account, then the CPU usage immediately starts from Monitorian. It was camouflaged before, because logging in usually causes a bunch of CPU usage as various startup programs launch. So I wouldn't notice it till the PC was idle, and then realize that the CPU fans were still going.

I can reliably trigger the bug now by switching between user accounts without logging out of the first one.

[emoacht]

Thank you for update.
Could you run and upload operation.log as is?
I have not seen the clue of user session change in previously uploaded.

[githubyouser]

operation.log
Sure, here's a copy of the latest operation.log. I had killed the Monitorian process, so I had to start it again, and as soon as I started it, it went back to using ~30% of the CPU.

[emoacht]

Thank you for the log.
Could you disable "restore brightness on reconnection" and see if anything changes?

[githubyouser]

Could you disable "restore brightness on reconnection" and see if anything changes?

I disabled it in both user profiles but the issue still shows up. When I logged out from one profile, Monitorian's CPU usage immediately went back down to normal. So it only happens when both profiles are logged in and running Monitorian at the same time.

[emoacht]

I found that a preceding instance of this app prevents a succeeding instance from starting named pipe server and causes unauthorized access exception. Consequently, repetitive attemps to start named pipe server caused relatively high CPU usage. It only happens under multiple user setup.

I changed to stop the attempt if that exception is thown. See 3b154cc
A succeeding instance will run without CPU usage but it will no longer accept command-line option to get/set brightness/constrast.

[githubyouser]

Awesome, thanks so much for being responsive and helping me track down the bug and then fixing it!