CFP3 and VMware cause slower shut down on Vista 32bit (CFP 3.x) [RESOLVED]

I have noticed that with CFP3 installed VMware takes considerably longer to shut down. The machine operates smoothly, but a shutdown that should take seconds now takes minutes. It’s impossible to hasten the process by killing the process because it doesn’t respond to termination. All VMware processes have maximum allowance in firewall and D+ rules. Uninstalling CFP3 solves the issue.

OS: Vista Business 32bit, latest VMware

Really? Ive got VMware Workstation installed, and my VM’s, Fedora 8, Win Server 03 and BackTrack 2 haven’t had any slowdowns.

I don’t see why it would ether. Do you mean your running Comodo in the virtual machine or the host OS?

on the OS, outside VM

I i’ve detected the same issue on my machine.
After installing COMODO FIREWALL, my virtual machines take about 5-10 minutes to shutdown.
I’ve uninstall the firewall and problem is solved.

i did not noticed any slowdown (in fact i’m even surprised by the reboot time - less than half-minute!) on my VMWare workstation though i have CFP 3.0.14.276 and NOD32 v3 outside VM and CFP 3.0.14.276 and CMF 2.0 beta inside my XP Home SP2 VM…

maybe it’s something to do with Vista compatibility… 'cos i’m running XP Home SP2 host OS

Woooo I’m not alone.

The process that isn’t shutting down, not even via task manager, is vmware-vmx.exe. Maybe Comodo will look into it.

well i got these unkillable vmware-vmx a couple of times but i didn’t even think of blaming Comodo since the problems started only when i tried to redirect my Alcohol Virtual CD-ROM to VMWare instead of mounting ISO image directly into VMWare…

I do have Alcohol installed but the VM is linked to my real DVD writer.

i got both Alcohol and real DVDROM connected to my VM.

I’ve got 2 machines one with windows XP SP2 and the other with Vista Ultimate.

  • Both have same version and build of Comodo Firewall Pro: 3.0.14.276;
  • Both have the same version of VMWare Workstation 6.0.0;
  • None has Alcohol;

And both have the same issue: the client OS take about 5-10 minutes to shutdown and on both I’ve already removed Comodo Firewall and the issue is gone.
So the only reason is Comodo.

I still use it, it’s a fantastic firewall, despite some small and minor issues.

still strange… i still don’t have any problems, but maybe it is not because of the firewall itself but because something is interfering with it - maybe low level drivers or VM network driver (i use bridged networking and everything runs fine). The only “unusual” thing about my VM - this machine is not “native” VMWare, it wasn’t built from the ground up but was imported from Parallels Workstation via VMWare Converter. And also i excluded all VM files from NOD32 scanning and added XP machine folder to my own safe files (i got CFP installed both on host and guest OS).

Could be. I tried uninstalling my AV and it didn’t help. Remade the network rules for vmware-vmx, but it STILL freezes for 5 mins before shutting down. Haven’t tried disabling D+ to see if it goes away then.

this could be caused by D+ since it is hashing every new executable it meets… hashing the whole virtual drive would be rather long process… except VM virtual disk ain’t no executable and therefore shouldn’t be scanned… maybe you should check your settings? i mean the D+ VMWare ones and Image Execution Control.

That AND the fact that I tried creating 20MB DOS VM which shouldn’t take long to hash so that’s not it. I tried setting D+ settings to a minimum and allowed vmware-vmx permissions for everything aswell as disabling image execution. To no avail. CFP3 is somehow conflicting with VMware and it has to be tested and fixed by the crew.

well it’s up to the developers now, i’ve been no help :-))

VMware 6.0.0 will always shut down after only about 5 minutes of being stopped. Until then it stays open, and killing its process from task manager will have no effect. This has happened to me on both Business and Ultimate 32bit Vista editions, and ONLY when CFP is installed.

However, I have today installed version 6.0.2 and the problem completly went away. Whatever the bug and whoever’s fault it is, VMware 6.0.2 fixes it. I am hereby, at looooong last, declaring this issue resolved.