Update does not work in x64

Discussion in 'ESET Smart Security v4 Beta Forum' started by Mits, Nov 19, 2008.

Thread Status:
Not open for further replies.
  1. Mits

    Mits Registered Member

    Joined:
    Nov 19, 2008
    Posts:
    22
    I just made clean install of v4 (64-bit, on XP x64) and when trying to update, I get a different error message than the ones usually reported in this forum:

    Update information is not consistent.

    I did not touch the default demo login, I triple-checked it against updtv4/updt4test and I have no proxies and no firewalls active.

    However, I noticed that the update server is the same as in v3 (u24.eset.com, probably a registry leftover from my previous v3 installation?), while in some post in this forum I read that the betas use a different server. Could someone please report which server they use for their successful updates? (press F5 for advanced settings and see which server is listed).

    Is there a complete list of update errors so we can get an idea what might be happening? (I'm ashamed to admit it, but sometimes I miss good ole "Error #xxx occurred" messages, which you could look up in a table or search in Google).

    Thanks in advance!
     
  2. Mits

    Mits Registered Member

    Joined:
    Nov 19, 2008
    Posts:
    22
    Re: Symptoms Update

    A probable cause I was considering and was afraid to mention, actually happened - ESS's firewall asked me two-three times whether to allow ESS's own updater to contact a site (I always use interactive mode), the message changed to "Updates are not necessary - your definitions are current". However, after two more manual update attempts, the message reverted to "Update information not consistent".

    In order to bypass the problem of ESS blocking itself, I disabled its firewall.

    Then, I kept attempting manual updates (not hammering, just every 5 seconds) and it seems that every 2-5 attempts to manually update, the message alternates between the two errors mentioned above.

    For me, this behavior is consistent with the following theory: ESS tries to reach an overloaded server (u24.eset.com), occasionally manages to login and when it does, the server does not accept my credentials. By keeping on attempting to update, ESS alternates between these two states.

    Therefore, I have to beg users once again, to inform me which servers they are using...

    My next step is to install ESS 32-bit in a Virtual Machine and see whether it can make updates. Will report on the outcome.
     
  3. Mits

    Mits Registered Member

    Joined:
    Nov 19, 2008
    Posts:
    22
    Update problem resolved!

    ESS v4 32-bit report in a VM:

    ESS is able to update normally, even though no update server is listed on the advanced setup!

    In Documents and Settings\All Users\Application Data\ESET\ESET Smart Security\ of that installation, only one directory was made (http_u40.eset.com), while in my x64 installation there were about 15, which were recreated even after an updates Clear Cache. It seems that somehow ESS is able to find all the update servers from my previous NOD32 AV and ESS demo installations (which were many).

    Then I decided to examine the contents of update.ver in the VM. The first two lines read:

    Code:
    [HOSTS]
    BetaV4-other=20@http://u40.eset.com/download/engine4test/
    
    while my x64 version listed some 37 eset hosts, all of the /nod32_eval/ type.

    Needless to say, this was one of those magical AHA! moments :D

    Resolution:

    I deleted all other servers in the update setup of ESS x64, I inserted http://u40.eset.com/download/engine4test/ as update server, and magically, updates worked!

    Lessons taught:

    It seems that, at least in my case, it is very hard to remove all traces of past AV/ESS installations. Previous update server information, although absent from the registry, lurks somewhere on the HDD and interferes with the installation of version 4.

    Therefore, in a future v4 beta FAQ, it makes sense to add the following:
    Case closed. Time to proceed to real beta testing now :)
     
  4. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Re: Update problem resolved!

    We strongly recommend uninstalling the current version of ESS/EAV first. The beta uses its own update server as well as credentials for update
     
  5. Mits

    Mits Registered Member

    Joined:
    Nov 19, 2008
    Posts:
    22
    By "clean install" in my first post I meant that I had uninstalled version 3 before installing v4.

    Since you mention it, I wonder how much testing has been done on the v3 uninstall routine, and whether it actually uninstalls all traces of its existence (files, registry etc) on a x64 system. By the latter I mean that usually 90% of the time allocated by a software company to testing is devoted to the 32-bit version and that there might still be some glitches left on x64. In the weekend I will try to simulate my problems in a Virtual Machine and report back.
     
  6. Farmand

    Farmand Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    73
    Location:
    Denmark
    The update dont work for me eighter..??

    I have done a complete uninstall and cleaned the reg also..

    Tryed both the "beta user/pass" and also my own licenses user/pass.

    Nothing works..

    Does anyone have a solution for this problem..

    Thanks
     
  7. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    What error are you getting? Perhaps you could try setting the logging verbosity to diagnostic level, attempt to update and then report back the event log records related to the last update attempt.
     
  8. Farmand

    Farmand Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    73
    Location:
    Denmark
    can i use my own license or do i need to use that beta user/pass to update.?


    Just tryed it on a 32-bit system.. and there is no problem.. So the update problem might
    be a 64-bit issue..
     
  9. Farmand

    Farmand Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    73
    Location:
    Denmark
  10. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
  11. Farmand

    Farmand Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    73
    Location:
    Denmark
    Yes, twice..
     
  12. Mits

    Mits Registered Member

    Joined:
    Nov 19, 2008
    Posts:
    22
    I think there are additional issues with the x64 beta.

    I was gladly running the beta, until I had to reboot. For some reason i got a BSOD (not due to ESS, my system is just becoming too bloated) and I had to boot with the "last known good configuration" option. After that login, ekrn.exe was not running and the ESS GUI naturally would not start (could not connect to kernel etc).

    After that incident, I had to uninstall ESS, delete all ESET references in Program Files and Documents and Settings and try to reinstall. The msi installer was starting normally, seemed to extract and copy some of the files, but at the end it proceeded to a "rolling back" operation (very fast, took few tenths of a second) and apparently deleted some of the installed files. The ESS services were not installed. In the installation directory, there were only 15 .dat files and an empty "Drivers" directory.

    When attempting to uninstall and retry, ESS was absent from the list if installed programs in Control Panel. Repeating the process of deleting leftover files, cleaning up the registry and reinstalling v4 let to the same reproducible effects 4 times.

    At that stage I gave up. I installed v3 (which still does not update) and found somewhere some recent offline updates to be protected on the internet as I write.

    My proposal is that ESET should:

    a) offer an alternative .exe installation file in addition to .msi (to get independent from e.g MS installer and dot.net, which may be part of my problems)

    b) devote some time to develop a thorough cleanup utility - other AV vendors have one, (although sometimes well hidden) and it's not a shame to admit such a utility is needed. In the contrary, for me it is a sign of robustness: ESS operates at a 'deep' level, close to the kernel, and it is not easy to uninstall it, alter it, disable it or tamper with it.
     
Thread Status:
Not open for further replies.