Memory Leak in nvoglv64.dll

I believe I may have encountered a memory leak in the latest versions of nvoglv64.dll. I have tested both the “Studio Driver” and the “Game Ready Driver” at versions 30.0.15.1259, as well as another recent version of the “Game Ready Driver” but did not copy its version number; all three cases resulted in the behavior I will outline below.

In testing some Vulkan software I’ve been playing with, I noticed that memory was accumulating each frame when I combined compute and graphics operations per frame (ie. dispatch and draw). Using Microsoft’s Performance HUD, I was able to gather that the cause was an accumulation of unhandled events: (Manually formatting HUD results since new users can only include one screenshot)

| Category | Type | Outstanding | Outstanding (delta) |

| Kernel | Event | 10,199 | 10,199 |

Going deeper with WinDbg, I was able to step through the assembly and verify that CreateEventA() is being called each frame in the following stack:

Stack Frame Creating Event

This call to CreateEventA() occurs directly before calling DrvPresentBuffers+0x8a70 in the dll.

Following the assembly, it appears that the resulting event is indeed never cleaned up in the driver nor is it returned to the calling code.

This is not my area of expertise, so I could be missing something and am open to feedback, but it appears to be an odd bug in the nvoglv64.dll driver.

All help is appreciated.

I’m able to trigger a similar memory leak in a different Vulkan application; in this example the memory is only leaked while resizing the application window, as shown in this stacktrace to re-create the swapchain.

image

Notice that the top three stack frames are identical to the previous application’s leaked resources, supporting my belief that some obscure condition is resulting in the creation on unhandled resources.

Hi @ryco117 ,

thank you for reporting this issue. I quickly wanted to reach out and let you know that your post did not go unnoticed, I am still on the lookout internally who might be able to either explain what you are seeing or confirm if this is an actual driver bug.

And any further insights you could share are very welcome! Especially if you would have a minimal reproduction app we could use.

Thanks for your patience!