AV Module 'Malfunctioning' when ALG Service is delayed loading (?)

[freesurfer]

Good day,

I'm using ESS v3.0.563.0. The ff screenshots show what always occurs during bootup.

195598
195599
195600

What I have noticed is that there are certain windows services that are delayed in loading. I've checked with Process Explorer and there weren't any other programs that is using enough CPU and I/O to produce the effect (the I/O is more telling, but I double-check w/ the HDD LED of my casing and it isn't blinking like hell; actually, it's hardly blinking at all :))

The windows services in question are: IMAPI, svchost (Process Explorer showed no commandline), ALG, and wuauclt (its not a service, but it's still delayed). But what I'm betting on is the ALG (Application Layer Gateway).

As for the cause for the delayed loading of services, I'm not sure, but it's most likely the VMWare (VMWare Workstation v6) I have installed. Actually, it's not just the windows services that are delayed, but also any programs manually executed (this includes the LAN icons near the system clock, w/c doesn't appear until the delayed services have started to execute).

So, the question now is, is the AV module actually affected by this delayed loading? Or is it just that the communication between the AV module and the GUI is disrupted, making the AV module still functional? Sadly, I'm guessing that the AV module is really affected since the rest of the modules, personal firewall and antispam module, are not affected. If that is the case, I hope a fix can be made soon as this can be exploited and be used as an attack vector.

I hope I can hear from an ESET staff soon.

Regards.

[krokodil_bb]

malfunctioning = non working or disabled. green nod icon in this situations is bug, eset know about it. If eset kernel not responding to gui, status icon is default green - users are happy8) . screenshots are from 566.

195607
195608

[freesurfer]

I forgot to mention that once the rest of the services (IMAPI, ALG, etc.) started loading (or atleast when they start to appear in Process Explorer), the AV Module would return to normal.

Regards.

[freesurfer]

Ok, I got around to doing some very basic testing and what I found out that what causes the major delay is VMWare, more specifically one of its service:
service: vmware-authd.exe
name: VMware Authorization Service
description: Authorization and authentication service for starting and accessing virtual machines

When I disabled it from automatically loading during startup, the rest of the services that was delayed, now loaded immediately, and consequently allowing the AV module of ESS to avoid the "malfunction" status.

Ofcourse, the vmware service itself didn't cause the "malfunction" but rather made the "malfunction" more evident. Why? Although the loading is now proceeding normally, I was still able to view ESS module status during startup/log-in and saw that while alg.exe hasn't yet loaded/is still loading, the AV module was shown to be "malfunctioning". Only when alg.exe was started did the AV module returned to normal status. It is quite possible that this is common to all setup/users, only it is hardly evident considering that by the time the ESS/EAV GUI loads, alg.exe has also already started.

Although one could question whether it is alg.exe is the "culprit" or not (I think that it is considering its purpose), I think the more important question is is the "malfunction" status just a communication error between the GUI and service/kernel module or is the protection "compromised" due to the Windows' network component in certain conditions?

I hope that an ESET staff or someone in contact w/ ESET provide some input on this matter. I'll probably also post this issue to the ESET NOD32 Antivirus Forum.

Regards.