NOD32 locks up- Design issues- Thoughts

There's a chance I'll be flamed, but I can't stop myself shouting NOD 2.7 has some design problems.

Minor or major depends on what side you're looking at the problem. If it is a minor glitch, easily fixable once Eset spots out the problem, or something bigger, something related to NOD's architecture.

If you recall I've allready spotted out in the past some conditions where NOD locks up the computer:

- Amon: Accessing sector/damaged CD
- Amon: Accessing some network files when in offline mode

Today I can definitelly add another case:
- Amon or Dmon: accessing Office documents

Symptoms are always the same:
- computer locked
- mouse hourglass
- keyboard only responds to ALT+TAB, showing the ALT+TAB dialog (but the task switch does not occurs)
- No task manager availability
- CPU usage is normal
- Pc needs hardware reset / power off

I'm not kidding, tricking; what I write here comes from more than 5 months of usage on 4 PCs each one whit it's own config, server and workstations.

The computer showing locks with Office documents has a brand new install, due to hard disk change: it has a freshly installed XP professional, freshly installed Office 2003, NOD 2.7 + Zone alarm 6.x. And after a few days it started locking up.

That is after the xth lock up I've decided to uninstall NOD and see what would happen. Since then, the computer did not lock anymore.

I definitelly think it is a design problem, even if I don't know exactly how NOD works. Nevertheless using the product and observing how it beheaves I've came to this conclusion: NOD modules manage a queue of files to be scanned and this could explain why NOD is so fast scanning; when possible, queue up accessed files and when possible do the scan. Till that moment, delay requests. If this is the approach, what happens if a file gets unaccessible? Probabily a computer lock; especially if NOD kernel is running in very low priority ring and has the capability to lock ALL the processes running.

If that is the case Eset should change the approach to something different; manage timeouts and do something, instead of locking up the PC.

I understand that it is difficult to spot out the problem, but Eset should start seriuosly to work on the problem.

I did allready go thorugh Eset's support but came out after one month of mailing with nothing and quite disappointed about it. Now for privacy reasons I'm not publishing mailing contents between me and Eset, but it ended all with nothing.

At this point I'm asking NOD users to post they're experiences and thoughts, wishing Eset will try to do something.

I currently own five NOD32 licenses till november 2007 and would like to renew if this tedious flaw will be complitely fixed.

I hereby ask the forum admin not to move this message in a previous thread, to be sure that it captures the attention of every user.

 

Does turning off DMON make a difference? In the past we have encountered a similar situation caused by a bug in MS Office, disabling DMON helped.

 

Hi Marcos, thanks for joining the discussion.

I think we should focus on the reasons why NOD sometimes locks the computer, and see if there's a chance to solve the problem.

If some users ore some configs need to disable some modules or except some file extensions to avoid locks up, we're leaving the problem somewhere.

There's no point in buying such a strong product and then little by little disable some features to get it work.

Eset should follow a path that wipes out the problem.

I understand that once the main architecture a software is done, it is difficult to change the nature of a product.

Nevertheless I'm asking my self if Eset is aware about the problem.
If someone in the dev. team is working on it.
If we, NOD users, have got a chance to get rid of those locks?

We could get into technical discussion that probabily would expose NOD's design & secrets to competitor's eyes. Strengths and weakness.

We don't want an unveiling, but answers to this problem.

 

Heres the problem though, i have yet to see any of the issues you referenced. The other thing is for nod to crash with things like office documents you would see many more reports. Could it be possible that its a program that is causing nod32 to crash?

 

Bluetarsky,

if you don't try the given suggestion, the ESET team will be unable to solve the possible issue with NOD. Please help them and try disabling DMON.

 

Interesting. Running XP Pro here. Office 2003 Pro. NOD32 2.7. DMON going full blast. No ZA. Have never seen issues with DMON/IMON/Office.

Have a couple of 20-25 pc networks nearby with XP Pro, various flavors of Office from 2K to 2003. NOD32 2.7. No ZA. No issues there either.

Hopefully your issue will be sorted out soon, but IMO, it's premature to say NOD32 has the "design problems".

 

Why I just don't disable DMON? Because as I've said the same problems is showing in multiple scenarios, and the result is the same: the lock described above.

Why those locks? Why NOD locks the computer? Why doesn't NOD states there's an error, an unreadable file, a timeout, an exception?

There are some conditions that unfortunatelly bring NOD into a blind alley.

Could it be Zonealarm 6.x??

 

Bluetarsky,

The developers know exactly how NOD works, so they will say if this is a design problem. You post your problem, the developer propose a solution, you try the solution. That's how it goes. You will not get anything from going around and asking why is something happening. Thousands of other NOD users don't have the same problem as you.

 

I have been using NOD32 for more than six months, but did not come to the kind of problems you meet with

 

Don't bet. I've been developing software since 1980 and I guarantee the more a program is sophisticated/complicated the more you're unsure how it works. C and C++ are bad beasts to tame, specially when dealing with low level programming/duty.

Unsure

That's how it went. The problems weren't solved.

Well maybe hundreds do. Don't they deserve attention or a solution?

 

Would be nice if each poster here could include its config...

 

Have you removed ZA from the equation to see if it might help?

 

Not yet. It looks like such a common companion...I could have a try........

 

Blutarsky - It appears that this problem has been seen before, and Marcos pointed you to a possible solution. You really need to try that first. As to the problem you're experiencing, we've been running NOD for a few years now (currently running 2.5.x and testing 2.7), on 3000+ machines in multiple locations - servers and clients, and have never had the issue you describe on Win9x/Win2K/Nt4/XP/Server 2003. Granted, we only run a single Office version, but somewhere in the resulting hodge-podge of software and hardware, we should have run into it...?

 

What's more, disabling DMON will not render your computer vulnerable as long as AMON keeps on running.

 

Sounds similiar to the problems I reported recently.

 

I would start there as well.... I've had my own share of problems with Zone Alarm and not with NOD32.

 

Hi peter.... what problems? BTW what firewall are you using?

 

You can click his forum name and select "Find all posts by xxx" to see what he's talking about. Briefly, he was experiencing a slowdown in the download of a particular file. Not a total lockup as you seem to describe.

 

Blutarsky - check my history for the two threads I posted. I don't use a Firewall except the WinXP SP2 one.

anotherjack - that was not a slowdown but a total lockup for half a minute. Just like Blutarsky described it.

 

Ok,
just to exclude the firewall question I had a go on my laptop that uses Comodo firewall and reproduced the second issue I've described at the beginning of this thread: Amon accessing an offline copy of a a file placed in a network share. I had to enable again Open/Execute options in Amon, navigate with Windows Explorer into the folder, right click on the offending file and....Lockup occured again.

No guys, it's not a Dmon specific, nor Zone Alarm....it is something related to NOD's design.... IMHO.

I hereby make a proposal: ask Eset a debug version of NOD. A version capable to log in a file what NOD is doing and where it gets trapped....I think it's the only way to get out from this situation.....could be a crypted log so no architectural hints are exploited....

 

Well, reading your posts, it sounded like yours locked up for 30 seconds or so, then eventually came back. Blutarsky mentioned that he had to actually power cycle his box to regain control. An odd problem.

 

'Morning, everyone.

I wish Eset representative would reply to the question above.....

 

Just updated NOD32 and when restarted my laptop, it locked up. Restarted several times, same result. Started in safe mode, removed NOD32, restarted again and laptop runs fine. I've got a Dell Inspiron 600M running Windows XP professional. The previous version of NOD32 ran fine. Any suggestions?

 

Maybe guys Eset should bring us on the road to the solution. I love NOD and would like to use it without limitatations.

At the moment to avoid locks I've changed the config on my lappy excluding AMON's Open/Execute.

On a workstation had to do the same and disable DMOn complitely