Excessive cpu util from dopuslib.dll!DoesExeFileContainZip

Hi,
I am using 10.0.5.0.4497.x86 on Windows XP and having an issue with Dopus hanging when I open new windows or enter directories
I have looked at what is going on with Process Explorer and found dopuslib.dll frequently consuming cycles in DoesExeFileContainZip

Just in case it would help I disabled internal zip support and restarted dopus but that has not stopped that function being called

Any suggestions ?

Thanks

Please see Crash, exit or high CPU usage when viewing certain directories for suggestions on tracking down the cause/trigger.

(DoesExeFileContainZip is a red herring from Process Explorer. It is just the nearest named/exported function in dopuslib.dll to the code Process Explorer is interested in. The offset Process Explorer reports is probably a large number, putting the code well outside of DoesExeFileContainZip itself, but Process Explorer has no info on any nearer functions so that's the best it can do. It will report most of the DLL as being DoesExeFileContainZip plus some offset.)

Thanks Leo I will take a look at your FAQ references

As a suggestion perhaps the devs could consider some other relevant/problematic functions to be exported so that the 'simple' option of just looking at Process Explorer could help narrow the problem area down rather than just be a hit on a non relevant.
I doubt it would help people trying to hack/crack dopus (unless they exported functions like check_license or call_home) but it would help support the software

Using current beta (10.0.5.1.4517.x86) and working my way through the suggestions, high cpu utilisation / apparent hang is still happening so far
The offset so that someone in the dev team could perhaps comment on which area in the code might be related is DoesExeFileContainZip+0x4ddd2

Working out which file(s) or filetypes trigger the problem will be way more important than working out which function is on the stack when it happens. (Which isn't something I can find out very easily, and the person who can isn't around today.)

It seemed to be more system wide rather than a particular directory as it would happen when I first opened dopus, so far...

Removing a network drive that is only available with a VPN

  • had a minor effect

Deleting my file collection

  • a bit more noticable effect but still pauses

Uninstalled Acronis

  • seems snappy again (for now at least)

The Acronis True Image shell extension has caused several people (myself included before I stopped using True Image entirely) problems in both Opus and Explorer so it could well be that.

Please let us know if the problem stays away for a few days, in case it's just a coincidence. If it does we might look at blocking the Acronis True Image extension by default, as it seems to cause more problems than it is worth.

Leo,
It wasnt the shell extension at all, I ditched all the shell extensions (using the option so dopus doesnt load them by default, shift to activate) and found no difference at all
Then I used the nirsoft ShellExView tool to go through and disable loads of things I dont actively use (to rule them out) and no difference

I had an old version of True Image 10 installed that I dont use and wasnt working so I downloaded the TI manual cleaner for v10 to uninstall it
After running that cleaner I noticed the TI disk filters still in place in the upperfilter keys so I nuked them out of the relevant registry keys
The version 10 cleaner instructions didnt mention the disk filters but the version 11 cleaner did, I checked just in case...

It was only after completely nuking TI (and rebooting twice to make sure the drivers etc were not active) that my 'pauses' have stopped

I am still seeing some relatively short enumeration pauses on entry to "My Documents" and that is wrong (coming from an SSD)
However compared to minutes of high cpu utilisation (effectively hangs) this is such a massive improvement I am not sure I care (for now)

What "function" was it getting stuck in btw ?

Based on my last "eliminate by removing test" it could potentially have been anything at all that read from disk
I had noticed that locking was involved in the stack traces (one of the reasons I ditched TI entirely because it was potentially in the code path)

Oh, interesting that it's the Acronis disk filter. I don't think we can block those as they are too low-level and not something we call directly. The Windows API itself calls them when we call it.

I don't know which Opus function it was (I don't have the relevant symbols & it'd take several hours to get them) but Opus doesn't call disk filters directly anyway; the Windows API further up the stack would be more relevant.

I suspect Opus just happened to be calling the right APIs on the right threads to trigger a bug in that version of the Acronis disk filter.

Leo,
Sadly I was wrong and it was only a temporary reprieve... the high cpu has continued to happen
Removing that filter did seem to help at the time (I realised later that I did also have the AV disabled during that last test)
It is better since removing the filter but the problem still happens, so the acronis filter was most likely contributing by slowing things down

Any chance of getting information from the position in the stack, that would be preferable than your chase a needle in the haystack approach if it reveals the best place to look at the start

What's the full stack tracks? Which system APIs is it inside?

(Please make the stack trace with the Acronis filter still disabled so we can discount the influence of that.)