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 (!)...)

@mateusb: no, the culprit is a HIPS module update, read on for the full details!... @Marcos: This new HIPS bug definitely persists every computer restart and it was for sure introduced with the newest HIPS module update, HIPS V1332-20181008, subdirectory '..\1541\', installed on my PC on 20181024! It's a horrible pain to have to live with this HIPS module version!!! (I'm using EIS V11.2.63.) And it's ridiculously easy to reproduce the bug with this program (XYplorer, an Explorer alternative), .https://www.xyplorer.com/. The reproduction procedure: 0. look very closely at picture #1 (since HIPS V1332-20181008 such HIPS popups (ie. "get access to another application") are popping up endlessly and you can save them forever, with no apparent success: they are ignored completely!!! As you can see in picture #2). 1. install a trial version of XYplorer, https://www.xyplorer.com/. With this program the bug can be shown in its full extent ridiculously easy. (That's the way I fully tested this. Optionally, to spare some time, you could try it possibly with Opera V12.x, Firefox V62(+), Vivaldi V1.x(+) - all of these generate generate now a HIPS popup with "get access to another application", since HIPS V1332-20181008 only, though all of these programs have existing HIPS rules for years. Or try it with Opera V50+ / Vivaldi V2.x (totally untested).) 2. switch HIPS into interactive mode 3. start XYplorer, a HIPS popup similar to the one in picture #1 appears, save the rule as ALLOW (look closely at #1, radio button and check boxes) 4. there might appear other HIPS popups, answer them with "remember until application quits" plus ALLOW, concentrate on the XYplorer ones only! 5. the next HIPS popup from XYplorer appears, over and over again, with the 100% identical rule that you have stored already! Store at least three of them. XYplorer never opens until you answer this specific HIPS popup with "remember until application quits" plus ALLOW button! After that XYplorer works until you close the program and restart it. 6. restart XYplorer and the very same HIPS popup madness starts over again! Store another one of these rules. Answer the next HIPS popup with "remember until application quits" plus ALLOW button, close XYplorer. 7. edit your HIPS rules and check that every of your just saved rules were saved indeed!... (See picture #2!) ESET: no offence, but I really don't know how this blatantly obvious bug could slip through your quality control unseen. Of course, nobody will notice this bug ever if not using HIPS in interactive mode (hint, hint!)... How much more proof does ESET need this time until it acknowledges this bug?!? (edit: ouch, wrong HIPS version in the enclosed picture file names, it should be HIPS V1332-20181008, subdirectory '..\1541\', not HIPS V1541.)

on 20180803, after PC start with AV update, I started the firewall log viewer within ESS V10 as usual. Immediately noticing that my precious custom column width settings were destroyed... Investigating the cause of this incident I noticed that the column for the field 'target' is missing in the firewall log viewer of ESS V10. (Hovering over a firewall log entry, exporting the firewall log as ".xml" und ".txt" all include the field 'target'.) Considering the destroyed custom column width settings within the firewall log viewer the root cause must be an update within ESS V10 that was installed on 20180803.

Well done, ESET. The "unknown operation" HIPS log bug has been fixed with HIPS V1322-20180613, rolled out ("to me") on 20180702, see the following screenshot: (1) PC is starting, wrong field content, (2) an AV update with (3) HIPS module update gets automatically installed at 22:36:27, (4) immediately (22:36:29) after that all HIPS log entries with correct field content (5) (6). (Remains the question why the rollout to the ESET users takes a whopping ~19 days: V1322-20180613 <-> 20180702...)

Ahhh, finally the right decision. This bug is of a low severity and easy to fix. But don't forget the other highly disastrous bug that I reported... Since HIPS V1317-20180417 (and HIPS V1320-20180516) consistently reproducible after each and every AV update! Now with a ridiculously easy procedure to trigger it. It will not get any easier than this - the gold chance for ESET to catch this super bad bug! A logging HIPS rule and a not at all "special" action is all that's needed to trigger it - precise details in the PM, please read and do it! This will take only 5 - 9 minutes (*) of your super precious time!!! (*=the actual test, reading the PM post may take an additional ~10 minutes...)

How can you be so sure that only the modules you mentioned were updated on 05/29/2018?!? Are the updated modules logged since V11.x? If not one is forced to continually check this manually after each and every logged AV update... Hardly I can believe that you're running with HIPS V1320-20180516 before 05/29/2018, which was installed on my PC on 05/29/2018 21:59:17 and definitely not a single second before that date (see my screenshot)!!! HIPS V1317-20180417 was installed on my PC on 05/08/2018 22:18:08 - and I'm starting my PC every day, thus you can see there is a significant amount of time passing by until a new HIPS module update reaches my PC... No update on my PC till now - but if em018_64.dll and/or em018k_64.dll (the HIPS module) were really modified on your PC then it's easy to look if this bug has been fixed: check your HIPS log after, for example, some 'cmd.exe' action...

@Marcos/ESET: as the screenshot of itman shows even EIS V11.1.54 fills the HIPS log since HIPS V1320-20180516 with the very same constant text "unknown operation" as it's the case with previous versions of your software. All HIPS logs using HIPS V1320 are filled over and over with "unknown operation" forever, ie. until ESET corrects this easy to fix bug. Oh my, how much more proof does ESET need until they confirm this silly bug and fix it?!?

Thanks Marcos, but I'm sorry that you're wrong. Changing "logging all blocked operations" to disabled changes nothing - as I expected it in advance. Look more closely at the attached screenshot above: 21:58:49 (hh:mm:ss), the old HIPS V1317-20180417 is still active, and guess what, field operation filled with the correct action - "get access to file"! Now look at 21:59:21 plus the creation date of subdirectory '1529' (ask your developers what this means!), this is HIPS V1320-20180516, automatically downloaded and installed on 20180529 21:59:17! Since exactly this time field operation in HIPS log is always "unknown operation" (exporting the log - the very same thing, as expected) - hand this over to your developers please, they know 100% perfectly well why this happens, why it's a crystal clear new bug and what they should do now!...

yes, they do... (But read my private message please, the super bad bug I disclosed therein is now even worser - and ridiculously easy to reproduce since HIPS V1317-20180417. With your 'svchost.exe, start new app, cmd.exe' you're >50% or even >80% into my reproduction procedure, I could bet that it's triggerable even with your EIS V11.1.54!... Thank you very much.) @persian-boy: (this) "unknown operation" is no severe bug. As the screenshot clearly shows introduced with HIPS V1320-20180516. And easy to fix.

regarding all ESET versions (*), mine is ESS V10.1.235: HIPS V1320-20180516, which was installed on my PC on 29th May 2018, introduced yet another bug, as can be clearly seen in the attached screenshot. (Field 'operation' filled with 'unknown operation' since then. Up to this version it contained the correct description, for example 'modify startup settings' / 'write to file' / 'delete file'...) (*= ie. all versions that make use of HIPS V1320-20180516.) (Besides: this is not the only HIPS bug, there exist two others which are far more worse than this one. One of which I already have reported, which is since HIPS V1317-20180417 even worser - more on that later. For this one I have a ridiculously easy triggering procedure now. With HIPS V1317 and HIPS V1320 it's consistently triggerable after each and every AV update!!! Before HIPS V1317 it was "limited" to an AV update with a HIPS module update...)

1. switch HIPS to interactive mode, force a HIPS popup, for example by copying a file to 'C:\Windows\System32\', the HIPS popup appears with correct xyOps action type, for example 'delete file, write to file' or 'modify registry', ALLOW (or DENY) this action, but store it as a rule. Edit this freshly stored HIPS rule, where you will see "all xyOps operations" pre-selected (see the screenshot) - that's the bug, a new one. (The 'target' is - this time (HIPS V1267-20170216 - see my previous bug report, https://forum.eset.com/topic/7475-ess-v9x-a-2nd-hips-interactive-bug-check-all-your-new-relevant-hips-rules-if-you-trusted-v9-blindly/#comment-40274!...) - OK, ie. the target user selection is honored correctly. BUT there was an "in between" HIPS V12xx, ie. between 20170201 and 20170216, where the user selected target wasn't honored, ie. the dreaded ALL targets HIPS bug reappeared once again - see my already mentioned previous bug report... Apparently this bug has been (re-)fixed already.)