High CPU usage, message 033920 = 0x08480

I have a similar issue with high CPU usage and I got a "Received message 033920 = 0x08480". Running the beta with the fix, but the issue persists. My config doesn't use toolbars in the same row and I don't use the folder tree.

How do I track down the cause?

The high CPU usages takes a while to take in and once it does Opus paints the toolbars visibly slowly, besides being sluggish in other ways.

I've moved this into its own thread as it's not the same issue at all. (One symptom in common, but not the same root cause.)

Please post a screenshot of the "Received message 033920 = 0x08480" message.

That sounds like something coming from another component, rather than Opus. The screenshot might help identify it.

Please also check here in case they provide solutions:

You can also send process snapshots to us which can sometimes be used to detect where high CPU usage is coming from (whether it's Opus itself, or something else):

For the last one, please follow the instructions carefully, as almost nobody does. :slight_smile:

As a mitigation, I have been using an AHK script that suspends Opus' process when it is in background and resumes it when on foreground. Does these illegal messages still get processed if they are sent when Opus is suspended?

I will try to take the snapshots correctly. :sweat_smile:

I didn't realise we were talking about the WindowMessageReporter.

If that's indicating something is sending messages in the WM_APP range to random windows on the system then it's something that needs to be fixed, as that could cause absolutely anything to happen, depending on what meaning those messages have to different software.

That particular message, with current versions of Opus, would probably just cause memory leaks, but if the same thing is sending other WM_APP messages then it could be causing other problems, and it may also cause bigger problems with other software, or other versions of Opus (the message numbers can move around between versions).

Unfortunately, Windows does not provide a way to determine the sender of a message, and the only way I know of to track it down is trial and error. I'd focus on things that run in the background (e.g. system tray apps) or that modify other software, as they're most often the things sending messages between processes. Things like AHK scripts can also send messages and might be worth checking.

I don't know. It'd depend on how it's being suspended. Better to find the cause than mitigate it in ways that potentially cause more problems.