NTKDaemon uses dedicated graphics on laptops

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.

@Kaiwan_NI Thank you very much for acknowledging that! I hope this can get fixed soon.