Jump to content

Fox Mulder

Members
  • Posts

    33
  • Joined

  • Last visited

Everything posted by Fox Mulder

  1. Jak jsem si všiml, blokovací pravidlo je ignorováno při každém startu NTB při 32bit verzi Win + ESET. Na 64 bit se toto neprojevuje. Tento můj problém zůstává bez reakce, ani se nikdo z ESETu nesnažil stáhnout logy z ESET Log Collector, působí to dojmem, jako když o tomto ESET ví, jen mlčí, aby o tomto problému vědělo co nejméně zákazníků... Jen doufám, že se pletu.
  2. Napadá mě, nemůže to být způsobeno, že se při startu počítače občas někdy opozdí start ESET Firewallu a systém Windows stihne komunikovat se servery MS dříve, než je plně aktivní firewall a všechna pravidla?
  3. Dobrý den, už podruhé jsem si všiml takového problému s vlastním pravidlem ve firewallu. Mám vlastní blokovací pravidlo pro službu Windows Update (WU), protože mám rád aktualizace Windows pod kontrolou a chci vidět, co se instaluje a zda správně. Pravidlo je zapnuto a když kliknu na tlačítko "Zkontrolovat aktualizace" systém po chvíli vypíše chybu "Zjištěna chyba - Nemohli jsme se připojit k aktualizační službě. Zkusíme to později znovu, nebo to můžete zkontrolovat hned. Pokud to pořád nefunguje, ověřte, jestli jste připojení k internetu." To je správně, tak to potřebuji a blokovací pravidlo tedy funguje správně. Jak jsem zmínil, už 2x jsem si všiml, že po zapnutí NTB se i přes aktivní blokovací pravidlo pro WU, dokázal počítač spojit s Windows Update a aktualizace si stáhnout a instalovat. Je pravda, že hned pod tím blokovacím pravidlem pouze pro službu WU, mám hned jako další povolující pravidlo pro svchost.exe (pro ostatní systémové služby), který služba WU také využívá, nicméně pokud vím, pravidla jsou přece vyhodnocována shora dolů, a první se použije první vyhovující, tedy to blokující pro službu WU. Jak je to možné (vždyť po ručním kliknutím na "Zkontrolovbat aktualiazce" se služba WU k jejich severu nepřipojí, jak už jsem zmínil výše. Existuje nějaké rozumné vysvětlení, proč blokující pravidlo občas selže? Zasílám logy z ESET Log Collector k vyhodnocení. Děkuji. eis_logs (P50IJ).zip
  4. Teď jsem zjistil, že na PC s Win 10 x64, kde bylo na novou verzi 17.0.15.0 aktualizováno (nikoli čistá instalace), se při úpravě pravidla zobrazuje kompletně celá cesta k aplikaci. Jak to tedy je, proč se při čisté instalaci ESETu v 17 na Win 10 x32, zobrazuje jen konečný exe soubor, ale při aktualizaci z verze 16 na verzi 17 se stále zobrazuje celá cesta k aplikaci (viz screenshot)? Píšete, že nezobrazení celé cesty je záměr, proč to tedy je na dvou PC rozdílné? Díky.
  5. Už je termín opravy alespoň přibližně znám? Rád bych si novou verzi nainstaloval. Obávám se, aby se oprava tohoto problému neodsunovala na později a později.
  6. Yes, without the robot, ESET's typical symbol, the "Overview" screen at the top right is unusually empty. On the screen that appears shortly after ESET starts, I really don't understand what the picture is supposed to express. It just reminds me of an unwrapped cookie with several layers of chocolate... :-)
  7. Aha, vypadalo to jako chyba. Jediným způsobem tedy, jak zjistit, zda se uživatel nepřeklikl při vytvoření cesty k souboru v administrátorském režimu, je tedy jen odstranění kliknutím na x, a znovu zadáním cesty. Ale dobře, v pořádku. Dobře, díky za vysvětlení. Bude to aktualizace přímo programu (např. 17.0.16.0) nebo jen konkrétního modulu? Kdy asi tak hotfix vyjde v normálním kanále aktualizací a jakou bude mít verzi? Děkuji.
  8. Snad oprava tohoto problému s nemožností vybrat službu bude rychlá. Ano, narazil jsem na další problém ve verzi 17. Ve stejném již zmíněném dialogu je položka "Cesta k aplikaci", problém je v tom, že se zde při editaci pravidla nezobrazuje celá cesta k aplikaci, ale jen konečný *.exe soubor (např. firefox.exe). Měla by tam být uvedena kompletní cesta, tedy C:\Program Files\Mozilla Firefox\firefox.exe. Bohužel celá cesta se nijak nezobrazí ani při najetí myší na položku, nezobrazí se ani v seznamu všech pravidel po vybrání konkrétního pravidla, v té pravé části v podrobnostech o pravidlu. Tudíž nelze nijak zjistit cestu k souboru uvedeného u položky "Cesta k aplikaci". Další drobnost je, že po instalaci ESETu a následném spuštění prohlížeče Firefox, se po chvíli v pravém dolním rohu zobrazí informace, že si můžu zapnout rozšířenou ochranu soukromí v prohlížeči. Po chvíli informace zmizí. Když se ale podívám do rozšířeného nastavení ESETu, vidím, že tato ochrana soukromí je již ve výchozím nastavení zapnutá. Proč se tedy zobrazí informace, že si tuto ochranu soukromí můžu zapnout, když už je ve výchozím nastavení zapnutá? Ale toto je skutečně jen velmi malá drobnost, která se dá přehlédnout. Ale ptal jste se, jaký další problém jsem ve verzi 17 objevil, tak jsem vám to sdělil.
  9. Pokud vytvořím vlastní pravidlo ve firewallu, zadám cestu k aplikaci, bohužel už nejde zadat službu. Po rozkliknutí řádku "Služba" nevyjede žádný seznam služeb (viz screenshot). Jde o novou verzi 17.0.15.0. Nejde tam ani napsat název služby ručně. Dělám něco špatně nebo jste zase něco pokazili? Bohužel poslední dobou je těch chyb při vydávání nových verzí stále více než v předchozích letech... Díky.
  10. Super, jsem rád, že byl konečně problém identifikován. Předpokládám, že se tím vyřeší i to, že i po stornování testu test běží dále desítky minut. Asi půjde jen o doprovodný problém toho prvního. Můžete sem napsat jaká bude verze toho Cleaner modulu, kde bude potíž již vyřešena?
  11. Zasílám požadované logy. eis_logs (P50IJ).zip ekrn_09ec278a_554 (dmp).rar ekrn_09ec278a_554 (mdmp).rar
  12. Marcos, I'm sorry, but I think you still don't understand what our problem is. It is not about the total length of the deep scan (when absolutely everything is tested, including the contents of the archives), but the fact that the deep scan stops for a very long time on one scanned file to which the registry refers. This particular file is a few KB and ESET tests it for tens of minutes to hours, as user Tio writes. Even adding new packers cannot affect this file, as this file is not an archive and even if it was, it is only in the order of KB, it would have to be tested in a few seconds. In addition, if the mentioned file(s) was previously tested by ESET in seconds and now hangs on it for tens of minutes to hours (on a single file referencing from the registry), there is probably something wrong with ESET. I mentioned this exact same problem earlier in the Czech part of the forum. And since this problem manifested itself for me again, I will send the requested logs to the Czech part of this forum.
  13. I think Tio has the same problem already addressed here https://forum.eset.com/topic/38249-scan-is-not-working-properly/ . Yesterday I tried a deep test on one of the laptops and again the test got stuck (when testing registry key values) at C:\Windows\System32\bi.dll, C:\Windows\System32\mi.dll, C:\Windows\System32\ping.exe etc. When I clicked the cancel test button, the buttons were grayed out and the test continued (on the same bi.dll file), after about 50 minutes I had to restart the computer to end the test. Evidently, the problem persists and the cause has not yet been identified.
  14. I described the same problem in the Czech part of the forum. Obviously someone else is having the same problem and it's not just a specific user problem. I had the problem in the first deep test after the release and installation of the Windows September 2023 updates, in the second deep test the situation did not appear and the test on the mentioned files took the usual time without any lags on the mentioned files. I will see how the test behaves with another deep scan after the October 2023 Windows Updates.
  15. Ano, jde skutečně o test registru, jen jsem se asi nesprávně vyjádřil. Spíše než o klíče registru, jde o hodnoty klíčů registru odkazující na konkrétní soubory na disku (odhaduji, že právě toto ESET zobrazuje v průběhu kontroly registru). Pokud si vyberu Pokročilé kontroly - Volitelná kontrola - vyberu hloubkovou kontrolu a zaškrtnu Registr systému, téměř během celého testu registru se zobrazují právě mnou uvedené (a samozřejmě i jiné cesty) k souborům. Jen s tím rozdílem, že cesty jsou vždy pouze malým písmem oproti tomu, jak jsem je napsal já. To, co jste uvedl v ukázce (přímo klíče registru), se také zobrazí, ale jen v minimální míře. Ohledně zmíněného problému v původním dotazu, si ještě potřebuji ověřit jednu situaci, to ale je možné, až Microsoft vydá aktualizace systému následující měsíc, poté bych případně doplnil nový poznatek. Prozatím děkuji.
  16. Promiňte, ale nejsem si jist, zda jsme se správně pochopili. Nejde o celkovou délku testu registru (zde vím, že může trvat delší dobu - vždy trvala 25 minut), ale jde o délku testu pouze některých jednotlivých zmíněných klíčů, který trvá neúměrně dlouhou dobu. Ano, nemuselo se nic změnit v testování registru ze strany ESETu, jak píšete, ale možná dochází k nějakému konfliktu se zmíněnými soubory, po aktualizacích Windows z 12.9.23. Proč najednou otestování zmíněných několika klíčů trvá skokově tak dlouho...? Před instalací aktualizací Windows jsem během testu registru ani nezaznamenal, že tam tyto klíče jsou, teď na nich ESET bohužel visí dlouho.
  17. Dobrý den, chtěl bych vám nahlásit problém s testováním registru v programu EIS. Problém se objevil po nainstalování aktualizací Windows z úterka 12.9.2023, je tedy možné, že to právě s některou aktualizací určitým způsobem souvisí. Asi nezáleží na systému nebo bit systému, mně se to projeví na Win 11 x64 i na Win 10 x32 a to na všech počítačích, kde jsem to zkoušel. Popíšu potíž: Při hloubkové kontrole, kdy se také testuje registr Windows, se program EIS na některých souborech (klíčích) registru zastavuje na dlouhou dobu oproti jiným. Test se zastaví např. u herního NTB s šestijádrovým (dvanáctivláknovým) procesorem na jednom souboru 4 minuty až 10 minut. Pokud během testu registru tyto testuje několikrát opakovaně, dobu testu to výrazně prodlouží. Dříve kompletní hloubková kontrola mi trvala 40 minut, nyní to je 2 hodiny 10 minut. Zkusil jsem test registru i na starém NTB s dvoujádrovým procesorem, kde byly časy zastavení klidně i 23 minut na jediném souboru. Zde uvádím dané soubory (klíče registru) u kterých se program EIS zdržuje dlouho: C:\Windows\System32\bi.dll (cca 4 min u herního NTB, u starého NTB 23 min) C:\Windows\System32\ci.dll (cca 4 min u herního NTB, u starého NTB jsem test raději zrušil a dále nepokračoval) C:\Windows\System32\mi.dll (cca 4 min u herního NTB) C:\Windows\System32\ping.exe (cca 4 min u herního NTB) C:\Windows\SysWow64\control.exe (cca 8 min u herního NTB) C:\Program Files\MicrosoftOffice\root\Office16\addins\Eduworks\Data streamer add-in\Microsoftdatastreamerforexcel.vsto (cca 10 min u herního NTB) U jiných souborů (klíčů registru) je to zcela normální, EIS se zastaví jen na jednotky sekund. Na starém NTB jsem provedl test registru před instalací aktualizací Windows a EIS se nikde na dlouho nezastavoval. Poté jsem nainstaloval aktualizace z 12.9.23 a znova provedl test registru - od této chvíle začalo docházet ke zdržování EIS na výše zmíněných souborech (klíčích registru). Můžete si prosím situaci zkusit navodit a případně zanalyzovat kde by byl problém? Děkuji
  18. Myslím, že byste měli překontrolovat pro jistotu všechna vestavěná pravidla, jelikož jsou tam odlišné směry nejen i pro ty dvě další pravidla, které také vidíte na screenu v předchozím příspěvku, ale je špatně i např. "Povolit synchronizaci času (NTP)". Zde je také komunikace povolena jen dovnitř, a tudíž synchronizace nefunguje.
  19. V případě, že by někdo měl stejný problém, zde je rozřešení problému. Potíž je v tom, že ve vestavěném pravidlu firewallu, které povoluje získávání IP adresy, je v nové verzi 16.2.11.0 povolena komunikace pouze dovnitř (viz zaslaný screenshot). Notebook ale pro získání IP chce komunikovat ven (viz další screenshot), což mu právě toto nastavení pravidla znemožňuje. Ve starší verzi 16.1.14.0 je toto pravidlo odlišné - je tam povolena komunikace oběma směry, tedy ven i dovnitř (viz třetí screenshot). Proto ve starší verzi než došlo k aktualizaci, získávání IP adresy z DHCP fungovalo bez problémů. Toto se projevuje jen ve firewallu nastaveném na administrátorský režim (jako to mám já), v automatickém režimu, který je výchozí a povoluje vše odchozí, se to samozřejmě neprojeví. Netuším, zda jde o záměr programátorů nebo chybu...
  20. Ano, jen bezdátově do Wi-Fi sítě. Je to moje domácí síť, ale jako veřejnou (nedůvěryhodnou) ji mám označenou záměrně kvůli přísnějším vestavěným pravidlům firewallu. Nicméně před aktualizací 16.2.11.0 fungovalo přiřazování parametrů sítě z DHCP bezchybně i při veřejně označené síti. I tak jsem ji ale zkusil označit jako důvěryhodnou dle vašeho obrázku, ale bohužel ani toto nijak nepomohlo - získávání parametrů sítě je stále blokováno.
  21. Zasílám logy z ESET Log Collector při zapnutém rozšířeném protokolování. Bohužel dalším krokem nemůžu pokračovat, jelikož netuším, která je ta příslušná komunikace, kterou bych měl odblokovat pro komunikaci s DHCP - je jich tam vetší množství, obzvlášť po zapnutí/restartu počítače. Která by měla být ta správná? Můžete mi sdělit, jak by tyto detaily pravidla pro komunikaci s DHCP měly vypadat? Žádnou komunikaci IP adresy kterou má můj router (v něm běží DHCP), s počítačem či opačným směrem tam blokovanou nevidím. Co přesně bych tam měl hledat? Díky. eis_logs (NTB Asus P50IJ - rozšířené protokolování).zip
  22. Doplňuji další poznatek z testování této situace: Provedl jsem odinstalaci EIS pomocí ESET Uninstalleru a čistou instalaci verzí 16.2.11.0, ale bohužel ani toto nijak nepomohlo k vyřešení problému. Zjistil jsem, že po nainstalování EIS 16.2.11.0 se může notebook restartovat a parametry sítě od DHCP dostává, ale jakmile se notebook vypne, při následném zapnutí už od DHCP nic nedostane. ESET to bohužel blokuje.
  23. Ještě přidávám logy z ESET Log Collector. Možná Marcos by z nich něco vyčetl... Díky za případné reakce. eis_logs.zip
×
×
  • Create New...