Wow, sounds really easy to reproduce...
very professional attitude! 
Thanks, you input is appreciated.
very professional attitude! [/quote]
Professionals are not allowed to use sarcasm?
very professional attitude! [/quote]
Professionals are not allowed to use sarcasm?[/quote]
sure they can. after they fix their product instead of having the 'only we can be right' attitude. dopus is an awesome product. they invest a lot of time and effort into support which is such a waste since this is probably the worst and rudest support I've ever seen. i'm terribly sorry if this will be taken as an insult, but that is how i feel.
Posting this for the 2nd time. First post was not passed by the moderators for some reason.
I am a brand new Dopus user chiming in with my experience.
I had installed Opus V11 on Win7 x64 a while back, had a quick look at it but have never really used it. Last week it popped up a reminder that my trial was expiring so I pasted in the certificate which didn't work because it need to be upgraded to V11. Running out of time, I left it sitting there over the weekend with the licence window open and by Monday morning dopus.exe had consumed 7GB (out of 12GB) of memory! Windows had popped up a low memory warning suggesting I close dopus.exe, Chrome browser had crashed and my desktop had turned black. 
I had left 3 Win->Win RDP sessions open on this machine, and I had also RDP'd to this machine from home (also Win->Win) over the weekend, quite possibly leaving the connection open for an extended period. uTorrent was not running. I am fairly sure that's the first time I've left Dopus running over the weekend, and the first time this issue has ocurred.
Thanks a lot for your report beatbox20. It seems that we can rule out uTorrent as a cause, not that I ever thought it was. Can you tell us if you had anything else running? You mention Chrome, but I didn't have that installed on my test VM.
I had a vague idea that it might be related to keeping RDP open for a very long time, or keeping it open and sleeping the client machine, then waking it up again. Maybe Opus has issues trying to render its GUI when the RDP session is not properly disconnected or something.
To be honest I don't even know why I'm bothering to try and diagnose this problem any more. It won't be fixed in Opus 10 so I won't benefit, and I don't pay for bug fixes that I helped solve on principal. Still, when it inevitably happens again I might as well post some data.
If you can give us enough information to be able to reproduce it and it really is a bug in Opus and not some other component then we'll be happy to give you a free upgrade to 11.
To the complaints about Jon's sarcasm, note that earlier in the thread it was said: I can reproduce it somewhat reliably by running uTorrent in the same VM.
Through the thread we've had complaints that we are not taking this issue seriously because we can't reproduce it when it's apparently easy to reproduce. The assumption is that we don't care or aren't even trying, which is not true. So then when we finally get some steps to try to reproduce it, and spend a long time trying but still can't, we're told it isn't actually that easy to reproduce... That's a bit frustrating.
(And still only two or three people have ever seen it, if it is the same issue for each person, which it may not be. We've seen before things like the Acronis True Image shell extension leaking 2GB of RAM if you go into a folder with the wrong type of file in it. Any code that is loaded into the Opus process can do the same while the leak is attributed to dopus.exe.)
How many times did you check the stack trace?
Was it always literally the same thing?
Yes. Believe me, I've done everything I can think of and spent a lot of time trying to find all possible things that the stack trace might represent. Unfortunately it didn't get anywhere.
The (very rare) issue with filesystem changes that happen faster than they can be processed is still there, so if this is just that issue then it's already on our roadmap. But that would not be triggered by normal activity or just a few bit torrents like mojo-chan suggested, so we don't know if it is really the same issue (or if it is, if it's the cause of the problem for both of you, or if you're each seeing separate issues).
A flood of filesystem changes would also not cause memory usage to stay high unless the flood never stopped, because when things return to normal the backlog is processed. If you are experiencing a flood of filesystem changes which never stop then it is easy to discover by using Process Monitor, so that's an easy theory to test. If there is such a non-stop flood, whatever is causing it will also be slowing down the whole system.
We could make a special debug version that prints out the number of elements when freeing collections, which might also help. I'm not sure if we have a good way to indicate what the collections contain, however.
[quote="leo"]How many times did you check the stack trace?
Was it always literally the same thing?[/quote]
well, it was a month ago, but I'm sure that I've checked more than once with a distance of few minutes (as this is not the first time I'm trying to catch something using this technique). yup, the call stack was the same (the thread was not suspended as it was the only one that actually spent time).
Yes. Believe me, I've done everything I can think of and spent a lot of time trying to find all possible things that the stack trace might represent. Unfortunately it didn't get anywhere.[/quote]
ok, sorry
well, it's difficult to suggest that as it highly depends on the internal design. 
if your question is valid, do typeid(x).name() on element when some size threshold is reached.
It happened again while I was connected remotely from home. Unfortunately I wasn't paying close attention but it happened something like this. Dopus.exe memory started growing slowly in 4k increments (didn't watch this for long so it may or may not be relevant). Minimized the RDP window for maybe an hour or more, looked again it was around 2GB. Minimized the RDP window again for an hour or two, looked again it was around 4GB. After that I think I just closed it down.
This PC is running RDP 8.0 server and RDC 8.1 client.
Here is a list of the other processes normally running on my PC. It may not be precisely the same as what was running when the memory issue occurred, but it would be pretty close.
Process Working Set PID
System Idle Process 24 K 0
System 14,160 K 4
Interrupts 0 K n/a
smss.exe 1,452 K 348
csrss.exe 7,068 K 576
wininit.exe 5,072 K 660
services.exe 15,264 K 716
svchost.exe 13,308 K 892
WmiPrvSE.exe 9,336 K 3816
explorer.exe 55,152 K 11208
nvvsvc.exe 8,772 K 956
nvxdsync.exe 21,756 K 5076
nvtray.exe 15,588 K 6172
nvvsvc.exe 14,492 K 5088
nvvsvc.exe 13,712 K 11344
nvxdsync.exe 17,872 K 8960
nvSCPAPISvr.exe 6,072 K 980
svchost.exe 13,632 K 140
atiesrxx.exe 5,176 K 584
atieclxx.exe 8,032 K 5064
atieclxx.exe 6,744 K 10304
svchost.exe 32,232 K 428
audiodg.exe 18,256 K 1664
svchost.exe 21,768 K 1040
dwm.exe 5,020 K 4392
svchost.exe 58,932 K 1080
svchost.exe 349,260 K 1108
taskeng.exe 7,768 K 4800
iSCSIAgent.exe 10,512 K 4652
taskeng.exe 6,040 K 11392
rundll32.exe 11,140 K 11756
wuauclt.exe 7,300 K 7888
svchost.exe 15,352 K 1236
svchost.exe 496,028 K 1480
rdpclip.exe 7,688 K 8044
spoolsv.exe 29,860 K 1656
svchost.exe 19,080 K 1688
armsvc.exe 4,000 K 1828
AppleMobileDeviceService.exe 9,884 K 1852
mDNSResponder.exe 7,776 K 1880
ccsvchst.exe 18,712 K 1932
ccsvchst.exe 15,280 K 4244
mdm.exe 5,776 K 1996
svchost.exe 4,120 K 1256
SMSvcHost.exe 35,228 K 1460
nis.exe 13,096 K 1428
nis.exe 9,904 K 2296
NMSAccessU.exe 3,196 K 2032
svchost.exe 4,092 K 2072
snmp.exe 6,480 K 2168
sqlwriter.exe 9,896 K 2204
svchost.exe 13,244 K 2232
svchost.exe 96,372 K 2256
vmnat.exe 5,424 K 2336
vmnetdhcp.exe 10,520 K 2412
vmware-usbarbitrator64.exe 8,924 K 2456
vmware-authd.exe 10,128 K 2596
SearchIndexer.exe 46,156 K 3376
WseClientMonitorSvc.exe 75,556 K 3788
svchost.exe 6,076 K 3928
taskhost.exe 21,640 K 4620
svchost.exe 9,248 K 5384
iPodService.exe 8,016 K 6568
daemonu.exe 13,012 K 6392
svchost.exe 15,876 K 6736
taskhost.exe 16,472 K 8680
WmiApSrv.exe 7,176 K 6520
TrustedInstaller.exe 11,732 K 9064
lsass.exe 29,212 K 728
lsm.exe 9,004 K 736
csrss.exe 23,888 K 672
winlogon.exe 8,832 K 776
explorer.exe 127,240 K 4660
RAVCpl64.exe 17,692 K 5232
wmdc.exe 8,020 K 5300
ZuneLauncher.exe 6,800 K 5320
itype.exe 1,444 K 5344
EssentialPIM.exe 42,884 K 5532
sidebar.exe 34,108 K 5620
DesktopOK_x64.exe 25,924 K 5716
5 Minute Break.exe 6,344 K 5788
netsession_win.exe 12,548 K 5836
netsession_win.exe 20,616 K 5888
SpotifyWebHelper.exe 8,064 K 5844
EvernoteClipper.exe 7,008 K 5932
EvernoteTray.exe 8,528 K 5976
Evernote.exe 51,212 K 4068
PNotes.exe 15,244 K 6024
splwow64.exe 11,472 K 6100
procexp.exe 6,408 K 6112
PROCEXP64.exe 62,112 K 444
OUTLOOK.EXE 283,120 K 7464
AcroRd32.exe 21,568 K 7848
AcroRd32.exe 161,364 K 8476
mstsc.exe 277,104 K 2432
Everything.exe 43,096 K 5256
dopus.exe 55,696 K 2020
chrome.exe 179,504 K 9708
mstsc.exe 48,524 K 2520
TOTALCMD64.EXE 34,480 K 10236
USB_Disk_Eject.exe 15,492 K 10260
mstsc.exe 189,964 K 10068
nusb3mon.exe 6,920 K 6032
iTunesHelper.exe 13,044 K 5460
VCDDaemon.exe 6,392 K 5604
jusched.exe 15,424 K 5928
jucheck.exe 14,464 K 6584
Dropbox.exe 103,588 K 4248
mmc.exe 77,088 K 10740
firefox.exe 619,876 K 10392
plugin-container.exe 29,332 K 7368
FlashPlayerPlugin_13_0_0_214.exe 12,804 K 10596
FlashPlayerPlugin_13_0_0_214.exe 33,424 K 5412
SkyDrive.exe 41,312 K 12044
csrss.exe 13,376 K 11312
winlogon.exe 7,472 K 6076
LogonUI.exe 24,180 K 5044
Notepad2.exe 10,160 K 6984
A watched pot never boils, now I have a plan and am waiting for it.
I am including the link below even though it is for a different program. I am thinking that both Dopus and Reflect are looking at all the connected drives so MAYBE there is some commonality.
Yes a watch pot never boils indeed. Dopus.exe has been as good as gold since the last incident.
Did we have any processes in common?
Let me know if you want me to run any parallel experiments
Okay, it finally happened. Opus is using half a gigabyte of RAM with one window open. Every time I re-start the RDP session the amount of RAM used doubles.
Unfortunately this isn't my minimal test VM, it's my in-use server. It is quite minimal though. The only things installed are drivers, Firefox, Java, Cumulus, PS3 Media Server, Microsoft Security Essentials (real-time scanning disabled), Dropbox and uTorrent. No codecs installed. The system is running, for now I can do more diagnostics but I probably only have one or two more RDP sessions before it eats all my RAM.
Here is the VMMap dump: mega.co.nz/#!tIwmnQKS!cKce6CZUi ... X_D2GnIfm4
It looks like the bulk of the memory use is the heap.
Sorry, forgot to add Classic Start Menu is installed. It wasn't installed in the VM though, so I think we can rule that out along with all the other stuff.
As for triggers I'd say either a heavy uTorrent session or perhaps closing the RDP session with an Opus window open displaying a drive that subsequently went into power saving mode (spun down). Normally Opus uses about 15MB of RAM and I noticed it climbing earlier today. The system has been up for about four days (rebooted to do some Windows updates).
DOpus goes to 100% CPU for about 20 seconds, doubles it's RAM usage and then settles down every time I open RDP. I need to kill it soon so I can use the machine.
Is everyone taking an early holiday this year? 
If reconnecting the RDP session is a reliable trigger then we're definitely getting somewhere.
Please generate a VMMap trace (different to the VMMap snapshot posted above).
Using VMMap on the remote machine (where the leak is), starting the trace, then disconnect and reconnect the RDP session with the trace still running. If the leak is triggered while the trace is running then the trace should then tell us which EXE or DLL allocated the memory (and hopefully more).
Also, please let us know the details of the RDP set up (e.g. which resources the RDP client is configured to share between the two machines, and other RDP client settings; also the versions of Windows on each machine) so we can try recreating a similar setup.
It may also be worth checking if the problem depends on what is in the clipboard when you make the RDP connection. e.g. If there is a small amount of text in the clipboard, does it still happen? Or does it only happen if files are in the clipboard, or similar?
Thanks Leo, I have started a trace and will report back when it happens again.
I will get exact versions of the RDP client when I get home. It is Windows 7 x64 on both sides, up to date with patches but not the optional RDP V8 (from Windows 8) as I didn't want to change anything until the problem is found and preferably reproducible.