Windows Server 2008 R2 64-bit memory leak

Solution 1:

Well, I see ~3.2 gigabytes of Driver Locked memory, which immediately stands out as suspicious.

This kind of memory, Driver Locked memory, is memory that has been locked by a kernel-mode driver. Typically for the purpose of transferring small amounts of data, usually for short periods of time.

So if you have a large chunk of driver locked memory, for a long time, it's usually a sign that something's not right.

I'm going to take a wild guess here and guess that since you mentioned that it's a virtualized server, that it's the VMware balloon driver that's doing this. I don't have enough data to be able to tell you why it's doing this, but there are plenty of cases and VMware support KBs, like this one, that specifically talk about the balloon driver erroneously retaining large amounts of memory when it shouldn't be.

You also have to consider the possibility that the balloon driver is behaving as designed, and it's trying to make your server page out memory because it desperately needs to give memory to another VM on the same host.

There is yet another possibility that it is not a hypervisor dynamic memory driver at all, but instead just some rogue device driver.

Drivers usually allocate memory that is "tagged" with a 3 or 4-character tag that gives a hint as to what driver was responsible for making the allocation.
poolmon.exe, part of the Windows SDK/DDK, can help diagnose.

Like I said, wild guess, but it's the best I can do with the data I have.

Solution 2:

Well, I have every imaginable version of SQL Server on premises, from 2005 to 2016, and I have not seen any memory leaks as huge as 100% of actually used mem. See if you have Dynamic Memory for your Virtual Machine enabled.

Driver Locked is a figure you should concentrate on. In your specific case, Driver Locked is probably one of Hyper-V drivers, which locked all unused memory (assigned to VM, but unused by it atm), so it can "give it" to some other VM configured with Dynamic Memory, or even to host OS, whichever needs it at the moment. You can test it by opening some large file or memory-intensive app inside that virtual machine - the DriverLocked memory should go down as some other metric increases. IMHO this should not be a cause for concern if you didn't overprovision too much of your memory across all VMs.