I think I did a long time ago, I'll try again. I do use that facility though so is there some specific reason for turning it off?
Okay, MAJOR breakthrough. It happens every time and is easy to reproduce immediately now!
I recently upgraded my server to Windows 8.1. When connecting to the server over RDP from Windows 8.1 (so using RDP V8) the memory use of Opus increases every single time, right from the very start. Windows 8's task manager seems to calculate memory differently to Windows 7, and shows the issue immediately. At first the increase is 0.1MB each time, but it doubles every single time you close and re-open the RDP session.
Unfortunately I can't get VMMap to even start Opus on this system, it keeps moaning about a missing DLL. I'll try and fix it later, but the good news is that the issue is now 100% reproducible and must be an Opus bug because we now have a fresh Windows 8.1 install with no additional codecs or software beyond Pale Moon, qBittorrent and Truecrypt, none of which install shell extensions. It's a different motherboard as well, I went from AMD to Intel and a whole different set of drivers.
Are you still interested in trying to fix this? Can you try recreating this set-up with two Windows 8.1 machines?
Please try the clipboard idea.
I don't have a Win8.1 VM but I have a Windows 10 one which presumably has the same version of RDP, and I'm not able to reproduce this (connecting from a Win 8.1 client).
Leo: The clipboard idea didn't help. Thanks anyway.
Jon: I don't know if Windows 10 is the same, but you are quite possibly correct. What version of Opus are you testing with? Is it an x86 or x64 OS on either end of the RPD session? Did you try opening a lister and repeating the test?
x64 at both ends, and yes a Lister was open. It was quite obvious that memory use wasn't going up between connections, in fact it often went down slightly (i.e. it would fluctuate randomly but there was no overall loss of memory reported by task manager).
I think I need to set up two VMs, one to RDP into the other and create the fault. Then I can post both somewhere for you to try.
Can I have an address to send some DVDs to you? The VMs are kinda large and not easy to transfer over the net, unless you can (ab)use Usenet...
Am I right that you're in the UK? If so, I can email you a UK address to post them to, to save having to send them to Australia.
That would be fine, thanks.
Okay, I've emailed a postal address to you, via the email address of your forum account.
Thanks, I have it. I'll prepare the VMs over the holiday and get them sent over to you.
Any update on this?
It's still bugging me! Definitely an RDP/dopus interaction issue.
No update as we still haven't been sent anything we can use to analyse or reproduce these reports.
Sorry, I've been busy with other stuff. I'll get around to it eventually. FWIW I had a few changes to the system that is most affected and it seems to happen less often now, touch wood. It is Windows 8 and QBittorrent instead of Windows 7 and uTorrent. Still happens occasionally though.
General observations.
Most of my memory incidents have been with a single dopus lister minimized, and seem to be triggered by either connecting or disconnecting from RDP.
Latest incident.
Watched dopus grow from it's usual 50MB to several hundred megabytes over a few hours of connecting/disconnecting RDP. On one occasion I was actually watching it in Process Explorer and noticed dopus.exe also consuming 12.5% CPU (100% of 1 thread) as the memory usage grew rapidly over 30 seconds or so and then stopped.
Then next day I logged on locally and that triggered an immediate response by dopus.exe (2 listers this time both minimized doing nothing) of CPU usage and memory growth rapidly up to 1.2GB. As this was happening I decided to close 1 of the listers and it was shortly after that the CPU/memory growth stopped. Upon exiting dopus the same cpu usage but with rapid memory shrinkage down to below 100MB before terminating.
This is the first time I have seen memory usage grow then stop and stabilize. It usually grows till it runs out of memory.
To stop VMMap running out of memory I will try pausing it and then re-start it when dopus starts playing up.
Interesting observation... I do keep some listers open but minimized for long periods sometimes, but lately have been doing it less. I'll experiment and see if keeping a couple open but minimized increases the frequency of the problem.
Latest incident.
I finally had dopus playing up after being launched by VMMap thanks to pausing VMMap overnight. When I started RDP the next day dopus was sitting at around 600MB and VMMap was 1.5GB so it seems VMMap uses some memory even when paused. I then noticed dopus' memory usage was quickly rising so I un-paused VMMap, but unfortunately before I had a chance to refresh VMMap it had crashed. It must have been growing by 600MB+ per second (1 snapshot/second) but it crashed way before I ran out of memory (and yes I was running the 64 bit version).
I will try again tonight and only take one snapshot before I refresh VMMap.
If you guys are seeing a repeatable issue. that the devs cant reproduce. Have you considered using an app like teamviewer to allow them to remote connect to you PC?
Thanks beatbox20, your efforts are greatly appreciated. I can never get VMMap to not crash, but I don't have a local keyboard/mouse/monitor on the affected system and as we know RDP triggers it.
I'm wondering if I can snapshot a VM every 30 minutes or something, and then go back to a point where I can unpause VMMap before it crashes, and maybe send the whole VM to the developers.
wowbagger, I have considered TeamViewer but aside from privacy issues I don't think it would help. The issue is being able to use any debugging tools, and unless someone is willing to set there 24/7 waiting for Opus to fail they will have the same problem as we do.