Jump to content

coch

Members
  • Posts

    28
  • Joined

  • Last visited

Posts posted by coch

  1. I agree. Installing silently with configuration is really useful to me, and if I didn't have the .msi workaround ESET would be the only software out of my approximately 15-20 software of all types that I install silently via my batch file every time I reformat and reinstall Windows (and I'm not even counting drivers which I also install silently).

    For most software there is a way to achieve this, i.e. whether silent install or direct copy of the installed software under "Program Files", along with direct configuration as part of the silent install switches, copying AppData folder and/or merging registry settings.

    I was unable to figure out a way to achieve this for ESET via the registry or AppData routes (I suspect it's possible though and that I just didn't dig deep enough, but this seems more complex than I'm used to).

  2. Sorry, it is not 100% working unfortunately, despite my post just above.

    The settings from the cfg.xml file are not applied. Quotes or no quotes. Percent sign or no percent sign. ESET installs with the default settings regardless of having specified --msi-property ADMINCFG=

     

     

  3. Thanks Marcos, I confirm it works now, with a slight modification to your above instructions:

    -silent should be --silent

    (you had double dashes everywhere except for the first argument silent and I found it didn't work with a single dash, you really need two dashes everywhere)

    I also found that the % are not required in the path_to_the_cfg_xml

     

    Here's the command that I used, with correction made, and it was successful in a complete silent install of NOD32 using the .exe:

    eav_nt64.exe --silent --accepteula --language 1033 --msi-property-ehs PRODUCTTYPE=eav --msi-property ADMINCFG="D:\Reformat\Programs\NOD32-v11-Config.xml"

    Replace whatever's between the quotes after ADMINCFG= with the actual path to your own config file.

  4. On 1/10/2018 at 5:27 PM, Marcos said:

    Please let us know the actual path that you used as %path_to_the_cfg_xml%. Couldn't it be the issue with spaces in the path that was mentioned above?

    Unfortunately, no there were no spaces. My command line was:

    eav_nt64.exe --silent --accepteula --language 1034 --msi-property  ADMINCFG="%D:\Reformat\Programs\ESET-NOD32-v11-Config.xml%"

    Although I also tried:

    eav_nt64.exe --silent --accepteula --language 1034 --msi-property  ADMINCFG=%D:\Reformat\Programs\ESET-NOD32-v11-Config.xml%

    (without the quotes as I wasn't sure if these should be included or not, usually not required unless there are spaces in the path, although even without spaces having quotes isn't an issue normally)

     

    eav_nt64.exe --silent --accepteula --language 1034 --msi-property  ADMINCFG="D:\Reformat\Programs\ESET-NOD32-v11-Config.xml"

    (without the % symbols that were in your example; again, I wasn't sure if these were needed or not, I usually don't see % other than for environment variables to be expanded)

     

    eav_nt64.exe --silent --accepteula --language 1034 --msi-property  ADMINCFG="%D:\Reformat\Programs\cfg.xml%"

    (with a shorter file name, just in case there's some legacy 8 character limitation)

     

    eav_nt64.exe --silent --accepteula --language 1034 --msi-property ADMINCFG="%D:\Reformat\Programs\ESET-NOD32-v11-Config.xml%"

    (single space between property and ADMINCFG, in this this was a typo)

     

    eav_nt64.exe -silent -accepteula -language 1034 -msi-property  ADMINCFG="%:\Reformat\Programs\ESET-NOD32-v11-Config.xml%"

    (single dashes instead of double dashes, because, as NBPC mentioned, double dashes for command lines are unusual).

     

    I tried all those variants above and the outcome was either a complete failure to accept the command line arguments/switches (no install at all), or an incomplete install (just the EULA files...) as I mentioned in my previous message.

  5. Sorry it took me so long to test this, but

    --silent --accepteula --language 1034 --msi-property  ADMINCFG="%path_to_the_cfg_xml%"

    does not work for me when using the .exe installer.

    The NOD32 install does start (as confirmed by seeing the process in Task Manager) and is silent, but appears to end prematurely and silently (without error message) adter about 10 seconds), and NOD32 does not get installed.

    C:\Program Files\ESET\ESET Security only contains eula.rtf, eula.html and a "help" folder, but nothing else.

    So, back to the .msi method for me, as this one works.

     

    EDIT: and before someone asks, obviously yes I did replace the ""%path_to_the_cfg_xml%"" with my actual path

  6. Thanks @Marcos this is very helpful and thanks @NBPC for following-up.

    I will try those switches tonight and if it works as intended this resolves by issue on my end.

    (And just to clarify, my initial workaround was to modify the .msi file, but later on based on NBPC's findings a registry method could be used without having to touch the .msi file and this was my preferred approach.

     

    Looks like if everything works as described by Marcos I won't have to use the .msi anymore as the .exe installer will do everything I want (silent install and pre-configuration).

  7. Hi, as an update, I no longer believe this has to do with NOD32 per se.

    I think it is at most, a problematic interaction between NOD32 and Volume2, but it is also likely to be just Volume2 being the culprit.

    There seems to be a lot of noise around Volume2 and BSOD/stability issues, especially with Windows 10 1709 "FCU" according to these posts https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/systemserviceexception-win32kfullsys/a84467d3-b7a7-44c7-98ea-c6f14271f17c?auth=1

    (first mention of Volume2 issues on page 2, 13 November 2017, and it continues for the next several pages).

    My issue is not with Windows 10 1709, I am on Win10 1703, and I'm positive I do not have this issue with NOD32 v10, with the same hardware, same drivers versions, same Windows version and same Volume2 version, but there is enough noise around Volume2 issues for me to make it the prime suspect now.

     

    Thanks everyone for your feedback.

  8. 1 hour ago, itman said:

    FYI - there are numerous issues with Win 10 CFU. Since you disabled all of NOD32's components and the issue persists, I would say your issue is with Win 10 CFU.

    Unfortunately, this isn't the explanation for me.

    I have indeed experienced many issues with FCU (the worst being a ~ 1 minute lag opening any hyperlink) and I have returned to the previous Windows 10 build, waiting for FCU to mature before switching. I stopped using FCU about a week ago.

    Plus, both my Desktop PC and my laptop are using the same version of Windows, same version of NOD32 and same version of Volume2, and I got no problem at all on my laptop. Thanks for your help, this is a difficult one to figure out. I don't see anything related to the problem in NOD32's logs or in the Windows Event log.

    I'll investigate further, maybe process explorer or something similar would yield additional clues.

  9. Ok well nothing I tried helped. Even disabled all NOD32 components (Real-time protection, Web and email, HIPS, Anti-stealth, PUP, PUA, Suspicious apps, and AMSI) and the slow down/freeze still occurs.

    Disabling autostart for volume2 and launching it manually later doesn't fix it either, it is very slow and the whole PC unusable for 30 seconds until the app loads fully, even if I launch Volume2 like 10 or 20 minutes after logon.

    Interestingly if I exit Volume2 and launch it again, it loads instantly like it should, it's only the first launch after booting/login that is very slow.

  10. @Marcos: Thanks for the feedback, I'll run more tests tonight ('m at work now). I already tried "Pause Protection" but it didn't help, so I suspect it may be HIPS perhaps; didn't test disabling HIPS yet because this requires a reboot and I didnÈ'T want to reboot at the time . I enabled the HIPS log and didn't see anything unusual though. But I'll check disabling HIPS later.

    @itman: That's on my list. Will try tonight. It is currently auto-starting via the registry, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

    Putting it in HKEY_LOCAL_MACHINE instead doesn't change anything either.

    I'll try to start it as a service instead, and set it to "Delayed Start" as you suggested. Not sure it will help though, because even if I completely disable auto-start, and run it myself manually even 5 minutes after login, the issue is still there.

    It doesn't seem to be a driver, it is just a small executable with a few resources files. It does interact with the sound driver to some extent though, but as far as I can tell, it doesn't require it's own driver, as I can copy the folder where it is installed to a USB drive and the utility runs as expected this way on other computers (portable mode).

     

     

    Anyway, I will investigate further tonight.

    That

  11. Hi, I initially wrote about my issue in this thread here https://forum.eset.com/topic/13311-eset-1012311-and-new-v11-startup-behaviour/ but I now believe it's a different problem, specific to me, so here goes:

    My issue is that my computer becomes extremely show, mouse very choppy (cursor stalls for several seconds, then allows me to move for about a second, then stalls for several seconds again, etc...) and this continues for about 30 seconds until NOD32 loads. This behavior stops a few seconds into the NOD32 splash screen, at which point I get normal control back of my computer, which is a very fast AMD Threadripper CPU, M.2 PCIe drive, 32 GB RAM, etc...

    I found the issue to be caused by the Volume2 software utility that I use. I have it to start with Windows, and it appears to load concurrently with NOD32, and this is what makes my computer slow to a crawl for 30 seconds or so after login. Now:

    • It is not due to loading concurrently: If I disable Volume2 from loading at startup, NOD32 loads very quickly and no slow down is experienced. If I manually launch Volume2 afterward, the computer becomes very slow for some time, just like if volume2 was starting with Windows.
    • This did not occur with NOD32 v10, with the exact same version of Volume2, and no Volume2 configuration changes.
    • This also does not occur on my Laptop (Dell 7779 2-in-1) which also have both NOV32 v11.0.144 and Volume2 (same version, same configuration) also set to Autostart with Windows. This suggests a hardware and/or driver component too in addition to a weird interaction between NOD32 and Volume2.
    • Volume2 is not detected by NOD32, and a manual in depth scan finds nothing either.  I've been using volume2 for many years and have high confidence that it is not a malware or virus anyways.
    • No issues after Volume2 is loaded, it is just loading it which is a big problem. Before V11 (and as stated above, even with V11 on my laptop) it loads almost instantly, being a small utility.

     

    ESET, can you please download Volume2 and investigate, check why computer could become so slow when Volume2 is loading?

    I'm not posting the link as I think this may be frowned upon in case I am wrong and there is some malicious code in Volume2, but you can easily find it. Google 'Volume2 irzyxa' there are links to it on Wordpress and Deviantart which appear to be the developer's (irzyxa) main homepages. Volume2 is a small utility, not widely known, that I use as a volume OSD, and also allows me to set hotkeys to quickly switch between audio output devices.

     

    Thanks!

  12. 17 hours ago, peteyt said:

    Is this with version 11?

    Yes, this is with v11.

     

    And to add more info, which I find very peculiar, I just noticed that my laptop does not have this problem. ESET v11 loads almost instantly, feels very fast, and I see no mouse stuttering whatsoever during loading.

    I find it odd because my desktop PC is much more powerful (AMD Threadripper CPU, 32GB RAM), so, kind of surprising it would take it almost to a crawl.

  13. I'm also having startup issues. Startup of ESET is quite slow, and until it is loaded I can't effectively use my PC, as the mouse is stuttering/jerky. And jerky big time i.e. freezes for a second or two, then I can move it maybe half a second, then freeze for 1-2 second again and repeat over and over until ESET is loaded... the problem stops roughly 1 second after the splash screen comes up.

    Kind of weird that " Microsoft's conditions in terms of performance " would lead to degraded performance.

    And lastly, my issue is unlikely to be due to a "unhealthy system", as this happens with a stock Windows 10 Fall Creators Update install with just  ESET installed and nothing else. When I say stock install I mean no tampering or any tweak applied, and even before installing any driver (not that the issue goes away if I try the same thing _after_ installing my chipset drivers), so basically, this happens even when installing ESET right after the first boot after reformatting and reinstalling Windows.

  14. Well, it's not a very elaborate use case, I just like installers of software that I use to have silent install switches, that's all.

    This is what allows me to reformat, reinstall Windows, and run a batch file that I wrote which installs all drivers and software that I use silently and unattended. I like to reformat/reinstall Windows frequently (roughly every month or so), and this makes the difference between a 20 minute operation (silent, automated installs) and a few hours of manually installing and configuring all software.

  15. Thanks Marcos.

    I understand consumer products aren't offered as .msi installers. However, the .msi installers are available straight from ESET servers, so surely they are meant for someone (non-consumers?), and that someone will likely run into the same problem I did if they try to silently install.

     

    Personally, I don't need my installer to absolutely be a .msi, but I do need silent install and I didn't find a way to achieve that other than using the .msi installer.

    Is there a way to achieve silent install with the regular .exe installer, including picking up the configuration file so that NOD32 is configured as desired after install? (the old ADMINCFG=cfg.xml trick, which I confirm still works with v11 .msi installers by the way). If this is possible I

  16. Aha! found a fix to my own issue, or workaround... or a hack actually:

    I was able to fix by modifying the .msi installer with SuperOrca, as follows:
    - Open SuperOrca.
    - Search for ProductACode.
    - Open section Registry.
    - At the ProductACode line, replace #[PRODUCT_A_CODE] with [ProductACode]  --> this was only a guess from me, but I thought it was off that the string looked different from the one just above, so I made it look the same by typing [ProductACode] in there.
    - In the line just below (line should be called ProductBase), replace #[PRODUCT_BASE] with [ProductBase]. This is the second registry error that appeared when using /qb
    - Save the .msi.
    - Silent install now works without errors, and didn't see anything wrong so far with the functioning of NOD32.

     

    Still seems to me like the installer has bugs which should be fixed officially instead of using hacks like this.

  17. Command line (from an administrator CMD window):

    msiexec /i "eav_nt64.msi" /qn /log log.txt

    Fails to complete install (progress bar rolls back changes and installer exits).

    Following error found in log.txt:

    Error 1406. Could not write value ProductACode to key \Software\ESET\ESET Security\CurrentVersion\Info.  System error .  Verify that you have sufficient access to that key, or contact your support personnel.

    EDIT: Error still occurs after setting registry permission to Everyone = Full control for key "HKEY_LOCAL_MACHINE\SOFTWARE\ESET", and taking ownership of the key.

     

    EDIT 2: Clarified that I am running CMD with Administrator rights, of course.

     

    EDIT 3: Using /qb instead of /qn displays two errors (cannot write registry key) during install, which can be ignored and the install can complete. The registry key HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info does exist after installing this way. Looks like the installer throws an error about not being able to write to this registry key when in fact it can.

     

  18. The point is for it to be easy. Users that need to disable protection will disable it regardless, and it's just a PITA to have to jump through hoops to do so. I personally hate having to do two mouse clicks when one would be enough. In this case it's at least 5 or 6 mouse clicks more than it used to be.

  19. This is just out of curiosity and not a problem I'm having:

    I'm using NOD32 v10 on windows 10 x64, administrator account. I can't seem to figure out where is egui.exe loading from.

    egui.exe does auto-start with windows, however:

    - It is not showing in the "Startup" tab of the Task manager.

    - It is not in my start menu's "Startup" folder.

    - It's not under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

    - It's not under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

    - Could not find a scheduled task that would load egui.exe.

    - Could not find a service that would load egui.exe. There is a service for ekrn.exe though. Maybe that's it i.e. perhaps ekrn.exe automatically loads egui.exe?

     

    NOD32's egui.exe appears to work as intended and does auto-start as it should, but I'd like to know why as I can't find an 'auto-start' entry for it anywhere on my system.

    Just trying to learn something here... is there another location that I don't know about in Windows where a program can put its "auto-start" entry to make it load with Windows? (As it doesn't seem to be in the usual places people look for I'd even call it "hiding" its auto-start entry).

     

    Edit, also searched HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run] and it's not there either.

×
×
  • Create New...