Jump to content

Archived

This topic is now archived and is closed to further replies.

surfer1000

New Build Available! (349)

Recommended Posts

These QA tests had have been made in the beta stadium.

Every installer must pass QA tests before it's released. ESET focuses on quality of their products and NEVER releases newer builds (installers) immediately after compilation. Note that there are 36 language versions and for each there are 4 installers (Windows XP / Windows Vista+, x86/x64) which makes up 144 installers in total to test.

I don't know who the beta testers are, but no good job was done.

It's for me the first version of ESET with so many bugs.

And reading this forum still more bugs are shown

We are not talking about beta testers as beta testing of v9 was finished months ago before the first v9 went gold. I was talking about QA tests that are done internally before any new installers are released. With newly added strings and possible changes in existing translation, each version must be tested for localization bugs as well as technical bugs.

You mentioned that v9 has "so many bugs". Please create a new topic with each alleged "bug" listed so that we can comment on it. I, for one, am not aware of any bug in ESET products v9.0.349+.

Also it's obvious that there's nothing like 100% bug free software; be it Windows or any other third party application, no matter how long and deeply a product is tested before it's released.

Share this post


Link to post
Share on other sites

I, for one, am not aware of any bug in ESET products v9.0.349+.

 

 

I posted 2 bugs here in the forum:

 

Bug 1

 

Bug 2

Share this post


Link to post
Share on other sites

Version 9.0.349 has been released in all language versions. It will just take a while until the version information on the website is updated.

Share this post


Link to post
Share on other sites

Version 9.0.349 has been released in all language versions. It will just take a while until the version information on the website is updated.

 

Great but i wait longer to install that version, when i read at this forum that version 9.0349 has still bugs.

The Cestina version has already version 9.0.351.3 so i wait certenly for that version also available is for the Dutch version

Share this post


Link to post
Share on other sites

 

Version 9.0.349 has been released in all language versions. It will just take a while until the version information on the website is updated.

 

Great but i wait longer to install that version, when i read at this forum that version 9.0349 has still bugs.

The Cestina version has already version 9.0.351.3 so i wait certenly for that version also available is for the Dutch version

 

 

There are no known bugs in v9.0.349.

Share this post


Link to post
Share on other sites

Well i read here at this forum dat several users have same problems with version 9.0349.

What is the changelog of version 9.0351.3? If there were no problems with version 9.049 why is there a Cestina version 9.0651.3?

Share this post


Link to post
Share on other sites

no difference in the official changelog

 

9.0.349.0

  • Added: Support for screen reader software (JAWS)
  • Added: Support for Outlook 2016 (Antispam plugin)
  • Added: License info about seat count
  • Fixed: Issues with printing and Windows updates
  • Fixed: Wrong categorization of virtual networks
  • Fixed: Issues with settings migration when upgrading from previous versions
  • Changed: Updated list of application status messages
9.0.351.2
  • Added: Support for screen reader software (JAWS)
  • Added: Support for Outlook 2016 (Antispam plugin)
  • Added: License info about seat count
  • Fixed: Issues with printing and Windows updates
  • Fixed: Wrong categorization of virtual networks
  • Fixed: Issues with settings migration when upgrading from previous versions
  • Changed: Updated list of application status messages

Share this post


Link to post
Share on other sites

It's exactly as I wrote 2 months ago, the hip problem is also not included in the new build 349 Fixed as Eset it can not correct because when Windows 10 every process gets a new random ID every time you start and the Eset Hip then every Thinks it is a new process, but what it's not, and therefore the rules previously created then are ineffective and of any rule that there are thus 200 or 300 and of course it is annoying that each rule thus has no effect and for the functionality of Eset Hip it is also not good if there are then 4000 or 5000 rules and every rule 100s male exists !!! Eset let it rather with Windows 10, I'll give the whole now time to Heise and so on, because I have of your fairytale erzählerei fed up!)

( German: Es ist genau wie ich vor 2 Monate schon schrieb, das Hip Problem wird auch nicht im neuen Build 349 Behoben sein da Eset es nicht beheben kann da bei Windows 10 jeder Prozess bei jedem Start eine neue zufällige ID bekommt und das Eset Hip dann jedesmal Denkt das es ein neuer Prozess ist, was es aber ja nicht ist und daher sind dann die zuvor erstellten Regeln wirkungslos und von jede erstellte Regel gibt es dadurch 200 oder 300 und es nervt natürlich das jede Regel dadurch wirkungslos ist und für die Funktionalität vom Eset Hip ist es auch nicht gut wenn es dann 4000 oder 5000 Regeln sind und jede Regel 100te male vorhanden ist!!! Eset lasst es lieber mit Windows 10, ich werde das ganze jetzt auch mal an Heise usw. weiter geben, denn ich habe von eurer Märchen erzählerei die Schnauze voll!)

The support was me by the German Eset confirmed, so what always deny this error here, the forums are full of it, so stop users for stupid to sell !!! Especially nominal user for stupid to sell the zich years for you your betas has tested for this behavior Ugh !!! It has nevertheless also hinbekommen Kaspersky, maybe you should work with MS times more!

(German: Das wurde mir auch vom Deutschen Eset Support Bestätigt, also was soll immer das leugnen dieses Fehlers hier, die Foren sind voll davon, also hört auf User für dumm zu Verkaufen!!! Vor allem nenn User für dumm zu Verkaufen der zich Jahre für euch eure Betas getestet hat, Pfui für dieses Verhalten!!! Es hat doch Kaspersky auch hinbekommen, vielleicht sollte man mal mehr mit MS zusammenarbeiten!)

Share this post


Link to post
Share on other sites

SlashRose, we kindly ask you to use gentle tone and avoid using inappropriate language which is against TOS. We are not aware of any bugs in HIPS and I've been using rules personally for ages without issues. Of course, each time a new process is created it's assigned a different PID. I'd suggest creating a new topic where the issue could be discussed further, with step-by-step instructions how to reproduce it. Maybe it's just misunderstanding of how things work but for now I won't speculate until we get more information. Also it's enough to use English from now on as this is English forum and not many users speak German.

Share this post


Link to post
Share on other sites

I've been using it since the v2, had long before there was this forum Tested for you for you 6 or 7 years the betas, do not you think I know that because how does Eset?

( German: Ich Nutze Eset seit der v2, habe für euch lange bevor es dieses Forum gab für euch 6 oder 7 Jahre die Betas Getestet, meinen sie nicht das ich da weiß wie Eset Funktioniert?)

Share this post


Link to post
Share on other sites

If our German friend @rugk was around, maybe he could have explained a thing or two in German to Slashrose and clear a few things up as it feels we go around in circles now.

Share this post


Link to post
Share on other sites

(...) We are not aware of any bugs in HIPS and I've been using rules personally for ages without issues. (...) Also it's enough to use English from now on as this is English forum and not many users speak German.

 

"not aware of any bugs in HIPS": I'm able to report 2 bugs in HIPS, that have nothing to do with Win10, because I'm using Win7 Pro 64-Bit. I call the first bug "The Dreaded HIPS Duplicates Bug, even with ESS V9.0.349.0" and the 2nd one "HIPS Definitively Stops Logging And Working". Bug #1 started immediately after installing 1st ESS V9 version (german) over ESS V8 (english) - but this has nothing to do with german version over english version. Later I installed ESS V9.0.349.0 english over the previous V9 (german) version.

 

"in HIPS and I've been using rules personally for ages without issues": the same with me - until ESS V9 came out and I installed it...

 

@SlashRose: keep on writing german, as a native german speaking person I'm understanding your german far better than your english (no insult intended here). Thanks.

 

@Marcos: SlashRose is meaning that the german ESET support has confirmed that the HIPS duplicates bug exists really and he doesn't understand why english support (this forum) is denying it (still).

 

I will describe bugs #1 and #2 in separate threads far more detailed than now (it's 5 o'clock in the morning...), but here a sample screenshot of bug #1 in advance (1525 HIPS rules (thanks for counting, if it's correct, a new feature of ESS V9), and around 200 highly annoying time consuming duplicates ("Doublette" in german)! And counting...).

 

regarding the screenshot:

- "I REALLY, REALLY, REALLY, REALLY, REALLY, REALLY, REALLY, REALLY HATE ESS V9!!!": please add " - but only until the highly capable ESET developers have eradicated a bunch of very nasty / nasty bugs, and highly annoying regressions".

- lines marked yellow: 'consent.exe' (UAC) and 'dllhost.exe' ("file save as", other functions) are very common HIPS duplicates, mostly daily.

- enabling / disabling PCAP, new firewall popups (and being forced to change them immediately - hint, hint: one of the highly annoying regressions, ie. firewall rule without check box "log it"...) and new HIPS popups (especially changing the description afterwards, ie. being forced to change it afterwards - hint, hint: the 2nd highly annoying regression, I think) accelerate the probability of duplicate HIPS popups significantly.

post-3617-0-16641900-1453002521_thumb.png

Share this post


Link to post
Share on other sites

I will describe bugs #1 and #2 in separate threads far more detailed than now...

Also please drop me a pm with the output from ESET Log Collector so that I can check and compare the HIPS rules that were created. Personally I've never come across an issue with v9 when 100% identical rules were created.

Share this post


Link to post
Share on other sites

(...) We are not aware of any bugs in HIPS and I've been using rules personally for ages without issues. (...) Also it's enough to use English from now on as this is English forum and not many users speak German.

 

"not aware of any bugs in HIPS": I'm able to report 2 bugs in HIPS, that have nothing to do with Win10, because I'm using Win7 Pro 64-Bit. I call the first bug "The Dreaded HIPS Duplicates Bug, even with ESS V9.0.349.0" and the 2nd one "HIPS Definitively Stops Logging And Working". Bug #1 started immediately after installing 1st ESS V9 version (german) over ESS V8 (english) - but this has nothing to do with german version over english version. Later I installed ESS V9.0.349.0 english over the previous V9 (german) version.

 

"in HIPS and I've been using rules personally for ages without issues": the same with me - until ESS V9 came out and I installed it...

 

@SlashRose: keep on writing german, as a native german speaking person I'm understanding your german far better than your english (no insult intended here). Thanks.

 

@Marcos: SlashRose is meaning that the german ESET support has confirmed that the HIPS duplicates bug exists really and he doesn't understand why english support (this forum) is denying it (still).

 

I will describe bugs #1 and #2 in separate threads far more detailed than now (it's 5 o'clock in the morning...), but here a sample screenshot of bug #1 in advance (1525 HIPS rules (thanks for counting, if it's correct, a new feature of ESS V9), and around 200 highly annoying time consuming duplicates ("Doublette" in german)! And counting...).

 

regarding the screenshot:

- "I REALLY, REALLY, REALLY, REALLY, REALLY, REALLY, REALLY, REALLY HATE ESS V9!!!": please add " - but only until the highly capable ESET developers have eradicated a bunch of very nasty / nasty bugs, and highly annoying regressions".

- lines marked yellow: 'consent.exe' (UAC) and 'dllhost.exe' ("file save as", other functions) are very common HIPS duplicates, mostly daily.

- enabling / disabling PCAP, new firewall popups (and being forced to change them immediately - hint, hint: one of the highly annoying regressions, ie. firewall rule without check box "log it"...) and new HIPS popups (especially changing the description afterwards, ie. being forced to change it afterwards - hint, hint: the 2nd highly annoying regression, I think) accelerate the probability of duplicate HIPS popups significantly.

It's the same, you have me Got!

(German: Genau so ist es, du hast mich Verstanden)

Share this post


Link to post
Share on other sites

Time a small part of double and triple Hip created rules, there are exactly the same and that is in every Hip mode

(German: Mal ein kleiner Ausschnitt von doppelt und dreifach erstellten Hip Regeln, es sind exakt die gleichen und das ist in jedem Hip Modus)

post-1266-0-34176600-1453042842_thumb.png

Share this post


Link to post
Share on other sites

And the whole again in Interactive Mode

(German: Und das ganze nochmal im Interaktiven Modus)

post-1266-0-57417900-1453043367_thumb.png

Share this post


Link to post
Share on other sites

 

I will describe bugs #1 and #2 in separate threads far more detailed than now...

Also please drop me a pm with the output from ESET Log Collector so that I can check and compare the HIPS rules that were created. Personally I've never come across an issue with v9 when 100% identical rules were created.

 

It happened to me while in "Learning mode" when I tried ver. 9. Also posters on Wilders indicated the same issue is present in ver. 8.

Share this post


Link to post
Share on other sites

Has the jumbled existing HIPS rule problem, i.e. existing ver. 8 allow and block rules interspersed with no rhyme or reason, been fixed in the latest ver. 9 release?  

Share this post


Link to post
Share on other sites

Has the jumbled existing HIPS rule problem, i.e. existing ver. 8 allow and block rules interspersed with no rhyme or reason, been fixed in the latest ver. 9 release?

This problem also exists in the last Eset v9 Build! Eset do not know how to solve this problem!

Share this post


Link to post
Share on other sites

 

Has the jumbled existing HIPS rule problem, i.e. existing ver. 8 allow and block rules interspersed with no rhyme or reason, been fixed in the latest ver. 9 release?

This problem also exists in the last Eset v9 Build! Eset do not know how to solve this problem!

 

Really don't know what the issue here is for Eset.

 

Prior to ver. 9, it is fairly obvious that that Eset's HIPS GUI was sorting rules by alphabetic order. The result would be:

 

User rule: allow ..................

 

would be sorted prior to;

 

User rule: block ..................

 

What was never answered by Eset is if the problem is just a GUI issue and that all HIPS allow rules are indeed being processed prior to any block rules? 

Share this post


Link to post
Share on other sites

If you need to see specific rules in v9, you can use the new filter function. Click the magnifier icon and enter "block" to display only blocking rules or the name of an application to filter, etc. As fot the priority, blocking rules have higher priority over allowing rules and more specific rules supersede general rules. However, it's possible that we'll change the evaluation of rules so that it works by order.

Share this post


Link to post
Share on other sites

As fot the priority, blocking rules have higher priority over allowing rules

 

Doesn't work that way in ver. 8.

 

For example, I created a user block rule with "ask" specified to prevent all actions against a specific and all subordinate registry keys. Later, I received an alert that some system activity wanted to delete a subordinate key. I let Eset create a rule to allow the deletion of the subordinate key. Never received any further alerts and Eset HIPS logging showed the activity being allowed. I have many more examples of allow rules being executed prior to block rules. 

 

Hence my conclusion validated by the above that Eset HIPS parses user rules in a top to bottom fashion in ver. 8.

 

If what you say is true about block/ask rules being evaluated prior to allow rules in ver. 9, it is against conventional HIPS/anti-exec operation. Without any rule, the operation is allowed by default. You create a user block HIPS rule in "ask" mode to prevent/monitor certain activity globally then if necessary create an allow rule for exceptions.

 

Finally, you do not radically alter the previous operation of a HIPS in a new release. Doing so invalidates all the work done previously. Appears Eset really doesn't care about the impact of changes on their existing customer base. My license is coming up for renewal soon. If all. ver. 9 issues are not resolved prior to that date, I will not be renewing my license. Will just switch to Comodo and save myself some money to boot. Nor will I recommend Eset to others.

Share this post


Link to post
Share on other sites

For example, I created a user block rule with "ask" specified to prevent all actions against a specific and all subordinate registry keys. Later, I received an alert that some system activity wanted to delete a subordinate key. I let Eset create a rule to allow the deletion of the subordinate key. Never received any further alerts and Eset HIPS logging showed the activity being allowed. I have many more examples of allow rules being executed prior to block rules.

I've tried to reproduce this with v8. When prompted for an action upon an attempt to delete a subordinary key, I expanded Advanced options as the rule would be otherwise created for operations not limited only to that registry key and checked the appropriate check-box. It worked as expected - I was not prompted again when deleting the very same key repeatedly but I was asked for an action when attempting to delete a different subordinary key.

post-10-0-70719800-1453221789_thumb.png

I'm going to test the same scenario with v9 and will post my findings shortly.

Update: It works the same way in v9 too:

post-10-0-02825200-1453222807_thumb.png

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...