if it helps, Resource Monitor describes all the other RAM as "Standby"
"Standby" RAM is in use. It's being used as a page cache (it holds pages recently lost from all process working sets; i.e. page faults to these can be resolved without going to disk) and also for proactive file cacheing by SuperFetch.
It's considered "available" because Standby pages don't have to be written to disk before they can be assigned to some other use. Such as when a process hits a page fault that does require reading from disk, new physical page(s) must be allocated to that process, and if necessary these can be taken from the Standby list. (This is not the first choice for finding pages for this purpose, that would be the free and then the zero page list.)
In other words your system is operating as it should be.
You can force your system to get more RAM into the "in use" state easily with the command-line tool
testlimit, one of the tools used in the experiments in Windows Internals. It is not part of the regular sysinternals tools but is associated with them; find it here at the sysinternals site. The download is a zip file that contains two versions, testlimit.exe and testlimit64.exe. Both are linked large-address-aware, so the 32-bit version will be able to allocate up to 3 GiB on a 32-bit machine booted with /3GB, up to 4 GiB on a 64-bit machine.
c:\> testlimit -? gives help.
c:\> testlimit -d 4 -c 512 will attempt to allocate 2 GiB of process-private virtual address space in 512 allocations of 4 MiB each. This should work fine on a 64-bit machine. On a 32-bit machine not booted with /3GB (most are not) it may error a little earlier b/c there's already a few MiB of stuff in the process (like the program itself, all the DLLs, etc.), so there is not quite a full 2 GiB available for the program to allocate.
In both cases there will be a reduction in "available" RAM, and an increase in "In use" RAM, but not necessarily 2 GiB worth because there is no guarantee that the OS will leave all 2 GiB in the process private working set. Even if it does that in the short term, you may see the process working set decrease later as the OS decides "hm, you're not really doing anything with it, other processes need it more" and pages it out.
Increase the size of the allocation "chunks" too much, reducing the number of chunks accordingly, and it will likely fail sooner as each allocation has to be virtually contiguous. e.g. try to find seven 512 MiB chunks in a 4 GiB address space and you'll likely fail.
If you use the l(eak) option instead of d(irty) the program will allocate the virtual space but will never reference it. This will not result in any appreciable decrease in "available" RAM.
(The d(irty) option takes its name from the "dirty page bit" in the x86/x64 page table entry, which is set when the corresponding virtual page is accessed with a "modify"-style operand, meaning the page's contents have been changed. This is Windows' indication that, should the page have to be evicted from the process working set, its contents have to be saved somewhere before the page can be used for something else. Pages with the "dirty" bit set go to the "modified page list" immediately after eviction; from there, Windows writes them to their respective backing stores.)
You will need to have sufficient "commit" available for these tests to work as described above (even for the l(eak) option, even though this option does not use any appreciable amount of RAM). Specifically, your "commit limit" should be at least 2 GiB (or however much you're allocating) higher than the "commit charge" before starting your test. Notice that this applies even if you're using the l(eak) option, not just d(irty). If you run into this limit you will see the "system is running low on memory" pop-ups or similar. The cure, of course, is to add more RAM and/or increase your pagefile settings.