I do not have a console window, but I do use background threads for resource loading (meshes, textures). I think you're onto something though, as it definitely appears to be hanging when the leak occurs. I assumed this is because of large resource loading on the main thread, but it's certainly not anything I'm doing intentionally. However I've placed breakpoints in my resource loading code and they don't fire off during the leak. They should only allocate memory once during the start of the app when my meshes load.

And yeah, no C#.

Well, I haven't been doing non engine, raw direct X win32 apps for a while.

Apparently there is something called dwm and you need to take care you are not doing the wrong things with directX while it's in different stats I guess:

I am unfamiliar with it, so you will need to read on it yourself.

https://docs.microsoft.com/en-us/windows/win32/dwm/dwm-overview

Thanks for the link. I had seen some references to "DWM" as well when I was looking up what the preview window is. I'll hit the books and update the thread if I find something enlightening.

This stuff is absolutely eldritch, I can see why aero was such a fuss when it came out.

There is a DWM func that disables it for your application... which has been deprecated.

There are several funcs that control the frame timing of DWM, DwmModifyPreviousDxFrameDuration, DwmSetDxFrameDuration, DwmSetPresentParameters, which have all been deprecated as of windows 8.1 and do nothing now.

Finally, there a func DwmSetIconicLivePreviewBitmap which allows you to override the live preview with your own bitmap. It is very picky about the type of bitmap you use, but after a bunch of fanfare I loaded a HBITMAP as a test and was able to get it to replace the live bitmap. However this did not fix the leak.

I'm going to keep researching other DWM functions that might not be as well documented, but there's a lot of brick walls here.

This may be my final update on this issue (for now).

Calling DwmFlush() once per frame before I do any of my dx11 rendering has reduced (not eliminated) the leak. This means it is almost certainly DWM that is causing the issue. Too bad they deprecated the call to disable it, but I at least brought the leak down from multiple gigs to a few megabytes, and it's only when opening up that thumbnail. I worry that as I add scenes with more complex geo that the leak will get worse, so I am going to investigate and see if anybody has found a way to disable DWM. I also need to analyze perf with that flush, hopefully it's not too bad. But for now I'm glad I was at least able to reduce the problem.

DwmFlush is probably just slowing down your app, which is why it slows down the leak. The DWM is a separate process and is not causing your application to leak. As I said before, there exist tools that will actually let you see where the leak is coming from. I suggest trying with different drivers (e.g. does it happen with WARP?) to try to rule out a driver bug.

It isn't slowing down the leak because the leak doesn't happen over time. It happens in large chunks of allocations when you hover over the thumbnail. I can take a screenshot of the memory profiler to show what I mean, but essentially you hover over the thumbnail and lose 20 mb. Hover over it again, lose another 20. How much you lose is dependent on the size of the vertex buffer and the DWM flush.

I will try with different drivers and do more profiling work, but there are no explicit allocations in my program that are causing it unless there is an error in the profiling tools.

EDIT: forgot to mention that the issue does not occur with WARP

On 11/14/2019 at 10:29 PM, joetext said:

I will try with different drivers and do more profiling work, but there are no explicit allocations in my program that are causing it unless there is an error in the profiling tools.

EDIT: forgot to mention that the issue does not occur with WARP

The leaks occur when you perform unauthorized access to a memory, not during allocating it.

If the issue does not occur with WARP, you have quite well narrowed down the source code where you might perform the leak, that is DWM usage (or how it's called).

Thanks for the reply Johnny Code.

I think what is making it hard to track down is that I don't intentionally call DWM anywhere (except for my tests where I tried to disable and flush it), so the use is quite opaque to me. To my understanding, DWM causes my program to render to a frame buffer instead of blitting straight to the screen. Perhaps there is some way I am mishandling winapi or dx11 calls, rather than to DWM itself?