engine0.nup won't update...

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?

 

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

 

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.

 

I no longer need help with this. No further replies necessary. Thanks.

 

What was the solution?

Cheers

 

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.

 

No worries, usually what I have posted will resolve the matter, either that or repairing Winsock.

Cheers

 

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.

 

You are welcome.

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

Cheers

 

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

 

Thanks for that, at least we have another avenue to try.

Cheers

 

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.

 

Environmental Variable issues have definitely appeared in relation to NOD32 problems. This will most definitely be of use to someone I'm sure.

 

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

 

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