What does NTKDaemon service do? (2024)

February 2023

Hi @SF_Green our Native Access product owner gave an overview of the history of Native Access here:

Dev Talks: Why We Transformed Native Access

He explained a bit what NTKDaemon does in the article. Hope it answers your question!

James Steele Member Posts: 47 Member

March 2023

Winknotes Member Posts: 5 Member

March 2023

Vocalpoint Member Posts: 1,305 Guru

March 2023

NTKDaemon is the primary driver of my non-stop "Native Access Reinstalling Itself" process that occurs here every second day.

NI Support has had me perform all sorts of scans, Visual C++ library replacements and other strange requests - instead of simply reaching out to SF Green and asking why this thing so poorly coded.

You would think that something as important as this service - would you know - work?

VP

Jaybee101 Member Posts: 1 Member

March 2023

Unstable is an understatement. I have a brand new PC on Win 11 and without fail every single day NTKDaemon crashes on boot. Every.Single.Boot. Fresh install of Native Access downloaded from the site etc, latest drivers etc. I'm not even using Native Access at all on a daily basis but it starts up and crashes :)

The Reliability module reports that the Fault Module Name is ucrtbase.dll

I think I'll take your workaround and just stop this thing from starting up every day and just enable it if and when I need to use Native Access.

There doesn't seem to be any way for reporting a bug to NI? Is this forum it? No official channels to the developers? Would be happy to send logs if there was. Can't see that the NTKDaemon crash is actually harming anything by closing but it seems an exercise in futility if it's just going to boot and crash every time the machine starts.

Vocalpoint Member Posts: 1,305 Guru

March 2023 edited March 2023

JayBee

Welcome the jungle! I have been fighting this issue for 6 weeks now and have literally written a technical manual for NI Support on the interactions between NTKDaemon.exe (V1.1.0 to be VERY specific) and ucrtbase.dll - and all NI Support has done with all this knowledge is continue to tell me it's my fault AND make all sorts of ridiculous suggestions like sending me to bizarre links (to Major Geeks etc) for things to try.

The key observations at this time are these:

Firstly - ucrtbase.dll is a key Microsoft Windows C++ library that is part of every version of Windows. EVERY Windows user has this file and in four different installs here with 4 different flavours of Windows 10 AND 11 - the file is identical (v10.0.19041.789) This version is on my DAW, on my personal workstation, on my wife's PC and so on. Fair to say this is probably your version too. With the extreme commonality of this file - it is not this file causing any issues.

Secondly - NI Support is also trying to blame the Visual C++ installers. Native Access 2 (v3.2.0) when installed to a BASE system - in my case - Windows 10 22H2 ENT that had just been installed AND has no software of any kind on it and NO existing Visual C++ Redistributables - installs two Visual C++ redistributable packages dated Oct 10, 2022 – version 14.32.31332

These versions are a tad older than what's is current from Microsoft but work just fine AND do not alter that ucrtbase.dll file in any way. I swapped out all my Visual C++ libraries on the DAW to be extra sure I was current - but this made no difference. NTKDaemon will crash, Windows Installer will then fire up (seemingly by itself silently in the background) AND then reinstall NTKDaemon from scratch - every time I double click the file icon.

Finally - NI Support is blaming ANYTHING but the bug ridden NTKDaemon.exe (V1.1.0) itself. And since it appears that no one is listening over there – let me state once again that Version 1.0.0 of NTKDaemon.exe did NOT exhibit any of these issues (delivered up to Native Access 2 v3.1.0) and given the exhaustive study I have given this - it it clear that NTKDaemon v1.0.0 was also using the same ucrtbase.dll that is currently installed.

The bottom line is that NTKDaemon.exe (v1.1.0) is faulty, does not play well with ucrtbase.dll and needs to be examined line by line to see what is going on here. I would also love to know what brainiac at NI thought it was a good idea to have Windows Installer step in to strip the software (silently no less) at the first sign of trouble and then try to cover it's tracks by reinstalling it right back to where it was. This is very definition of insanity.

It would be better to simply have it crash, die and post a meaningful message on screen so the user can see what is causing the crash and try to troubleshoot it. But instead of exposing its faults - NI simply tries the install again hoping it will work right a second (third, fourth, fifth) time. Sigh.

For such a critical piece of NI software - the fact that I even need to waste time typing all of this is embarrassing.

After all this - I should really be offered an interview for a plum role in NI's Q&A department so I get someone to pay attention to what is going on here.

On a slightly more positive note - I did manage to glean info from NI Support that a new version of Native Access is coming soon but of course no info on whether this new version actually addresses this issue.

VP

March 2023

Hey there, PM of Native Access and the NTK Daemon here. Just letting you know we're aware of some Daemon instabilities. We're currently working towards getting our diagnostic systems improved so we can get more of an idea how to recreate these crashes, as that's our number one problem with resolving them. We tackled a pretty major instance of the Daemon crashing during downloads back in 3.2.0, but we are also aware of the reinstalling that's happening every Native Access startup, for which I've logged a ticket.

We apologize for the inconveniences you're experiencing. If you see the NTK Daemon crashing, what would help tremendously is sending the daemon.log file to the support team for us to investigate what the NTK Daemon was doing when it crashed. But thank you for the in depth deep dive @Vocalpoint. We'll take a look and see what we can gather!

HighConcept Member Posts: 1 Newcomer

April 2023

Here's an NTKDaemon.exe crash dump, hot off the press (April 1). Forward it to support, if you will. Windows 11 Pro 64 Installation. This crashes every time I reboot the computer.

James Steele Member Posts: 47 Member

April 2023

PhoenixGTR Member Posts: 4 Member

April 2023

It's good to know you're working on it. In the meantime, though, is it OK if the Daemon service is set to manual start, to be launched when needed? If so, should it be running every time a NI plugin is in use, or only for update checks and installs?

LostInFoundation Member Posts: 4,320 Expert

April 2023

My question is even simpler: why do we even have to have something like this started at computer start up instead of being it started together with a NI program when it is needed? And closed when the NI programs are closed?

I admit my ignorance…but nowadays it really seems they want to force us to have things like this running in background even when there is no need for them…

Quite suspicious, don’t you agree?

April 2023 edited April 2023

I don't think it's suspicious (unless you're using that word in a different way than usual), because I don't believe it's doing anything nefarious, but it is odd. I have the same question about why it needs to be always running.

I've written applications which required long running daemons and used others. The description of what NTKDaemon does (from the dev thread) does not match the requirements for a long running daemon.

I didn't have it as a login item – the recommended fix for having to enter the user password on starting Native Access after a reboot, which also occurs if I manually terminate NTKDaemon from Activity Monitor – and don't want it as one.

I've set up an Alfred workflow – because that's the kind of thing I do a lot, for all sorts of actions, and I wanted to experiment with NA's NTK Daemon dependency to see if it really needs to be running when NA is not active – to start NTKDaemon and then NA. And terminate both when I'm done. I've yet to notice any negative effects of the daemon running only when NA is active. There was some weirdness with NTKDaemon being slow to start from an Alfred app launcher action (other apps are quick, including NA) vs. starting it manually by running the app from Finder, but I got around that by directly running the executable inside the app package in the workflow instead. I'd love to know why the app itself is slow to start from the Alfred app launcher when it's fast when started in other ways, but as long as it's quick to start from within NA (evidence indicates it may not be but I can't be sure, given the statement in another thread that it is reinstalling, not just starting) I don't expect NA to help figure out how it works in an Alfred workflow, and I have a working alternative solution.

I understand the need to decouple actions like installation from the UI. But given the purpose and use of NTKDaemon, I can't see a good reason it needs to be running except when NA is active.

It's also odd that the action when NTKDaemon is found not running is 'reinstall it' and not 'look for it where we expect it to be installed, start it if it's there, only install it if it isn't there'. This could be an oversight, and hopefully the latter is where they're going to end up.

SF_Green Member Posts: 33 Member

April 2023

That was my original point exactly.

LostInFoundation Member Posts: 4,320 Expert

April 2023 edited April 2023

This is what I meant with “suspicious”: if it’s not needed, why making it constantly running? Is there some other (hidden) reason?

But I understand by saying this I fall into the “conspiracy” territory.

But…you know…being the earth flat, everything can “fall” 😂😂😂

lem_sessions Member Posts: 7 Member

April 2023

So after many BSODs (stuck at 0% so no LOGS) I re-set my PC fully to Windows 10H2... for a while (>24hrs) there were no BSODs and I think I finally solved the problem.... mmmmh nope... when the PC was on the net, I got another BSOD with Traktor 3.5.3 running but this time it wrote some logs!

....aaaaaaand guess who the culprit was once I actually got some Security Logs for the BSOD:

NTKDaemon.exe mis-interacting with ucrtbase !!!! nothing else is installed on this PC except Traktor 3.5.3.

reason I am running 3.5.3 and not 3.8? Saving Collection Problems, listed in another thread. My 3 min save of a collection turned into 15 min not-save-my-collection.... many other people with this 'problem'.