Task dopus.exe eats all memory and 50% CPU

Running Dopus on Win7-64bit. Since about v10.2.0.0, and when I leave my computer alone for about 1.5 or 2 hours, the task dopus.exe as seen by Windows task manager has ALL remaining memory (about 6.5GB of 8GB) allocated to itself and happily does something which amounts to 50% CPU time on a quad-core Intel Q9550.

Closing Dopus sometimes not possible, [Not Responding] in title. Have to end the process. Then everthing goes to normal.

I installed every new v10.2.0.x beta in the hope this will go away, but it does not (have v10.2.0.5 now). Did some clean re-install too, no change. I have not replaced Windows Explorer, I do not have any new shell extensions that I know of. I can't remember happening that with 10.1 or 10.0.

What is Dopus doing in the background when computer is not used for a time?

Memory leaks are usually due to third party shell extensions, or sometimes video codecs (if you are dealing with folders containing video files).

We have written a guide with some suggestions on how to track down where the leak is occurring:

[ul][li]How to find components causing memory leaks[/li][/ul]

Since I updated to 10.0.2.0 I have observed two times that DOpus consumed all available memory leading to an error message from windows saying that a certain process runs out of memory (asking me if I want to close DOpus). Last time was today in the morning and DOpus took around 9 GB RAM before further messages appeared (Firefox crash etc.). I'm pretty sure that the working set doesn't increase step by step since I often check my free memory during development because I have 2-3 virtual machines running in parallel most time. On my development system I don't use any other DOpus plugin than the text/hex-viewer and I don't have any media files on the system. I have never seen that before (10.2.0.0) but it isn't an actual problem for me since I heavily use DOpus many hours per day and it only appears two times in the last weeks.

I just found the entry in my event log ...

Try the FAQ I linked above if you want to diagnose it.

Just telling us you're seeing a leak doesn't help much, and the leak is probably in a 3rd party component (else we'd all be seeing it, unless it's only in some obscure feature/configuration of Opus, in which case you'll need to work out what might trigger it for us to help; the FAQ should help you determine where the leak is coming from, either way).

Even if I have no idea how to reproduce it I thought it would be at least useful for you to know that other people are affected too. Particurlarly because there were no media files involved in my case. If I find out how to reproduce that, I will give you more details.

It's not useful at all to know without any information on what causes it, especially as it's almost always caused by something else you have installed, such as shell extensions, and not Opus itself.

HI.. since the last 2 betas, i have had this same bug. I found that it triggers when i leave the computer alone, usually around 30-60 minutes and then the memory is gone!. the thing is, that there is no listers open at all. and dopus.exe just eats up the memory until the system dies. If am using dopus, it doesn't do this.

this is what is said in my event viewer:


We need more information than that to do anything.

We have Opus running 24/7 on several machines without ever seeing a problem like this, so there must be other factors triggering it.

If you cannot trigger the leak on demand (which the guide linked above covers), then disabling 3rd party shell extensions using ShellExView is a good idea in case that helps pinpoint what might be causing the problem.

Looking at what else is happening on the machine (e.g. in the event logs) when the memory usage starts climbing is also a good idea.

18 April 2013
I am also getting this error. Directory Opus (Version 10.5.1.0) consumes all memory, ends up at 100%. If I close down Opus, immediately memory usage goes down to my usual, which is about 15%

Windows 7 64Bit 8GIG ram

Thanks
Luke

Please see the first reply.