coch

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

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=

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.

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.

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

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

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.

@NBPC, thanks a lot, much better than my approach of hacking the .msi installer file using Orca, and I confirm this also works perfectly for me (it also seems to resolve a few minor issues I was having).

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.

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.

@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

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!

I have additional info which may help troubleshooting my issue, I'll post as a new thread as I now have enough info to strongly suspect my issue is specific to me (or at least to my use of the Volume2 software utility) and thus, likely different from the OP's issue (unless also using Volume2). I don't want to hijack this thread .

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.

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.