Microbe

Hi ESET, Question : Is there a way to point to another server, e.g. US or Singapore? Example the Update server is located in Singapore > then once the update server has been update > the modules updates or virus signature from ESET Update server will push to all the client in Australia. On the screenshot below > we tried the steps from https://support.eset.com/en/kb2850-troubleshooting-for-modules-update-failed-message the link and problem still exist, we would like to ask what will be the next steps? do i need to collect logs? Then the affected devices would 25 devices 5 license for ESET Server security 20 license for ESET Endpoint antivirus all of the machine have the similar issue modules update failed. Cheers, Gil

Hi Marcos, Next time i will do that I will send the logs, once i get it thanks Cheers, Gil

Hi Team , I would like to ask how to resolve this case See with bold word: It appeared that the initial problem (Message Error allocating memory.RefID: ref:!00D0Y01lCTe.!500Vk02IoIB:ref) had been resolved but now another update issue has appeared. General compiler error. Cheers, Gil

Hi eornate I advised to the client to client to contact their internet provider, since a lot of customers who are using Telstra as internet provider are experiencing troubles with the ESET modules update. This client called me and he informed me that the resolution from their internet provider is to have the replacement of new modem, when they got a new version of modem and connect to the internet the problem has been resolved Cheers, Gil

You can now closed this issue. Problem has been resolved Cheers, Gilben Castro

Thank you Marcos you can now closed this post :) Cheers, Gilben Castro

Hi ESET Team, We don't want to say things or answer his question if we are not totally sure, so see the below questions of our client: 1. Hi again . I think I can see what’s happening with this, after more playing around with it. You might like to confirm on your setup what I’m seeing here … the profile selection in the scheduled task is not independent from the profile selection in the Advanced Setup / Malware Scans / On-demand Scan configuration. This is very misleading, or a bug. If the profile selection in a scheduled scan job has to be governed by the Malware Scan / On-demand Scan profile selection, there really shouldn’t be a selection box for the on-demand scan profile in the task scheduler. In that case, could you get ESET to remove the selection box from the job scheduler in the next software release please? It should simply display what the default on-demand profile selection is (based on the setting in Malware Scans / On-demand scans). If it’s a bug though, and the profile type of the on-demand scan is actually supposed to be selectable for a scheduled job, can you report the bug to ESET so that can be addressed please? This would seem the most likely scenario, because otherwise how could someone set up multiple scheduled jobs for different types of on-demand scans if they wished? … like a weekly scan that excludes archives and a monthly scan that includes archives for example. 2. Hi i said you were away on Thursday and Friday which is good, because on re-reading my last messages (attached) I realised I should provide some more clarification and an example … Below, when I say this: “… the profile selection in the scheduled task is not independent from the profile selection in the Advanced Setup / Malware Scans / On-demand Scan configuration” what I mean is that I’ve found the scan profile I try to set for the scheduled task always just reverts to whatever is showing at the time in the profile selection box on the “Advanced Setup / Malware Scans / On-demand scan” page, so that selection determines what type of scan is done, NOT the profile that I selected for the scheduled task. For example, if I select “Smart Scan” as the profile for a scheduled on-demand scan job, but what is displaying as the last profile I was looking at on the “Advanced Setup / Malware Scans / On-demand scan” page is the “In-depth Scan” profile, the scheduled job will run as an In-depth Scan, NOT a Smart Scan, and “In-depth Scan” will show as the selected profile when I revisit the configuration of the scheduled task, NOT the “Smart Scan” profile I’d previously selected and saved for that task. I hope that’s clearer, Gil. Surely those two things should be independent of each other and it’s a software bug, right? Please help us about the right response to our customer Cheers, Gil

Thank you i will share the above information Thank you very much ESET

Hi Marcos, Can you help us to give the best answer on his question? Hi Gil. I made some significant observations and asked for some answers or confirmations in my email. These are all very important to my use of ESET, and since ESET HQ haven’t specifically responded to any of those, could you give considered responses to each point please? It seems that he need more information regarding on his concern: I found that my normal weekly scans had been scanning Archives, so I disabled that in all these latest scans as you suggested, and I guess that’s what made a big difference. I’ll make sure Archives remain disabled in future weekly scans, thanks. Answer: If the user has disk images and other big archives in a specific folder(s) on a disk, it'd be better just not to select this folder(s) in scan targets rather than disabling archive scanning completely. I have no idea where all the archives are. Based on scan numbers, there must be something like 3.5 million objects involved (!), which I just can’t fathom at all. Most must be system-related I guess. If I continue with weekly scans at all (see below), I think for the sake of practicality I’d have to stay with the option of excluding Archives from the scans. That is the default Smart Scan configuration after all anyway. Scans that included Archives have run continuously for up to 16.5 hours, maybe even longer at times I believe. That’s just infeasible. I noticed that the standard Smart Scan profile, by default, scans Runtime Packers, but based on the info you sent, I tried disabling that in today’s first scan as well. Then I wondered what difference it would have made if it had been enabled like in a normal Smart Scan, so I enabled it in the next scans to see how much time that added on etc. It nearly doubled the scan time! and increased the number of scanned objects by 1,279,000! so it would certainly be a bonus to exclude Runtime Packers as well as Archives. Please just confirm though that there’s no loss of system security if weekly malware scans don’t scan Runtime Packers, Gil? Answer: Unlike archives, runtime packers are used to compress executable and make them smaller. Such files are unpacked in memory upon execution. Therefore it is not wise to disable runtime packers although the files should be still scanned / unpacked by advanced heuristics. I don’t really understand the last part of that last sentence... “although the files should be still scanned etc…” Is this referring to the settings for Real-time File System Protection? Does it imply that if the RTFSP settings for Runtime Packers are set so that they’re scanned on Creation, Open and Execution with Advanced Heuristics, that will still provide good protection without them being included in weekly malware scans? Maybe the same would apply to Self-extracting Archives too. Relying on the RTFSP could mean much quicker weekly scans. So, in short, are you saying it would provide the optimum protection to scan absolutely everything in weekly scans, but RTFSP provides sufficient protection on its own? This thought led me to check ESET settings a bit further, in particular on the latest clean installation done on a new laptop. That showed there’s no configured weekly scan provided by default. (I remember now adding that myself ages ago, only because the previous internet security software brands I’d used did a weekly scan.) This suggests that the ESET program’s default and recommended setup doesn’t require a regular scan at all. It can protect the system adequately just with RTFSP and the other scheduled auto checks that come with a standard setup. That’s great! The Advanced ThreatSense config for RTFSP already includes Runtime Packers and Self-extracting Archives, and Advanced Heuristics. I could probably consider also enabling Runtime Packers and Advanced Heuristics in the RTFS ThreatSense config for even more ongoing protection, and maybe stop the weekly scans altogether. So, unless there’s info to the contrary somewhere, I’m inclined to think I should just rely on the standard out-of-the-box ESET setup, maybe with the tweaks mentioned above to strengthen the RTFSP settings even more (and monitor for performance impacts), and perhaps check out weekly scans again when the multi-threading of version 17.1 arrives. Surely ESET have provided an appropriately configured product setup out-of-the-box, so there shouldn’t be any problem with using it as it came, right? 7. To be able to properly experience the benefit of “Smart” scanning, the third scan used identical parameters to the second scan, and it was run straight after the second scan (with only an annoying but unavoidable auto Windows Update happening between the two). “Enable Smart Optimization” was definitely selected in both scan profiles. Answer: Complete disk scans will always take time and won't complete in a few minutes. If modules have been updated between two scans, the cache will be cleared. Otherwise it could happen that previously undetected malware for which a detection has been added in the last update would not be detected if the file was not re-scanned. With Smart optimization enabled many files will be skipped, especially those signed by Microsoft. The good news is that with v17.1 we will bring multi-thread scanning which should improve scan times on modern systems with multiple-core CPUs. It's great to hear about multi-thread scanning coming, because there really seems to be a problem with the performance and operation of Smart Scans now. There wasn’t a module update between the latest two scans, so the cache wouldn’t have been cleared. (There wasn’t even an internet connection at the time of the scans.) The second Smart Scan simply scanned 13027 fewer objects out of 2.15 million, so that’s not “many files” being skipped at all, and it saved just 0.75 hours scanning time. The scan still took 6.5 hours with Runtime Packers and Self-extracting Archives included, but excluding Archives. That’s not demonstrating much of a benefit of Smart Scanning at all... It firstly scanned 2.15 million objects, and then immediately re-scanned 2.14 million of those same clean objects. ☹ That’s the major issue I’m trying to draw to your attention about the operation of Smart Scans. Can you help us answer the above information. Cheers, Gil

Hi Marcos, I will share your response with our client. and i will let you know once they have response from us Cheers, Gil

Okay, i will communicate with ESET Australia. Thank you Marcos for being responsive with our concern. - we appreaciates your help so much Cheers, Gil

7.To be able to properly experience the benefit of “Smart” scanning, the third scan used identical parameters to the second scan, and it was run straight after the second scan (with only an annoying but unavoidable auto Windows Update happening between the two). “Enable Smart Optimization” was definitely selected in both scan profiles. Answer: Complete disk scans will always take time and won't complete in a few minutes. If modules have been updated between two scans, the cache will be cleared. Otherwise it could happen that previously undetected malware for which a detection has been added in the last update would not be detected if the file was not re-scanned. With Smart optimization enabled many files will be skipped, especially those signed by Microsoft. The good news is that with v17.1 we will bring multi-thread scanning which should improve scan times on modern systems with multiple-core CPUs. It's great to hear about multi-thread scanning coming, because there really seems to be a problem with the performance and operation of Smart Scans now. There wasn’t a module update between the latest two scans, so the cache wouldn’t have been cleared. (There wasn’t even an internet connection at the time of the scans.) The second Smart Scan simply scanned 13027 fewer objects out of 2.15 million, so that’s not “many files” being skipped at all, and it saved just 0.75 hours scanning time. The scan still took 6.5 hours with Runtime Packers and Self-extracting Archives included, but excluding Archives. That’s not demonstrating much of a benefit of Smart Scanning at all... It firstly scanned 2.15 million objects, and then immediately re-scanned 2.14 million of those same clean objects. ☹ That’s the major issue I’m trying to draw to your attention about the operation of Smart Scans. Hi ESET Team, Can you check this too

I found that my normal weekly scans had been scanning Archives, so I disabled that in all these latest scans as you suggested, and I guess that’s what made a big difference. I’ll make sure Archives remain disabled in future weekly scans, thanks. Answer: If the user has disk images and other big archives in a specific folder(s) on a disk, it'd be better just not to select this folder(s) in scan targets rather than disabling archive scanning completely. I have no idea where all the archives are. Based on scan numbers, there must be something like 3.5 million objects involved (!), which I just can’t fathom at all. Most must be system-related I guess. If I continue with weekly scans at all (see below), I think for the sake of practicality I’d have to stay with the option of excluding Archives from the scans. That is the default Smart Scan configuration after all anyway. Scans that included Archives have run continuously for up to 16.5 hours, maybe even longer at times I believe. That’s just infeasible. I noticed that the standard Smart Scan profile, by default, scans Runtime Packers, but based on the info you sent, I tried disabling that in today’s first scan as well. Then I wondered what difference it would have made if it had been enabled like in a normal Smart Scan, so I enabled it in the next scans to see how much time that added on etc. It nearly doubled the scan time! and increased the number of scanned objects by 1,279,000! so it would certainly be a bonus to exclude Runtime Packers as well as Archives. Please just confirm though that there’s no loss of system security if weekly malware scans don’t scan Runtime Packers, Gil? Answer: Unlike archives, runtime packers are used to compress executable and make them smaller. Such files are unpacked in memory upon execution. Therefore it is not wise to disable runtime packers although the files should be still scanned / unpacked by advanced heuristics. I don’t really understand the last part of that last sentence... “although the files should be still scanned etc…” Is this referring to the settings for Real-time File System Protection? Does it imply that if the RTFSP settings for Runtime Packers are set so that they’re scanned on Creation, Open and Execution with Advanced Heuristics, that will still provide good protection without them being included in weekly malware scans? Maybe the same would apply to Self-extracting Archives too. Relying on the RTFSP could mean much quicker weekly scans. So, in short, are you saying it would provide the optimum protection to scan absolutely everything in weekly scans, but RTFSP provides sufficient protection on its own? This thought led me to check ESET settings a bit further, in particular on the latest clean installation done on a new laptop. That showed there’s no configured weekly scan provided by default. (I remember now adding that myself ages ago, only because the previous internet security software brands I’d used did a weekly scan.) This suggests that the ESET program’s default and recommended setup doesn’t require a regular scan at all. It can protect the system adequately just with RTFSP and the other scheduled auto checks that come with a standard setup. That’s great! The Advanced ThreatSense config for RTFSP already includes Runtime Packers and Self-extracting Archives, and Advanced Heuristics. I could probably consider also enabling Runtime Packers and Advanced Heuristics in the RTFS ThreatSense config for even more ongoing protection, and maybe stop the weekly scans altogether. So, unless there’s info to the contrary somewhere, I’m inclined to think I should just rely on the standard out-of-the-box ESET setup, maybe with the tweaks mentioned above to strengthen the RTFSP settings even more (and monitor for performance impacts), and perhaps check out weekly scans again when the multi-threading of version 17.1 arrives. Surely ESET have provided an appropriately configured product setup out-of-the-box, so there shouldn’t be any problem with using it as it came, right? Hi ESET Team, Can you check the above response from our client, just focus on the marron words. Thank you!

Hi ESET Team, Can you review the attached logs, This is related with the ticket number : #CASE_00729049 1. Unable to install ESET Management Agent 2. Still, modules updates failed and could not connect to server Cheers, Gil ees_logs (1).zip

Hi Team, can you help us review the logs? I provided the HAR LOGs last week. Cheers, Gil

It is connected with the wifi, can you help me what will be the next steps or what should i recommended to our client . Cheers, Gil

Thank you, ESET Team, I will share the above information to our client. Cheers, Gil

Can you help me with the above information. Do i need to collect logs? Cheers, Gil

Hi ESET Team, Can you help me to response on this case :#CASE_00727712 # I’ve put in a fair bit of time working through the suggestions you sent for ESET configuration parameters, and I can see the potential for making a big difference, thanks. I did three back-to-back scans yesterday through to today. With the changed ThreatSense parameters, the first one only had to scan 874,000 objects, instead of over 5.69 million like my last weekly scan (!), and it took 3.75 hours. Testing a variety of options, the other two scans ran for up to nearly 7.5 hours. Still a good improvement from 16.5 hours, but I need to double check some things with you about the scan settings please, so I can make sure future weekly scans are as efficient as possible, without compromising system security. My questions are highlighted in blue, with proposed settings underlined … I found that my normal weekly scans had been scanning Archives, so I disabled that in all these latest scans as you suggested, and I guess that’s what made a big difference. I’ll make sure Archives remain disabled in future weekly scans, thanks. I noticed that the standard Smart Scan profile, by default, scans Runtime Packers, but based on the info you sent, I tried disabling that in today’s first scan as well. Then I wondered what difference it would have made if it had been enabled like in a normal Smart Scan, so I enabled it in the next scans to see how much time that added on etc. It nearly doubled the scan time! and increased the number of scanned objects by 1,279,000! so it would certainly be a bonus to exclude Runtime Packers as well as Archives. Please just confirm though that there’s no loss of system security if weekly malware scans don’t scan Runtime Packers, Gil? When Runtime Packers were included, the scan found a variant of “EFI/CompuTrace.A” in the UEFI Partition, which has been showing up in weekly scans for some time now, but from what I can find, that doesn’t seem to be an issue of concern. Is that correct? I tried turning off Advanced Heuristics in today’s first scan too, to test a minimalist strategy, but I guess if it’s enabled by default in a Smart Scan, I probably shouldn’t turn that off. So I enabled it again in the other scans. Should Advanced Heuristics be enabled in weekly malware scans, ? One other thing I thought may have been impacting the run-time of weekly scans was that the “Preserve Last Access Timestamp” setting was ON. It seems it’s OFF as the default in a Smart Scan profile, and I thought that might have a bearing on the process used by Smart Scan, so I’ve turned that off for all of these latest scans. Should Preserve Last Access Timestamp stay off? and would that have made any difference anyway? To be able to properly experience the benefit of “Smart” scanning, the third scan used identical parameters to the second scan, and it was run straight after the second scan (with only an annoying but unavoidable auto Windows Update happening between the two). “Enable Smart Optimization” was definitely selected in both scan profiles. The latter scan still took 6.5 hours, which was only 10% quicker than the previous one … so something still doesn’t feel right about “Smart” Scanning. Shouldn’t the Smart Scan have excluded almost all of the objects scanned just prior? The scans were run back-to-back, so surely the last scan should have been much, much quicker than the previous one as a Smart Scan because the digital signatures, time-stamps etc would have shown the files were clean and hadn’t been changed between the scans. Can you help me understand this please ? It seems to be a key potential performance issue.

Hi Marcos, ESET NOD32 Antivirus - See the attached file. You are correct It's weird because when i was trying to collect the logs using ESET Log Collector this error appeared. i followed your instructions. You can check it now Additional information: 1. We've tried to use Hotspot, but still have exist 2. 2 devices are now affected by the issue. If you need any furtuer logs just let me know ESET LOGS.zip

Hi Marcos, Yes, we are able to download the ESET Log Collector using a browser, i will inform our client about the above information. For ESET Endpoint Security with the case number : CASE_00729049 - can you also analyse the logs? I already sent the logs above. Cheers, Gil

Hi ESET Team, I've got the logs from ESET Endpoint Security with the case number : CASE_00729049 See the attached file for your reference Cheers, Gil ees_logs.zip

To clarify: For ESET Nod32 - this is a different client but the same error and issue. Do - do i need to post ? for this client? This is the case number : #00729727 For the ESET Endpoint security, - still waiting for the logs from our client : Ticket number: CASE_00729049 Cheers, Gil

Hi ESET Team, See the above information and logs from the client.

For the ESET Endpoint security - still waiting for the logs from our client, Cheers, Gil