I am using Dropbox with my folder on a TrueCrypt volume on an HP Pavilion Touch 14-N009LA with an AMD A8-4555 APU, 8 GB of RAM and Windows 8.1. When I run Dropbox, after about 15 minutes my RAM usage shoots up to 7.5 GB and Windows becomes unusable. Closing Dropbox won't do anything. But the moment I dismount my volume, POOF! all that used RAM is freed and memory usage goes back to normal.
This makes it impossible for me to use Dropbox with nearly anything else and I honestly can't think of any reason. What's happening here?
Update 1: It seems like this happens every time Windows reads the Dropbox folder because I just got the same problem when moving my folder from its current container into a new one. I took a look at Process Explorer and it didn't show any process using more than 2 GB of RAM (Superfetch was eating an awful lot, like 2 GB, so I shut it down, but it didn't really work). However, Process Explorer does shows over 5 GB of RAM allocated as "cache WS". I'm investigating that.
Update 2: RAMMap shows here that the 5 GB of memory are being used as a "mapped file". I have never worked with memory-mapped files so all I know about that is from googling, and it might be possible that this is the reason why Dropbox seems to be working so badly with a TrueCrypt volume. My guess is that TrueCrypt accesses the encrypted volume as a memory-mapped file, meaning that there's probably nothing I can do about memory-mapped files.
However, there is one interesting thing: when I empty all the working sets with RAMMap my memory usage jumps back to normal, but keeps filling up again as Windows is reading stuff from my encrypted volume. I don't know much about Windows's memory management but one thing I'm sure about is that this didn't happen two weeks ago. It's as if Windows had developed a memory leak in which a working set is not getting cleared or something. (Sudden hard disk usage increase on C:\ is due to the system transferring back into RAM everything that was transferred to the pagefile to make space for that 5 GB working set).
Also, Resource Monitor lists all that used RAM as standby memory. This implies that it might have to do with the read or write caches Windows uses for disk I/O, which I believe is active on TrueCrypt volumes when they're mounted as normal disks. I'll see if mounting my volumes as portable devices works since AFAIK disk cache is disabled by default in these cases.
Update 3: Mounting the volumes as portable devices didn't work, the system still keeps eating up all the RAM. Next thing on the plan is to see if I can recreate the problem on my sister's computer, which is the exact same model and OS as mine, as well as on my desktop computer which uses Windows 7.
Update 4: Following up on this problem. I just tried to reproduce this problem on my sister's computer. I couldn't. I installed all the latest Windows updates on that computer, created a 10 GB TrueCrypt volume, filled it with enough stuff to fill its 4 GB of RAM, and RAM usage remained the same. I ran Dropbox with one of my folders and RAM usage remained the same.
Now, what happens when I run RAMMap on my computer with the volume mounted and after writing stuff to it? All my system's RAM is listed as standby or modified memory for mapped files. Active memory for mapped files never goes beyond 150 MB.
Conclusion? Something broke on my Windows 8. As a result Windows is not clearing the working set of the memory-mapped TrueCrypt volume, or declaring for some reason its memory usage active instead of standby, or something like that.
(Mind you, since TrueCrypt is kill I decided to instead migrate all my encrypted data to dm-crypt. I now use Gentoo Linux as my main OS and only use Windows to play games. If for some reason I need to access my encrypted disks, what I do is starting a Linux VM, connecting the encrypted drives to the VM, mounting them, starting Samba, and mapping the shared directory on Windows as a network drive).