NOD32 Service Doesn't Start on WinXP SP2

Aside: I know there are other similar threads to this, but they detail a different error to that I am experiencing.

I am attempting to get NOD32 to work on a new computer running winXP Pro SP2, only to find that the NOD32 kernel service fails to start. In all cases the WinXP Event Log shows this error:

Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7009
Date: <date>
Time: <time>
User: N/A
Computer: <computer name>
Description:
Timeout (30000 milliseconds) waiting for the NOD32 Kernel Service service to connect.​

I have tried with both the 2.12.2 and the 2.12.3 versions of NOD32, with the same result. After the user's desktop is displayed on boot-up, a couple of icons (for other programs) appear in the system tray after which there is a 30-second period of inactivity. After this, the boot-up sequence continues but some other apps that run at startup also fail as a consequence. If NOD32 is uninstalled, the Windows startup sequence completes without error 9and all startup apps load successfully).

My machine spec:

P4 3.0GHz HT
512Mb RAM
WinXP Pro SP2

 

Do you have or have you had any other Anti-Virus product installed on that machine?

Have you installed with Administrator privileges?

Have you tried uninstalling Nod32

Deleting the Eset folder from C Drive> Program Files

Reinstalling a FRESH copy of Nod32.

Cheers

 

No, no other A/V. The machine is new, with a freshly-installed copy of WinXP Pro SP2 (not a pre-installed copy, but a fresh copy installed by me onto a just-partitioned and formatted disk).

Yes, and running under an admin account.

Yes, I have tried that - many times (including a registry clean of all things Eset). I have also tried turning off HT and DEP, to no avail.

 

Hi spm:

What are the startup apps?

 

It makes absolutely no difference. Normally, they are:

SpySweeper, Popup Washer, TrojanHunter Guard and Outlook

However, even if I disable all of these the issue still occurs. Even uninstalling all of these makes no difference.

 

Can you please send an email to support@nod32.com and place a link to this thread. If you do not hear from Eset within 3 days (allows for weekends), please advise us here...

Let us know how you go…

Cheers

 

Yes, I am about to do this, especially as I have now managed to isolate the issue...

It is definitely a bug in NOD32, albeit a non-obvious one. The machine in question has a PATH environment variable which includes a path to a folder on a remote machine (using a UNC path). The remote machine acts as an internet gateway. The machine also uses a wireless connection.

What I find is this: the problem goes away if eother (a) I remove the remote path from the PATH variable, or (b) I use a wired connection to the network.

It would seem, therefore, that the PATH causes the NOD32 kernel service a problem during startup, while the wireless connection is still being established. When this causes the service to exceed its allotted startup time (30 seconds) Windows abandons the service startup. In fact, when the NOD32 service fails to start automatically, I can subsequently start it manually (i.e., after the wireless connection is established) in just a couple of seconds. This would tend to support my reasoning.

For now, I can workaround the problem (by avoiding the remote PATH element), but Eset needs to address it.

 

Hi SPM, what exactly do you mean by remote path? Do you have TEMP and TMP system variables set to point to directories on a remote disk?

 

A UNC path to a folder on another machine connected to the same subnet.

No. I never referred to the TEMP/TMP variables at all. I referred to the PATH variable.

 

Hi! I had my problem, with kernel service starting, noone could help, but I came up with my solution: try installing it in c:\nod32\ or \eset or something, but not in program files, and not in a directory that has a space in it's name. It worked for me.

 

Guess what? No response from Eset. What a surprise (again).

 

I have just sent an email, and would expect a reply tomorrow night or the following day...

I'll see what I can find out for you...

Cheers

 

Hi guys,
I tried creating both new system and user variables pointing to a network drive using the UNC path \\server\share and everything worked fine after a restart. Is there anyone else experiencing this problem?