engine0.nup won't update...

Discussion in 'NOD32 version 2 Forum' started by nameless, Sep 26, 2007.

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

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    I'm using NOD32 2.7 on WinXP Pro SP2.

    I happened to notice that NOD32 was fervently downloading a 7,663-MB engine0.nup file over and over. What happens is that it selects a download server (since I have it set to choose update servers automatically), then begins downloading engine0.nup. When it gets to 76%, it stops, selects a new update server, and begins downloading engine0.nup all over again, from the beginning. Then, it gets back up to 76% completion, and... You guessed it, it selects yet another server, and begins again.

    It repeats that exact cycle over and over--begin downloading engine0.nup, get to 76%, select a new server, and begin all over.

    I watched it do this at least a dozen times before canceling it and trying again manually. (At which point, not surprisingly, it did the same thing.)

    The chances of me uninstalling, reinstalling, and reconfiguring NOD32 are 0. Any ideas to draw this goofiness to a sound conclusion?
     
  2. Blackspear

    Blackspear Global Moderator

    Joined:
    Dec 2, 2002
    Posts:
    15,115
    Location:
    Gold Coast, Queensland, Australia
    Hi there, this may be a Winsock corruption issue, however lets start with the following:

    1. Navigate to the C Drive on your computer.
    2. Double click on Program Files.
    3. Double click on ESET.
    4. Delete nod32.000
    5. Double click on the folder called “updfiles”
    6. Delete the contents of everything within “updfiles”.
    7. Reboot your computer.
    8. Connect to the Internet.
    9. Open up the NOD32 Control Center.
    10. Click on Update in the left panel (the bottom update).
    11. Click on Update Now.
    12. When NOD32 has updated reboot your computer.

    Cheers :D
     
  3. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    I followed your advice to the letter (except that I have NOD32 installed to "NOD32" rather than "Eset"). The problem went from bad to worse: Now, upon boot, I get the error "Error starting file system monitor".

    Since the engine did download successfully (or so it seemed), I thought it would be fine after a reboot, but it's not. I've rebooted twice now, and AMON really won't start.
     
  4. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    I no longer need help with this. No further replies necessary. Thanks.
     
  5. Blackspear

    Blackspear Global Moderator

    Joined:
    Dec 2, 2002
    Posts:
    15,115
    Location:
    Gold Coast, Queensland, Australia
    What was the solution?

    Cheers :D
     
  6. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    No idea. I removed NOD32. I was trying not to be rude, which is why I didn't say so in the post above.

    Yes, I know I have very little patience. I can't help it. AV software (including NOD32) has robbed me of more money, time, and hassle than any other software genre. I just don't have the time or patience to deal with this.
     
  7. Blackspear

    Blackspear Global Moderator

    Joined:
    Dec 2, 2002
    Posts:
    15,115
    Location:
    Gold Coast, Queensland, Australia
    No worries, usually what I have posted will resolve the matter, either that or repairing Winsock.

    Cheers :D
     
  8. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    It wasn't a Winsock issue, unfortunately. LSP-Fix showed that all was OK while NOD32 was installed and after. My connectivity was fine before and after. The steps you outlined seemed only to break my NOD32 installation.

    But it's OK. Probably. I'm going to restore from a backup made prior to when I removed NOD32. I tried running avast! for a couple days (the performance hit was unbearable). Tried using KIS (couldn't even install the PoS successfully). So it's back to the lesser evil, with gritted teeth.

    Thanks for the advice, though. I appreciate that someone tried to help.
     
  9. Blackspear

    Blackspear Global Moderator

    Joined:
    Dec 2, 2002
    Posts:
    15,115
    Location:
    Gold Coast, Queensland, Australia
    You are welcome.

    It would have been nice to resolve the issue though, as we have another person with the same/similar situation.

    Cheers :D
     
  10. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    Well it seems to have been rectified. Here is what I did, although I highly doubt that these points will help anyone else. I think the problem probably had to do with something weird going on with Eset's servers or something.

    The few things I am quite sure of is that it was never a Winsock issue, nor was it an issue with "my connection". There is simply no way that the download of a 7.7-MB file is going to coincidentally die at the 76% point, many times over. (Another user saw the same thing--the download failing at 76%. For another user, it happened at 69%). Every other file I download is fine. My connection is fine in all other respects. It wasn't Winsock, it wasn't my "Windows files", and it's not my connection.

    Anyway, to resolve the problem via serendipity, I:

    1. Went to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and noticed that the values for TEMP and TMP were of the REG_SZ type, rather than REG_EXPAND_SZ, as they should have been. I deleted these values and then recreated them as REG_EXPAND_SZ types, using the same value names and data (i.e. TEMP and TMP, with the data being %SystemRoot%\TEMP in each case).

    2. Went to HKEY_CURRENT_USER\Environment and verified that the TEMP and TMP values there were REG_EXPAND_SZ.

    3. Rebooted.

    4. Updated NOD32. It worked. Probably not because of my TEMP and TMP values, but I'm not psychic.

    I'm not sure how my TEMP and TMP values got screwed up, but I do know that they were not always REG_SZ. Some crap software must have changed the data type for some odd reason.

    Again, I am not implying that anyone else has the TEMP/TMP issue, or that this will help them with the NOD32 update issue. The only reason I thought it might be worth mentioning is that I was thinking maybe NOD32 couldn't find the TEMP directory when it needed to commit the file, so it aborted the download...
     
  11. Blackspear

    Blackspear Global Moderator

    Joined:
    Dec 2, 2002
    Posts:
    15,115
    Location:
    Gold Coast, Queensland, Australia
    Thanks for that, at least we have another avenue to try.

    Cheers :D
     
  12. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    I'm 99.9999999999999999999% sure this won't help anyone... Registry values don't just change types on a whim. So, sorry if this wastes anyone's time.
     
  13. sparx

    sparx Registered Member

    Joined:
    Jan 10, 2007
    Posts:
    60
    Environmental Variable issues have definitely appeared in relation to NOD32 problems. This will most definitely be of use to someone I'm sure.
     
  14. Johnoz

    Johnoz Registered Member

    Joined:
    Mar 4, 2007
    Posts:
    27
    Location:
    Sydney
    Hello Nameless and Blackspear,

    I am one of the people suffering from this issue. https://www.wilderssecurity.com/showthread.php?t=186939
    Although it is resolved for me by moving to the V3 beta, I checked my registry as described by Nameless.

    In my case in 1. above the values were as recreated by Nameless - that is REG_EXPAND_SZ and in 2. they were as verified per Nameless - REG_EXPAND_SZ

    cheers
     
    Last edited: Oct 3, 2007
  15. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    Well it's one more thing to cross off the list of possibilities for you, I guess.

    For anyone else, please note that it is not enough to verify that the directory exists (e.g. that C:\WINDOWS\Temp exists), and you cannot simply check the TEMP and TMP variables in the System properties applet. That applet is ignorant of data types. You need to use a registry editor and verify that the data type is REG_EXPAND_SZ for the TEMP and TMP values. (Technically, it would be fine for one or both values to be of the REG_SZ data type, if the corresponding data is set to something that is already expanded--such as C:\WINDOWS\Temp rather than %SystemRoot%\Temp.)
     
Thread Status:
Not open for further replies.