Possible return of "GPU-Z Memory leak when left open for days"?

[RobertR]

Yes, I found the older thread - but the "resolution" of that one wasn't very definite, and may or may not be related to what I am seeing.

Basically, the last 1 or 2 releases of GPU-Z (either just 1.11.0 or including 1.10.0 also) have been exhibiting a monotonic growth in the process's working set of 4 KB or 8 KB every 6-8 seconds, as displayed by Process Explorer on fully up-to-date 64-bit Windows 10.

So, after 4 days - including hibernating at night, so no restarts of GPU-Z - we are up to 1/4 GB... not crippling, obviously, but annoying, and it seemed like the longer this goes without getting fixed, the more difficult it might be to find.

I have an MSI NVidia GTX 1070 card, with the NVidia 372.90 WHQL driver - and I am not asking GPU-Z to log anything, just requesting the usual "Refresh sensors while GPU-Z is in background".

Let me know if there is anything else I can supply, or questions I can answer - thanks!

 

[W1zzard]

Stops growing around 10 MB here on Windows 7 + GTX 980 Ti, so I suspect it's a leak in the NVIDIA driver again, for Pascal only.

Will try to replicate on Pascal

 

[RobertR]

Cool, thanks for looking into this - and to think, I was troubled when, with my old AMD 7850 card, GPU-Z's WS would get up to 50-60 MB.

I am puzzled - how could anything like a memory leak in the NVidia driver show up in my [GPU-Z] process's WS?

A tidbit: the suspend/resume caused this to briefly shrink by 8 MB, but the instant the system was back, it resumed its march to... well, we'll see - I do have another 12 GB still unused.

 

[W1zzard]

I am puzzled - how could anything like a memory leak in the NVidia driver show up in my [GPU-Z] process's WS?

GPU-Z loads NVIDIA libraries into its process space to query things. If there's a memory leak in those libraries it will show as owned by GPU-Z.
Similar issue when the OpenCL driver crashes during detection, GPU-Z will crash with it, people will blame GPU-Z...

Now that I'm thinking about it, maybe I can unload the NVIDIA library every few hundred calls, which could free up the memory.

Going on a two week vacation tomorrow, so this will have to wait a bit.

 

[dorsetknob]

enjoy your vacation @W1zzard

 

[RobertR]

GPU-Z loads NVIDIA libraries into its process space to query things. If there's a memory leak in those libraries it will show as owned by GPU-Z.
Similar issue when the OpenCL driver crashes during detection, GPU-Z will crash with it, people will blame GPU-Z...

Now that I'm thinking about it, maybe I can unload the NVIDIA library every few hundred calls, which could free up the memory.

Going on a two week vacation tomorrow, so this will have to wait a bit.

Ahhh... like nvapi.dll? Sure, this could help - if it cleans up after itself when it is unloaded.

Yup, enjoy - I am sure everything will be waiting for you when you return.

 

[RobertR]

...
Yup, enjoy - I am sure everything will be waiting for you when you return.

So, I trust you are refreshed and recharged after your vacation, since this pesky little "feature" is still present in the latest (1.12) release of GPU-Z.

Not to be in any way combative - but merely to provoke thought - I will mention that neither MSI Afterburner's nor HWiNFO's NVidia monitoring functions exhibit this particular behavior.

Since none of the primary monitoring apps I know of are open source, I am unable to offer any suggestions or assistance - other than testing any possible fixes.

 

[RobertR]

Following up, Martin from HWiNFO confirms he is using NVAPI for "almost all" NVIDIA GPU queries, so this would seem to have narrowed the possibilities for the monotonic WS growth GPU-Z exhibits to either using NVAPI [somehow] differently, or ... something else entirely [besides NVAPI].

BTW, my question to him included your potential mitigation mentioned above, but he didn't comment on it one way or another, so it could still be worth exploring.

Thanks, W1zzard, and of course, I am ready to test anything you would like me to take a look at.

 

[rtwjunkie]

I'm curious why you would leave GPU-z open for days. Please don't be offended, I only ask because it doesn't make sense to me. Hopefully you can explain for me.

 

[RobertR]

Umm, why not [leave it open for days]? And, BTW, the "days" thing is just a good way to see really big WS sizes - the growth rate is on the order of 1 KB/sec, which you need to pay attention to to actually notice.

Further, I typically don't do a full restart of my system unless forced to by some update that can't complete otherwise, preferring to hibernate (which has started to become unstable on the latest Win 10 for me), or just sleep my system.

And no worries about any "offense" being taken - questions are just questions.

 

[RobertR]

For those still eagerly following this thread , after less than a week (and with my system sleeping about half the time), my Working Set for GPU-Z 1.12.0 on 64-bit Win10 is up over 330 MB. For the really interested, the CPU time used by GPU-Z over that elapsed real time is ~2 hours.

The "records" in the memory segment that is growing monotonically appear to have some sort of binary "preamble" or spacer, then really get going with "NVAPI Clock config"... and end with "... MHz" and a LF character - note that all of these are 16-bit characters - then it all just repeats indefinitely.

As always, happy to answer any questions or run any requested tests.

 

[Naki]

Curious, what tool do you use to read the GPU-Z memory space? Low-level debugger?
(SoftICE/etc)

 

[W1zzard]

The "records" in the memory segment that is growing monotonically appear to have some sort of binary "preamble" or spacer, then really get going with "NVAPI Clock config"... and end with "... MHz" and a LF character - note that all of these are 16-bit characters - then it all just repeats indefinitely.

Bah this is the GPU-Z internal log, I invited you to the GPU-Z Beta group to test the fix

 

[RobertR]

Curious, what tool do you use to read the GPU-Z memory space? Low-level debugger?
(SoftICE/etc)

Nothing that exotic, I am just a "recent convert" to Process Hacker (and running my own 64-bit build)... this is the first thing that has made me leave good ol' Process Explorer behind.

@W1zzard: heading over now.

 

[Kegelcizer]

Hi,
I'm experiencing the same thing on my ASUS GeForce GTX 1060 Turbo 6GB DDR5 192-bit, Windows 8.1 64 bit up to date, 375.95 WHQL driver.
Also, ASUS GPU TWEAK has the same issue for me, not at the same rate though.

I see W1zzard has an idea of what this issue is, but if you need more details from my system, I'll supply them with pleasure.

 

[robotzko]

can confirm same issue on Asus GTX 1070

after start it has about 10 MB after 1 day open it has over 100 MB and after some days it grows to 300 MB ram usage

Windows 10 Build 14393.447

 

[RobertR]

Just to "close the loop", W1zzard's fix does appear to take care of the problem... a test version has been running since yesterday, and still is using less than 30 MB.