NTKDaemon uses dedicated graphics on laptops

XiccioDJ

Hello!

I noticed a (I consider it to be major) issue with NTKDaemon, mostly on laptops.

I've got a Windows 10 Laptop with an Intel CPU (i7-10750h), integrated graphics card and a dedicated Nvidia graphics card (RTX 2060). The problem with NTKDaemon is that, even when the laptop is on battery power, it uses the dedicated graphics card (which is strange because it has no GUI of any sort). This absolutely obliterates the laptop's battery life, because it keeps the said dedicated graphics card on.

When taking this screenshot, my laptop was freshly turned on with NO connected external screens and without it's power supply:

This is the Nvidia Optimus software, that tells if the GPU is in use. You can see NTKDaemon.exe is the only process using the dedicated graphics card, again keeping it on and thus reducing battery life.

What's even worse is that NTKDaemon seems to use the dedicated graphics card even when you set it to use the integrated one from the Windows settings (Display settings -> Graphics settings -> Set NTKDaemon.exe to Power saving).

I also observed this issue on an early 2011 MacBookPro 15" on High Sierra (I know, Native Access 2 shouldn't run there but I was still able to install and use it), where NTKDaemon keeps the dedicated AMD card on (checked from Activity Monitor), so I don't think this is a Windows-specific issue.

Do you also encounter this issue? Can we expect a fix from NI?

XiccioDJ

Today I decided to dig further into the issue and try to find the cause of it.

I used Ghidra to try to inspect NTKDaemon.exe (please read P.S.), and see when the GPU gets activated. Surprisingly, I discovered that NTKDaemon imports OpenGL, which is strange to see on what should be a headless daemon:

With this discovery, I decided to see what function uses wglCreateContext, which is responsible to create a new “OpenGL instance” (or something like that, I guess). With version 1.7.0.137 of NTKDaemon, I found this function at the address 140778050, which seems to make use of the OpenGL apis:

It even creates a window… Shouldn’t NTKDaemon be headless...?

So, what I did at this point was to try to patch the binary to avoid calling this function. At the address 14076a203, I found the only function that calls the above function (14076ac25 is where the above function gets called):

Then, I made a very simple and dirty patch, NOPping the condition and the function call:

Before:

After:

I saved that as binary, restarted the service and… Voilà! Not only NTKDaemon doesn't use the graphics card anymore (thus saving battery), but it also works (Native Access 2 starts fine), which means that function is probably avoidable to get called.

Now, I believe that this function was made to get informations about OpenGL on the graphics card, since some NI products do need a minimum version of that, but I think there should be a better option to get graphics card details, without creating an OpenGL context (GPU-Z, for instance, is able to do it). I noticed that right after the context is created and infos have been collected, it gets deleted. Though, this seems to not be enough since NTKDaemon continues using the graphics card forever in its execution. And ultimately, I really believe Native Access 2 itself should be responsible to do install requirements checks (it uses Electron, and there should be plenty of libraries available to obtain GPU infos), but it’s also true that I don’t know exactly what NTKDaemon is used for, except it should automatically update my Traktor Pro Plus subscription.

Anyways, the fix to the issue is probably very easy to find for the Native Access team. I would really love to have some feedback on if we (the users) can get an update with this problem fixed.

P.S. I am not by any means a professional programmer/reverse engineer, so it is likely that some things I wrote may be wrong. Also, I DIDN’T inspect ANY OTHER ASPECT of NTKDaemon.exe, it really wasn’t my intention to begin with. I know that decompiling is against NI's TOS, but it was really to only find the issue (absolutely no attempt at exploitation) and try to maybe help with Native Access development, underlining where the issue is. After I found the issue and tested the solution, I deleted the Ghidra project, and I'm using the original (untouched) NTKDaemon again.