DO11: Memory Leak?

I've been using the betas since the first one was released. I don't normally use betas but DO is the number one tool I use and I just can't wait to see what's new.

Since the install of 11.0.7.0, I've been noticing that my computer has been experiencing some slow response times. As I installed a few different things around the same time and we had another MS update, I waited to see what would shake out. Today, I finally tried to track down what was making everything so horribly slow. I have 16GB of RAM in a brand new HP laptop. Imagine my surprise when I discovered that DO was using 12.6GB of that memory!

Has anyone else reported similar problems? When I killed the dopus.exe process, the memory all got released, but I usually have listers open and now can't do that.

dkoppy
"Those who aren't willing to help solve the problem, don't have the right to bitch about it."

Our guide, How to find components causing memory leaks, may help you track down the cause of the problem.

Okey, I've followed the instructions in the document. When I have VMMap64 running, the drain still happens but it appears to be from the VMMap64 process rather than dopus.exe. When I look in the stack, though, I don't see anything other than Windows processes, and there aren't any entries that are extraordinarily large. The largest one is VirtualProtextEx, which never goes above 65594 bytes (byte size?). Inside that are just a bunch of KERNELBASE.dll and ntdll.dll entries. The next largest entry is about 7K. Everything looks normal, but the machine is horribly unresponsive and 95% - 98% of the RAM shows used in VMMap64 (or dopus.exe if I don't start it in the memory manager).

Any suggestions of what to do next?

Thanks.

I've now tried turning all of my startup programs off. The problem still persists. When I look at the VMMap stack, it doesn't actually show a lot of memory being used. Besides the VirtualProtextEx, the next highest entries all have the KERNELBASE.dll and ntdll.dll entries and dopuslib.dll. No other exes or dlls show in the list.

I'm now going to try going back to beta 6 or 7, before the problem began.

Jon:

Can I get a copy of the beta 6 and beta 7 install kits? I can't find the ones I used and would like to test my problem with earlier versions to see if this problem has been here all along.

Thanks.

I don't think we have the older betas available any more, but I can check. I seriously doubt this is anything new that has crept in recently.

Why are you looking at VMMap in itself? You need to look at dopus.exe as shown in Leo's guide.

The guide says: "Use the standard Task Manager to keep an eye on dopus.exe's memory usage so you can tell when you've triggered the leak." When I run dopus.exe through VMMap.exe, the process that is holding all of the RAM, sometimes 12GB or more, isn't dopus.exe. It's VMMap.exe. In any case, when I look at the trace and stack, what I see isn't any other application running on my computer - its dopuslib.dll.

In any case, this problem is solved!

I have DO running on the affected machine (my laptop) and on another system (my desktop). The desktop doesn't exhibit the behavior and memory levels are normal. The two computers are both running Windows 8.1 and I have the same applications installed and running on both systems. I' was going to look at what is different between them to see if I could find the offending program. As the laptop is an HP system, with the attendant HP utilities running, I was starting to suspect one of these utilities.

Before I could start on that, though, I was struck by another possibility - that it had something to do with 32-bit memory mapping. I don't know much about this, but as I mentioned in an earlier post, the top process in the VMMap.exe trace after I'd captured data with the leak was VirtualProtextEx. This was always a byte size of 65594. I tried an experiment and loaded VMware Workstation and started a Windows 8.1 virtual machine. Workstation started fine and loaded the VM, but when it actually tried to start it, I got an error message that the virtualization setting in the BIOS wasn't turned on. I remembered that a couple of weeks ago, my HP utility software notified me that there was a BIOS update. I approved the installation, the system rebooted, and everything worked fine. Today, I rebooted to double checked this, and discovered that the BIOS update apparently had disabled it. When I reenabled it and restarted the system, the DOpus problem was gone. I've been running Opus for several hours with no memory issues. Unless something comes up, I guess this is fixed.

So, the moral here, for anyone experiencing an apparent memory drain by Opus, is - check your BIOS settings and be SURE that the Virtualization Technology or 64-bit Virtualization or whatever your particular system calls this feature, is ENABLED!

Thanks to Jon and everyone else who assisted me on this. I didn't realize until the last few days of wrestling with this, how much I depend on Directory Opus. Having to shut it down every time I wasn't using it was not only irritating, but seriously impacted my work flow.

Opus doesn't use virtualisation hardware so that seems like a coincidence, unless it's due to a shell extension from someyhing else that leaks memory when it's disabled.

It's normal for VMMap to use a lot of memory when tracking allocations, since all the records of allocations take up a lot of memory.