Are you checking return codes of every single DirectX call e.g. with if(FAILED())?

If not, do this and try again just to make sure that there is nothing you have forgotten to check on your end to prevent calling a failing function over and over.

You can also intercept WM_SYSCOMMAND in your message loop to watch for the screensaver coming on or power save being enabled and pause your game loop at this point which will also help. Personally in my own game I return 0 here, so that power save and screensaver are disabled while my game is active, this would work around your problem.

Is it the SC_MONITORPOWER wParam you return 0 for? So returning 0 for this will intercept and stop the monitor from shutting down, and calling DefWindowProc for the message sends it back to Windows for a shutdown?

Yeah, that's the one. In the event this is a driver bug this would be an effective workaround if not slightly impolite to the user to override their power saving setting :D

all my GPU memory allocations starts to pile up.

When the app is running "normally," what are you allocating (and apparently later deallocating), and what specific conditions trigger the deallocation?

But if you Create new buffers while the monitor is shut off none of that gets deallocated

Maybe this is because the os has physically powered off the pci-e device so the allocations go onto nowhere?

If this is the case and it turns out to be a documented issue you could use the SC_MONITORPOWER message to pause your game while the monitor is off and stop allocating buffers. This would be correct behaviour anyhow as why allocate buffers on a device that can't be seen? You'd just be wasting cpu time...

You shouldn't be creating new buffers every frame! I know you are hesitant to move away from that solution, but it is quite simple to use UpdateSubresource and achieve the same effect. If nothing else, it is worth trying so that you can see if this issue also affects your application when you aren't creating buffers every frame.

I have seen something similar to this before using the Memory Diagnostic feature of VS2015. Every time you create a resource, your process's private bytes will be increased, and it doesn't immediately go back down right afterwards. This is probably due to the fact that the runtime/driver doesn't immediately release the buffer memory, even though from the application side it is released. I haven't confirmed this suspicion officially yet, but it would makes sense in your case too.

Are you getting any diagnostic messages at application exit time? If you are leaking resources, you will get a live device object report in the output window. As long as you don't get that message, then your app is not the source of the additional memory.