Disabling IMON

As many others have experienced, my xp os takes a considerably longer amount of time to shut down ever since nod32 has been installed. Like many others, I have obviously tried uninstalling (which removes the problem) and reinstalling (which subsequently brings the problem back). Leads me to believe that it is definitely nod32 doin it. I have read that IMON is the problem and when disabled, this IMON process problem is no longer an issue. I was looking to try this.

However, my question: when I go to the resident module IMON and select "QUIT" (rather than the check mark icon to disable), i get a notice saying that IMON will be removed from the registry and will not come up on my next restart. Obviously those are my intentions anyways, but does this also mean that i will never again be able to load IMON without reinstalling the entire nod32 application? I currently do not run any pop3 accounts or other on-computer email clients (such as outlook, etc), so I do not necesarily require the IMON anyways. However, I would like to know if I would still have the chance to re-enable IMON sometime in the future if I should happen to get a pop3 account up and running.

Any help/other hints for the long shut down problem would be much appreciated!

 

No, you will NOT need to reinstall NOD32 if in the future you want to use IMON. You can just click "start" on the IMON panel. The only time you would have to reinstall NOD32 in order to use IMON when you have not been using it would be if you do an advanced install and do not even install IMON at all. What you are doing here is just disabling IMON and removing registry entries but you are NOT removing IMON from your NOD32 installation. It takes only a press of the "start" button to start using it again. I have done this several times because I used the new HTTP scanner that is in the beta I have and so I know that you will not need to reinstall NOD32 to use IMON again.

 

Great to hear, thanks for helping me out!

One quick question:

UPDATE - Function: gethostbyname, parameters: ,return value: 11001
UPDATE - Update attempt failed (server connection failure.)

^ I keep getting the above messages under my events log. They have been comming on there ever since I had NOD on here. Ive got the purchased edition and commercial version and everything and im possitive the passwords are in correctly. Funny thing is...whenever there is an update available, it updates fine. I get no notices of wrong password but I was just wondering if you have heard of anything like this? I removed my passwords and sure enough it asked for ones before I could update. I stick em back in and boom its good to go again (so i know it aint the passwords). It seems to only happen on XP (I also have nod installed on a windows 98 computer and the updates are listed only as they occur and never with a bunch of double notices about failed attempts, etc).

Can you shed any light? I was thinking it was there to let you know when it was checking for updates even if none were available, but considering I did not see the same thing for windows 98 kinda got me thinkin somethin wasnt right.

 

Do you have it set to auto update or do you have it set to "offer" before updating? I saw the update attempt failed errors on W98SE and on XP. (The other error I haven't seen but I have been getting, only on the XP box and only recently a slightly different error about parameters and an error code). I also get lots of "error connecting to server" and then each server is listed with the error.

I changed the W98SE box from "offer" before updating (both definitions and program updates) to "offer" only before program updates (thus making definitions updates automatic on that box).
After I made that change, the errors disappeared from the W98SE box. I still have the XP box set to "offer" before any updates of any type and I get those errors frequently. This is a subject that has been discussed here considerably and we don't have any clear answers yet as to why these errors occur. Lots of speculation.

 

If you use a dial-up connection be sure you have the appropriate connection type set in advanced update setup.

Though it's not a brilliant solution, you can shorten the time necessary to shut down Windows by decreasing the value of the WaitToKillApplication keys in the registry (20000 ms by default). Usually, there are more instances of that key so you may need to change each of them.