Can you post a screenshot of the stack window?
EDIT: See correction in next post. I misinterpreted what was in the screenshot at first.
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.
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.)
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.
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
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 firstname.lastname@example.org 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.
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.
Thanks for the info on renaming .EXE files, but that option won't work for me.
I clicked on the EXT column, to order Extensions to see the EXE files all in one place.
Six minutes later, after watching Opus 10 go to white, black, etc., I gave up. Even the computer clock does not update during this usage.
It's faster to turn off the computer and reboot.
It's back to Version 9.5.6.
I've been using Opus since 2004, and never had a problem like this with any versions except Opus 10.
You could exit Opus and rename them using Explorer, then see if it fixes the problem.
Or just wait until the next update. If it's the same problem Geoff was having then it's already fixed, pending the next update. But if not, we'll investigate it if you can narrow down which file(s) are causing it.
Clarification, please, on renaming EXE files.
Do I rename EXE files showing in the Lister?
Or ones that are in use on the computer?
The ones showing up in the Lister.
As an alternative (e.g. if renaming the files isn't an option because they're in use), you could also make Opus open a lister open showing a different, empty folder, then copy the files into it one by one (or a few at a time) to see which file triggers the problem.
e.g. With Opus not running, make an empty folder, right-click it and choose Open in Directory Opus. That should open Opus showing the empty folder.
(If you get high CPU usage viewing an empty folder, it could still be because there's a problem file in one of the folders the folder tree is showing. They'll be scanned to see if any are archives which should appear in the tree. There are ways to prevent that being scanned, but I'll avoid complicating things for now.)
Assuming the empty folder doesn't trigger the problem, you can use Explorer to start copying files from the problem dir, into the empty dir, to see which file triggers the problem.
(It may not be an EXE file, but you might as well start with those.)
I really hate to post in a thread a few months old but I am having very similar problems in DOpus 10. High CPU at times - actually most any time I change folders in DOpus. Most CPU used after performing most file operations, e.g., copy or move files. It has been getting progressively worse with each beta version, so I decided to stick to the stable version. But it isn't any better at all.
I did post a separate thread about this and got one reply with some questions. I replied with answers but never got any more replies.
I know that most all such problems seem to be due to "something else on your system" and yet I didn't have any of these problems with DOpus 9; they all appeared with DOpus 10. Maybe my system just doesn’t get along with whatever is so different in DOpus 10. I'm very close to just uninstalling and reinstalling DOpus 9.56, the last version that worked for me. As it is now I have to end the dopus.exe process and open another file organizer to get the things done that I did with DOpus for the last three or four years.
Thanks for any help with this.
System: Windows 7 Home Premium, AMD Athlon 64 X2 4400+, 2200.0 MHz, 4 GB RAM
DOpus Version 10.0.1.0.4185.x86 6/17/2011 12:39:45 PM
It's unlikely your problem and the problem the thread is about are the same, except for the symptom of high CPU usage. Bumping your old thread would've made more sense. Now the info about your problem is in two different places. (But also note this isn't an official support forum. If people don't have spare time or any ideas, you might not get a reply.)
For anyone else trying to follow this, here is the other thread which was mentioned:
[ul][li]DOpus 10 High CPU After Move or Copy Action[/li][/ul]
Is it happening when you change folders, or when you copy files, or both?
If it's both then the files (the ones in those folders, and the ones being copied) are probably triggering a bug in something that Opus uses to get information about the files. You mentioned PDF and Word documents in the other thread, so I'd guess it's a shell extension for extracting document information. Opus 10 will use them while Opus 9 ignored them. That's probably your difference.
Download the latest beta version of Opus (10.0.1.5 is linked in my signature) and install that.
Also download the latest version of ShellExView and run that. Sort by the Type column and see which MetaData and Property Handler extensions are installed on your system. Especially any non-Microsoft ones. They may point to the component that's causing the problem.
NOTE: Disabling them in ShellExView only affects Explorer, not Opus, as far as I can tell. So that won't help.
CORRECTION: Disabling the handlers via ShellExView does affect Opus (at least provided you have the latest version), but it looks like you have to exit and restart Opus for the change to take effect.