CPU usage increase

I installed Ver 10 over 9 and all went well. However I have noticed that when I boot the computer and Opus10 loads, all is well.
However when I double click on the desktop to open Opus my CPU usage increases to 50%. I checked in Task Manager and one of the 2 cores is running at 100%.
Even with this hi constant CPU usage Opus works well but the CPU gets a rather warm.
Closing Opus does not help, I have to end dopus.exe to bring CPU usage back to normal. Ver 9 did not exhibit this problem.
Any ideas please?

[ul][li]Crash, exit or high CPU usage when viewing certain directories[/li][/ul]

Thanks leo, but the only thing that has changed is the version of Opus.
Opus has not crashed or does not operate slowly, erratically or in any way unusual. Just high CPU usage.
Many users would not realise it is happening, I just happen to have a CPU Monitor on the desktop and a CPU temperature indicator in the task bar.
Houston, I think you have a problem.
I will disable plugins and do the snooping suggested in your link and let you know the results if any.

As just one example, Opus 10 can use IThumbnailProvider shell extensions now, so the list of things installed on your system that might mess things up is increased.

I have a CPU monitor as well and I can assure you that sustained 50% CPU usage just from opening Desktop is not normal. It's something on your system triggering a bug somewhere. (The bug could be in Opus, but it's more likely to be in a shell extension, video codec, etc., and either way the trigger needs to be found before anyone can suggest/investigate further.)

BTW, is Opus responsive while the CPU usage is happening? There is a bug we're investigating at the moment that causes the tree to redraw itself over and over with a very specific combination of settings, so you might be seeing that, but if you were the tree would not work so you'd know it.

Also, you can use Process Explorer to find out which code/module is using the CPU. Right-click dopus.exe, then Properties, go to the Threads tab, find the thread with the high CPU usage, then click Stack to get a list of the DLLs involved. It's usually the last non-Windows DLL that's to blame, although it isn't definitive.

Thanks leo, I'll try process explorer.
Opus is responsive while all this is going on.
I disabled all plugins, restarted Opus and the same 50%.
I backed up some files (over 100,000) on my system from one drive to my backup drive and CPU usage gradually rose to 100% and stayed there even after the copy process had finished. I closed dopus.exe and restarted it and back to 50%.

I tried Process Explorer and it seems that dopuslib.dll is the culprit 49.44%

Can you post a screenshot of the stack window?

OK leo, I hope this helps


EDIT: See correction in next post. I misinterpreted what was in the screenshot at first.

Thanks!

That does look like a bug in Opus, and it's being triggered by Opus trying to scan one of the EXE files in the directory you are viewing to see if it's a self-extracting zip file.

  1. What's the date on your dopus.exe? If it's dated April rather than May, re-download Opus and see if that fixes things. There was an 'out-of-band' update to fix an issue with the EXE scanning and that fix might be all you need. (Until now, we'd only seen one EXE that triggered it, and the problem was sligthly different.)

  2. If that doesn't help, could you narrow down which EXE is triggering the problem and attach it to the thread (or to a private message if it's not an EXE you want to post publicly)? Then we can look at it and work out what's going wrong.

Sorry for the run-around until now! These problems are usually not in Opus itself, but this one clearly is.

CORRECTION: It's not to do with the zip-file scanning. The "DoexExeFileContainZip" name is a red-herring; it's just the nearest function to where the code is that Process Explorer knows about. (The offsets are really far away from that function.)

Could you post the following info:

  • The same (or similar) screenshot but with stack window + columns wider so the full Start Address column can be seen.
  • The version number and date from Help->About in Opus.

That information should allow us to look-up which code is actually being run there.

Thanks!

Thanks leo
The Version is 10.0.0.0.4137.x86 and the date is 30/4/2011:11:40:05 AM.
I'll post the other after I drop the kids at school.

Leo, I tried the latest version of the installer (it was about 300KB larger) but the result is the same.
Attached is the screen shot of the later version


Hi leo,
I have found the offending .exe file, a Divx installer.
Do you want me to send a copy of this to Jon so he can have a look?
It's a 24MB file

Yes please, or to leo@pretentiousname.com and I'll pass it on. Whichever is easier.

BTW, if it's no trouble, could you open process explorer again, select the high CPU thread and thrn push the Stack button? I only just realised we were looking at the list of threads, not the stack for the thread we're interested in (both look very similar; wasn't until I saw all the numbers at the end were the same in the last shot that I realised).

Thanks for all your time. Hopefully we're almost there.

Email sent to you leo.
Attached is the stack info.
Thanks for sticking with the problem, I reckon we have it beat. DOpus10 is back to sensational, where it belongs.


Many thanks, Geoff!

With the file you provided I was able to reproduce the problem and a fix has been written which will be included in the next update.

Cool, thanks leo.

I have a similar problem with high CPU usage. About 25%. However, my computer becomes almost totally unresponsive.
It took 11 minutes to get a screen shot using Process Explorer to see the Threads involved.

Gads. I cannot think this morning. Cannot figure out how to put a screen shot here.
So I added an upload attachment. Maybe that will work.
Meanwhile, I have to uninstall Opus 10 and go back to 9 again.

Ted


Hi Ted
Your problem looks remarkably similar to mine.
Leo has the fix that will be included in the next update.
FYI to find the file that was causing me grief, I tried adding .old to the end of each .exe in the lister (not folders or sub-folders) until I found the one that could not be renamed because Opus was using it. It was not an important file so I moved it to a little used partition. Problem alleviated.