mma64

Using Win7 and EIS V16.0.24 I haven't encountered this new "version" of a "hiding" (@Deahty, others) / out-of-the-monitor ( @VW00) firewall popup bug in interactive mode yet. But the info about the popup sound is interesting, I will check this out. (To hear sound I have to put on my headphone.) @VW00have you checked the Microsoft SysInternals Tools already? Contains PsKill with which you might kill the hanging process (not EIS / ESS of course) eventually. And Process Explorer (and another one). With the former one can fiddle different properties of a process for example the visibility of a window or popup / dialog box etc. I have used Process Explorer once and was able to make a not appearing popup in another program, ie. not ESS, visible and could close it correctly. As a developer, like me, you know what I'm talking about. (Others shouldn't use such tools except they know what they are doing.)

@Mr_FrogThis "buy license" bug has nothing to do with any program but ESET EIS. Be it a real bug (EIS effectively (")forgetting(") that there is a valid, activated license (for a short time) and then "rethinking" (/revalidating and correcting) its error), or be it an issue, ie. EIS "thinking" there is no license, but in reality the valid and activated license is always there and ON, as it should be. (Now developer speak) the latter could be as banal as taking the wrong variable in the notification popup source code, instead of for example the boolean 'isLicenseValid' some other boolean. (Boolean: can be true or false only.)) The more notification popups an EIS V16.0.24 user has, the higher the probability that he/she will notice this "buy license" red warning in some notifications displayed. Especially if the EIS GUI was not open at that time, ie. closed - this is the key factor, increasing the probability of the added red warning in notifications. With my HIPS rule "allow direct access, all activities, log=yes and now even notify=yes" for PerfectDisk, this program is generating ~8000 (!) notifications in 2 to 3 hours, if I leave the program open. Which is not the case generally. Ie. PC start, PerfectDisk START, PerfectDisk CLOSE. Now the SMART values, temperature etc are "recorded". And before PC shutdown PerfectDisk START and checking the values. Thus now we have 3 PCs showing this behaviour, 1x Win10, 2x Win7... Who's next? Anyone else?

hm, I have no "empty setup window(s)" and with "buy now" do you mean "{button}buy license - Your computer is not protected"? (->video @00:54)?! I'll do this stuff, but will it work? Ie. it's 100% impossible (for anyone) to catch the very moment "buy license" appears in the 1st HIPS notification of this bunch of a lot of others. And, as you (/ESET) have seen, it's mostly and eventually only in the very 1st one appearing. Would an 'ekrn.exe' memory dump not store the process state of the 2nd+ notification, the ones with "good license"?!...

This HIPS rule is "allow direct access, [ALL activities], notify=yes, log=yes", ie. it's goal is to log exactly these activities and, since a few weeks, notify it to me at the same time. Ie. it's working perfectly as it should, except the "buy license" bug, mostly on the first notification of this event, followed by a whole bunch of similar notifications w/o "buy license". In HIPS interactive mode every "suspect", "suspicious" activity, seen from the AV software side, will generate a popup where you can decide what to do with it. Thus all PerfectDisk activity is stored in HIPS rules since many years. @Marcos/ESET too: Only because of this notify=yes I noticed the "buy license" bug (in notification popups, be it HIPS (100%) or firewall (not quite sure, but I assume it) at all. Which lead to my further investigations on this matter. (Ie. if you have no (HIPS) notifications cascade, you will never notice that there's this new bug.) And I changed to notify=yes only because of the above mentioned new HIPS Duplicates Bug, similar to the very old and fixed one. @Marcos/ESET too: Otherwise there's only "buy new license" once for about 5 seconds when opening the ESET GUI after PC start - a thing one can live with, I thought, until I had to detect the same red warning in notification popups!... Over and over again, fully reproducible (-> the video), I could have been doing the above mentioned flow forever, every time with the exact same result. This flow is the key to reproduce this bug. The 2nd key: start your PC from total shutdown, don't wait for HDD (/SSD) activity calming down totally, open ESET GUI - is "buy license" appearing shortly? Then you're on the right way. Close ESET GUI, wait ~4 minutes, doing nothing else. Reopen ESET GUI - "buy license" appearing shortly. Superb, you have a PC showing this bug! (This doesn't work always, but a lot of times (-> video, but not captured fast enough unfortunately)). Do the PerfectDisk OPEN/CLOSE thing with the ESET GUI closed, this "forces" the "buy license" in HIPS notification popups with more probability. (The 3rd key could be a HDD instead of a SSD: (my thought) "my PC start eats several minutes, that's the reason for the "buy license" when starting the EIS GUI?! This would certainly not happen with a speedy SSD."))

@Marcos/ ESET: this domain is working, I have tried it, directly from this topic. Apart from my successful trial my logs are showing me two more successful downloads (not from me) until now: 63.247.xxx.xxx - - [10/Jan/2023:14:12:37 +0100] "GET /hab-dich-ESET.wmv HTTP/1.1" 200 16849217 162.226.xxx.xxx - - [10/Jan/2023:17:23:29 +0100] "GET /hab-dich-ESET.wmv HTTP/1.1" 200 16849217 looking at the automatically created forum mails (your 1st post), "Tue, 10 Jan 2023 07:10:57 +0100" it's clear that you tried it after 05.00 CET. But I saw at around the same time, 05.00 CET today, that you were logged in. (PC shutdown was ~05.30 CET.) Now it's 19.31 CET in Switzerland. Please try it again. Eventually I will not shutdown my PC on wednesday ~05.00 CET.

dear 'itman', thanks for looking at my video. This HIPS rule already exists ("allow direct access, [ALL activities]"), PerfectDisk is a commercial defrag tool by Raxco, thus there will happen no malware activity by it for sure. It's exactly this HIPS rule with its cascading HIPS notification popups that showed me something weird is happening in EIS V16.0.24! (The longer version: I made a "allow direct access, [ALL]" version of it because of another EIS HIPS bug introduced in EIS V16.0.24. And disabled a bunch of (very old) HIPS rules regarding PerfectDisk and "allow direct access, specific #1, #2, #3 etc". More about this one in another thread coming soon.) In short: PerfectDisk is working well since many years and many, many ESET ESS / EIS versions! Now there's this weird "buy license" "nonsense" bug. And this for the first time mentioned new HIPS bug, similar in a way to the (very old) HIPS Duplicates Bug (which is fixed) but definitely not the same.

I'm sorry for the long delay, here is the promised video, you can download it here: hxxp://mprogger.selfhost.ch:8080/hab-dich-ESET.wmv the video, ~15 minutes: - ~01:00 (mm:ss) first "buy license" in HIPS notifications cascade. I was able to repeat this "PerfectDisk START / CLOSE -> HIPS notifications cascade with 'buy license' warning (on the 1st notification popup)" cycle on each continuous trial. Somewhat strange: I'm quite sure having seen "buy license" appearing not only on the very 1st notification popup, but in between too, before doing this test video. Now I'm unsure about it. - ~02:18 the same thing starts in a few seconds, easily reproduced (always starting and closing PerfectDisk Pro, a disk fragmentation tool) - 04:39 now it's time to CLOSE and START the ESET EIS GUI, to see what's happening... - 05:37 crazy, already the first EIS GUI START showing "buy license" shortly! - 06:33 what's going on here? The second time! (Please take the full run, at least 05:37 to 06:33+) In between (~06:00) all I do is waiting before the next EIS GUI START (!!!) and bamm, the next "buy license"!) - now I'm trying to "mix" PerfectDisk START / CLOSE and EGUI START / CLOSE, ~08:38 the next EIS GUI "buy license" - hm, somewhere between 12:00 and the end I'm more than sure I saw a starting HIPS notification cascade where the first had "buy license" and a EIS GUI START showed the same "buy license", but this seems uncaptured?!? The latter disappeared always very quickly, presumably too quickly to be captured behind the dark HIPS notification popup. This was the time to stop capturing because everything was captured. Video downloadable until ~05.00, now it's 01.18 CET. Otherwise from ~15.00 - ~05.00 on this tuesday. I'll deliver these logs, but I guarantee you that you (ESET) will find nothing special, as it was the case last time with the HIPS Duplicates Popup Bug and these logs! There are some more boring HIPS and firewall rules - that's it... (hm, link icon in forum editor not working, pasting URL lead to 'hxxp://...'. What's going on here???)

@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

Wow, a quite fast bug correction, thanks... Yesterday, 20201216 at 17:06:18 CET the bug fix was installed on my PC. Look at the following screenshot, how this looked like. Immediately I switched to "help : installed components : COPY" or something like this. And when I reentered the firewall log view, all fields "target" were populated! Somewhat strange, but it shows me that the bug can't be in the firewall log file as such but in the firewall log view and the firewall export function. - the installed modules: Detection Engine: 22492 (20201216) Rapid Response module: 17445 (20201216) Update module: 1021 (20200218) Antivirus and antispyware scanner module: 1568.2 (20201214) Advanced heuristics module: 1203 (20201015) Archive support module: 1311 (20201125) Cleaner module: 1214 (20200921) Anti-Stealth support module: 1171 (20201106) Firewall module: 1411.3 (20201019) <--- good luck at finding out what module else had the bug, because it's not this one!... ESET SysInspector module: 1280 (20201022) Translation support module: 1833.1 (20201216) HIPS support module: 1403 (20201103) Internet protection module: 1416 (20201120) Web content filter module: 1079 (20201009) Advanced antispam module: 7864 (20201027) Database module: 1112 (20200928) Configuration module (39): 1914.2 (20201102) LiveGrid communication module: 1093 (20201216) Specialized cleaner module: 1014 (20200129) Banking & payment protection module: 1206 (20201202) Rootkit detection and cleaning module: 1029 (20200929) Network protection module: 1685.1 (20201006) Router vulnerability scanner module: 1071 (20201006) Script scanner module: 1084 (20201121) Connected Home Network module: 1040 (20200728) Cryptographic protocol support module: 1056 (20201113) Databases for advanced antispam module: 6176 (20201216) Deep behavioral inspection support module: 1109 (20201013) Advanced Machine Learning module: 1085 (20201207) Telemetry module: 1061.1 (20200706) Security Center integration module: 1026.1 (20201020)

Depending on your level of knowledge this might look so, but I'm pretty sure I haven't made an error in my analysis. Ie. I have exported all firewall (and HIPS logs) since ESET V4 and this is (hopefully - I will check it...) the first time this issue has shown up. The exported log before this bug has all "target" fields populated, and the temporarily exported currrent one has all "target" fields unpopulated! ("25.11.2020 18:54:44" (see previous post) is the last record of the last exported firewall log (as ".xml") and "25.11.2020 18:59:31" (see previous post) the first not yet exported firewall log entry.) You could check this easily too: go into firewall log view, right click and then "export all...", save as ".xml" (or better, depending on your computer proficiency, as ".txt"), double-click the exported ".txt", look at the first record and at the last: "target" field empty or not?!? Which time period do you have? (I have set all values in EIS V14 to "keep the log(s) forever" of course, ie. EIS V14 : setup : advanced setup : tools : log files : automatically delete records older than ... days".) an exported ".txt" firewall log looks like this one record: Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;SHA1;User 25.11.2020 18:54:44;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;THIS-IS-TARGET-FIELD:XXX;TCP;erlaubt XXXXXXXXXXX, 12.01.2020);C:\...\XXX.exe;SHA-1 hash;USERNAME With some luck you could see both states: records with target field empty and populated. If there are populated ones, hovering them will show its content in EIS firewall log view too, of course - except there's a bug in the log view too!... This would be an interesting check, if you could do it, please, I can't because - that's really crazy! - I made this last firewall log export about three minutes (!!!) after this AV update occured!

@jsb "damn it!", you were a little bit faster than I... But the following prepared post was too deep in the night written and I was too tired to post it after finishing it! I doubt this, more on this later today eventually. This would mean that the bug (thanks for confessing this, @Marcos) would be a log view problem or the like. Fact is, even exporting leaves the "target" field empty after a highly specific point in time! read on, the mentioned prepared posting at full length: here c & p directly from firewall log view working still...: 19.11.2020 15:53:38;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;XXXXXXXXXXXX:80;TCP;Allow XXXXXXXXXXXXXXXXXXXXX;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; ... today I noticed field "target" always empty, doing the very same c & p as above: 25.11.2020 18:59:31;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;NO-TARGET-FIELD-CONTENT-ANY-LONGER!!!;TCP;Erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, 03.12.2018);XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; conclusion: something very bad happened in between this time frame! But when did this happen exactly?!? even exporting the firewall log has this very same error now!... (the following one not a current one, but the FIRST non-working firewall log entry!): <RECORD> <COLUMN NAME="Time">25.11.2020 18:59:31</COLUMN> <COLUMN NAME="Event">Communication allowed by rule</COLUMN> <COLUMN NAME="Action">Allowed</COLUMN> <COLUMN NAME="Source">XXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="Target"></COLUMN> <--- BUG, BUG, BUG: bad, VERY VERY BAD!!! <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">Erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, 03.12.2018)</COLUMN> <COLUMN NAME="Application">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="SHA1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="User">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> </RECORD> ... but I'm able to nail down the bug insertion within a 5 minutes period (without any firewall log entries in between these two)!: <RECORD> <COLUMN NAME="Time">25.11.2020 18:54:44</COLUMN> <COLUMN NAME="Event">Communication allowed by rule</COLUMN> <COLUMN NAME="Action">Allowed</COLUMN> <COLUMN NAME="Source">XXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="Target">XXXXXXXXXXXXX:80</COLUMN> <--- good! <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, XX.XX.2020)</COLUMN> <COLUMN NAME="Application">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="SHA1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="User">XXXXXXXXXXXXXXXXXXXX</COLUMN> </RECORD> somewhat mysterious is the fact that within this time frame there was no EIS update whatsoever?!?: ?Time;Component;Event;User 25.11.2020 13:00:43;ESET Kernel;Detection Engine was successfully updated to version 22377 (20201125).;SYSTEM 25.11.2020 14:54:55;ESET Kernel;Detection Engine was successfully updated to version 22378 (20201125).;SYSTEM 25.11.2020 16:54:55;ESET Kernel;Detection Engine was successfully updated to version 22379 (20201125).;SYSTEM <--- look at THIS! 25.11.2020 20:54:55;ESET Kernel;Detection Engine was successfully updated to version 22380 (20201125).;SYSTEM 26.11.2020 00:54:56;ESET Kernel;Detection Engine was successfully updated to version 22381 (20201125).;SYSTEM a summer time / winter time bug (?!?). Here, at my location, we have CET time. And 16:54:55 could be, assuming such a bug / "issue", very well be 18:54:55 (= +02:00 hours). Timestamps are displayed correctly in general. But Win7 messes all times displayed up - after switching to for example winter time. Ie. correctly stored / displayed timestamps in summer time are WRONG after said switching to winter time. All of them. Eventually forever. They might be correct again during the next summer time. Now your developers have all informations they need to eliminate this catastrophic bug. As fast as possible. @MarcosMay I suggest logging the versions of all modules that are updated during an AV update too?! Because it can't be the "Firewall module: 1411.3 (20201019)" which is the current one installed on my PC...; wait a moment, it could very well be this one - because, as you know very well, there's a (huge) gap between new module versions and the arrival on a user's PC / Laptop / whatever device... here are the currently installed module versions (EIS V14.0.22): Detection Engine: 22482 (20201214) Rapid Response module: 17435 (20201214) Update module: 1021 (20200218) Antivirus and antispyware scanner module: 1568.1 (20201207) Advanced heuristics module: 1203 (20201015) Archive support module: 1311 (20201125) Cleaner module: 1214 (20200921) Anti-Stealth support module: 1168 (20200908) Firewall module: 1411.3 (20201019) ESET SysInspector module: 1280 (20201022) Translation support module: 1833 (20201202) HIPS support module: 1403 (20201103) Internet protection module: 1416 (20201120) Web content filter module: 1079 (20201009) Advanced antispam module: 7864 (20201027) Database module: 1112 (20200928) Configuration module (39): 1914.2 (20201102) LiveGrid communication module: 1087 (20201204) Specialized cleaner module: 1014 (20200129) Banking & payment protection module: 1206 (20201202) Rootkit detection and cleaning module: 1029 (20200929) Network protection module: 1685.1 (20201006) Router vulnerability scanner module: 1071 (20201006) Script scanner module: 1084 (20201121) Connected Home Network module: 1040 (20200728) Cryptographic protocol support module: 1056 (20201113) Databases for advanced antispam module: 6166 (20201214) Deep behavioral inspection support module: 1109 (20201013) Advanced Machine Learning module: 1085 (20201207) Telemetry module: 1061.1 (20200706) Security Center integration module: 1026.1 (20201020) kind regards

"wow", this time a fast HIPS module update, automatic AV update has just fetched HIPS V1331.1-20181025, subdirectory '..\1543\' - and guess what: no more the totally same "get access to another application" HIPS popups appearing over and over again, if in HIPS interactive mode and "daring" to save them! (And subdirectory '..\1541\', HIPS V1332-20181008, was deleted automatically.)

@MathewCXT: If you were in learning mode then check your HIPS rules please: it might be choke full with (empty, see picture #2) learning mode rules regarding "get access to another application" ones... (As explained above: you will never get out of the "get access to another application" HIPS popups loop if you "dare" to save the seemingly new HIPS rule(s)! And the corresponding program will never proceed with opening (XYplorer, Firefox) - unless you answer the popup with "remember until application quits" plus ALLOW button. Closing the program and restarting it leads to the same HIPS popup madness again...) The only HIPS mode you will notice this bug is the interactive one. @Rami: Not the case with EIS V11.2.63 to this very moment, ie. 10:53 CET. Hopefully the mentioned HIPS module reversion is far more speedy than the usual HIPS module rollout (HIPS V1332-20181008 was installed on my PC on 20181024 (!)...)