mma64

@Mr_Frog: be patient, you're not the only one with this problem.
@Marcos: I couldn't say it any better, that's it! Ie. whether its a notification popup or a new popup, be it HIPS or the firewall, from time to time there will be this nasty "buy a license..." warning in red (see 3rd screenshot from top)! Thus it seems I'm in the right thread / topic...
@Marcos(/ESET): indeed, only ESET can tell us whether ESET LiveGrid has anything to do with the license activation checking. I have LiveGrid disabled. But I doubt it very much that a disabled LiveGrid has anything to do with this! (Remember the "I have been noticing this behaviour since EIS V16.0.24"?!)
The good thing: I have the promised video showing once and for all that this bug (/whatever ESET may call it) exists really! Stay tuned, now I have to buy some bread first.

sorry, @itman, if this user's license is activated which I think it is, then it is a bug or whatever ESET might call it. The very same thing happens on my computer each time I start it, ie. daily. And yes, my license is activated. This happens since EIS V16.0.24 and not the first V16.x version! I'm pretty sure about this.
But with a little twist: entering the EGUI this warning message disappears (after about 5 seconds) and the license seems to be activated...
And yet another twist: I'm having a HIPS rule that fires quite often and is defined with "notification popup?" = yes. Looking at these notifications appearing in bunches at time, one or more of them appear with the warning info in the 3rd screenshot above!!!
Ie. HIPS notification popups #1 - 3 without the warning, one with, another bunch without, one with etc (!!!) (*)
This is quite irritating and perhaps even dangerous: hasn't ESET decided to cease protection completely if license is expired or not activated quite some version prior to V16?!?
(*= I'm able to make a video of this, ESET!... And everybody can test it, for example with a firewall rule on any browser and then doing some web surfing (allowing ports 80 and 443, TCP and UDP)...)
HTH

- please hand this over to your developers as fast as possible, but you can try it for yourself, everybody can do it in no time...
- this is a very easy to reproduce HIPS bug:
1. extend an existing HIPS rule with for example another ".exe" using the "ADD" button within EIS V15.2.11 and see what crazy thing happens: the selected EXE file gets an "\*" automatically appended!!! (See screenshots #1 - #3. #2 in german, a note by me, saying "extending existing HIPS rule 'xy.exe, write to file', DENY, appends unwanted "\*" to every new addition. Be it selecting within EIS or by copy-pasting!")
2. this doesn't happen when there is a new HIPS popup that you save.
3. now to the very bad consequences of this new and totally wrong automatic appending of "\*", see screnshot #1: here I extended an existing and working HIPS rule (20210720) at two different dates again (20220104, 20220707). Now, with EIS V15.2.11 'weekday.exe' is still working (all these EXE are shelled within different other programs), but not the other two EXE ('send-mail.exe', 'BarcodeGenerator.exe')!!! These two other EXE are completely hanging forever and eating one CPU core fully! It's impossible to KILL these, for sure not with the tools contained in Win7. (The 'cmd.exe' is eating one CPU core, the called EXE is doing nothing, if I remember it correctly. Both can't be killed.) The only remedy is a restart of Win7... (You can KILL them within Win7 task manager a thousand times, no error message, no KILL!) (Point #4 in screenshot #1 would mean "allow all files in directory '..\send-mail.exe\'", but 'send-mail.exe' is a file and not a directory!
4. I can hardly believe that I haven't used the 'BarcodeGenerator.exe' shelling since 20220104, but I will try to verify this (*). It could be that the HANG behaviour kicks in only since EIS V15.2.11?!? (*= checking the HIPS logs, checking previous settings export XML files.)
5. I will not check whether (see screenshot #2) a "write to file" with this automatic "\*" append will HANG the EXE in the HIPS rule too or not. It could very well be the case - again this "'xyz.ico' is a file and not a directory" "thingy"...
hopefully this will be fixed fast, #3 is a very nasty and annoying bug!
kind regards