Options
SF_Green Member Posts: 33 Member
February 2023 edited February 9 in Native Access
I have to admit I've always been suspicious of the NTKDaemon service, but there have been statements from NI people here saying it's just for login and access to Sounds.
However, I constantly see the NTKDaemon service using high amounts of CPU time and activity after a fresh boot and other times when my Komplete Kontrol S88 is off and no other NI software has been started since boot that the service is active and using a fair bit of CPU time. I've even reverted to Native Access 1, and the daemon service is still very active on a regular basis.
Is NTKDaemon being used for telemetry and NI is lying to us, or is there some other BELIEVABLE explanation for why this is happening? Sorry but the general state of affairs these days just leaves me highly suspicious of any big software/tech company. Microsoft, Google, Facebook - liars all. Not saying NI is in the same league as them, but still not feeling inclined to be overly trusting these days.
Tagged:
- Native Access
2
Kaiwan_NI Administrator Posts: 2,669 admin
February 2023
Options
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!
1
James Steele Member Posts: 47 Member
March 2023
Options
Just want to report here on my end that NTKDaemon seems unstable. The process often crashes spontaneously (I saw it spontaneous crash in Activity Monitor when I was typing an email) or it doesn't start up at all upon boot. This seems to explain why I'm always asked for my credentials when running Native Access... because the NTKDaemon process wasn't running. I've actually added the NTKDaemon.app to my dock and launch it manually before running Native Access and I have no problem then with Native Access logging in like it should.
4
Winknotes Member Posts: 5 Member
March 2023
Options
I had a system crash that I thought Zoom was responsible for but the reliability report showed it was NTKDaemon that crashed even though I didn't have any NI apps running at the time.
3
Vocalpoint Member Posts: 1,305 Guru
March 2023
Options
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
4
Jaybee101 Member Posts: 1 Member
March 2023
Options
https://community.native-instruments.com/discussion/comment/56065#Comment_56065
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.
3
Vocalpoint Member Posts: 1,305 Guru
March 2023 edited March 2023
Options
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
5
Hayo_NI Product Team Posts: 298 mod
March 2023
Options
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
Options
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
Options
In my case this was on MacOS 13 and NTK Daemon just crashes by itself... it won't stay active in the background. I took to adding the NTKDaemon.app to my dock and I click it to manually relaunch it, and then immediately afterward launch Native Access and I don't have to be asked to reinstall helpers, etc.
PhoenixGTR Member Posts: 4 Member
April 2023
Options
https://community.native-instruments.com/discussion/comment/60352#Comment_60352
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
Options
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?
1
Paul B Member Posts: 86 Advisor
April 2023 edited April 2023
Options
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.
1
SF_Green Member Posts: 33 Member
April 2023
Options
https://community.native-instruments.com/discussion/comment/62322#Comment_62322
That was my original point exactly.
1
LostInFoundation Member Posts: 4,320 Expert
April 2023 edited April 2023
Options
https://community.native-instruments.com/discussion/comment/62353#Comment_62353
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” 😂😂😂
1
lem_sessions Member Posts: 7 Member
April 2023
Options
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'.
«123456»
Back To Top
Categories
- All Categories
- 18 Welcome
- 1.1K Hangout
- 56 NI News
- 567 Tech Talks
- 488 Social Club
- 3K Native Access
- 12.8K Komplete
- 1.5K Komplete General
- 3.3K Komplete Kontrol
- 4.4K Kontakt
- 1.4K Reaktor
- 317 Battery 4
- 4.5K Maschine
- 5.3K Traktor
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators