denijeur 0 Posted January 30, 2014 Share Posted January 30, 2014 When I try to activate a trial license on a first time installed Nod32 Antivirus I'm getting the following error message: ---- Activation Failed Error creating temporary file name ----- Version info: Eset NOD32 Antivirus Version 7.0.302.26 Windows 8.1 Pro Build 9600 I googled that error message and found a similar error message appeared when trying to update the virus signature DB, so I tried solutions proposed for that problem, namely: 1. Cleared Temp folders: C:\Windows\Temp and C:\Users\MyUserName\AppData\Local\Temp\ 2. Deleted those folders and created them anew 3. Cleared Update Cache in NOD32 4. Checked the environment variables TEMP and TMP, they are fine (pointing to the existing temp dir in my user profile dir). The error persists. Please help. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,277 Posted January 30, 2014 Administrators Share Posted January 30, 2014 Did you also check the c:\windows\temp folder? If emptying it doesn't help, it could be a permission issue. In that case, a Process monitor log will shed more light. Link to comment Share on other sites More sharing options...
Solution denijeur 0 Posted January 30, 2014 Author Solution Share Posted January 30, 2014 (edited) Marcos, thanks for answering. I had checked, then cleared, then recreated C:\Windows\Temp folder. Unfortunately that didn't help. Thanks for telling me about the Process Monitor tool, I didn't know about it. I downloaded it from Microsoft site, filtered all suspicious lines, including this one: Process: ekm.exe Operation: QueryOpen Path: C:\Windows\SysWOW64\%USERP~1\AppData\Local\Temp\ Result: PATH NOT FOUND The path looks weird enough, but after I had created this folder (C:\Windows\SysWOW64\%USERP~1\AppData\Local\Temp\) activation succeeded. I mark this topic as solved and I thank you again. Still I wonder why this weirdly named folder was necessary at all. EDIT: a few typos. Edited January 30, 2014 by denijeur Link to comment Share on other sites More sharing options...
Administrators Marcos 5,277 Posted January 30, 2014 Administrators Share Posted January 30, 2014 For some unknown reason, Windows API returns this weird and non-existing path to the temp folder. If you run echo %TEMP% in the command-line console, it should return the same path. Unfortunately, I was unable to find more information about the weird path so it will remain a mystery as to why Windows returns it Link to comment Share on other sites More sharing options...
denijeur 0 Posted January 30, 2014 Author Share Posted January 30, 2014 No, actually the %TEMP% variable is set correctly. See the screenshots. hxxp://i.imgur.com/mIRBW5B.png hxxp://i.imgur.com/5dXRN3u.png Link to comment Share on other sites More sharing options...
Arakasi 549 Posted January 30, 2014 Share Posted January 30, 2014 From programming experience, you get a similar path due to the fact your running the windows service using different accounts. SYSTEM account for example, goes out there to c:\windows\system32\config\systemprofile\AppData\local\temp , or add the SysWOW64\, so imagine it being ran under that account and not user, and failing. You would have a variable that is.... c:\windows\syswow64\config\systemprofile\Appdata\local\temp , windows may insert %userp~1 as a type of junction or shortcut for the path. Which leads to additional scenario following here: Also if behind the scenes code is using GetTempPath() , there are many variables that can cause it to get thrown off, some of which include variable being too long, in this case we see a tilde sign in the string of your path. Possibility. Permissions of course not being write on the directory you land on is unfortunate, lol. We may never know not being able to reproduce it, but i hope this dev session helps with the head scratching. Link to comment Share on other sites More sharing options...
denijeur 0 Posted January 30, 2014 Author Share Posted January 30, 2014 Arakasi, I have just reviewed environment variables of all the users, and they all have %USERPROFILE%\AppData\Local\Temp value in TEMP Anyway, looks like you are right, probably some function shortens %USERPROFILE% to %USERP~1 while parsing this path thus causing the trouble. I just wonder why I'm the only one reporting it, my configuration doesn't seem so odd out. Link to comment Share on other sites More sharing options...
Recommended Posts