Since you’re program is a synthetic test to monitor memory usage, and you’ve successfully run and monitored memory usage, it seems to me you don’t have a problem other than an interest in trying to understand what’s going on.
The OS and compiler toolchain are actually quite important.
Since you’re using Visual Studio 2015 (VS 14.0) you can use the memory heap profiling tool to investigate. Run your program and take a snapshot just before you resize, and then resize and take another snapshot so you can look at the difference. Make sure that you have debug information in your build (i.e. a release build but generating a pdb) and that you’re targeting the v140 platform toolset (this should be standard).
In my case what I see is that although the memory of the process changes when I change the size of the window or go fullscreen, the application itself and glfw are not allocating any memory as the heap snapshots show.
Using Process Explorer I can see that the GPU memory is going up at the same time as the overall Private Data, so it’s probable that the driver or WDDM is responsible. Looking at the 32 bit build I see that although the GPU memory increases, the private data doesn’t go up much.
You might wonder why there’s a difference between the 32 and 64 bit versions, and it’s possible this is related to an issue we encountered when working on Crysis DX10 and WDDM 1.0 which led to a Microsoft releasing a QFE patch - video memory was being virtually mapped in the process virtual space leading to the process running out of virtual memory. Since 64bit memory space is more than sufficient, the memory optimization may not be applied on 64bit processes. This is a guess however.
The best way for a more concrete answer than that provided is to investigate this yourself. I’ve linked to some of the tools with which you can do this. There are further tools available such as ETW tracing and GPUView, VMMap and RAMMap.