PC freezed when I want use imgburn

When I want use imgburn, the pc freezed. I can use imgburn when I disable NOD32 Antivirus 3.0.672.0. Thats not realy funny. NOD 2.7.x runs with any problems... ;*(

Has anybody an idea?

I have a:
Pentium IV 3.2 GHz HT
Windows XP Home SP3 with all updates
I reinstalled Windows XP on Saturday.
NOD 32 3.0.672.0

 

I was actually going to start a thread about this issue a few days ago; ImgBurn stopped working for me as well. A few other programs also stopped working; when I tried to run them, my PC just froze (and I tried running the same s/w on two different PCs). One of those programs, jv16PowerTools, had been problematic in the past and, apparently, the same issue is reoccurring.

At first, I added the programs with issues to "Exclusions" and, although that resolved matters, I wasn't satisfied with the solution. So, in ThreatSense engine parameter setup, I turned off Advanced heuristics and that resolved the "freezing" problem (even after I removed the s/w from Exclusions).

I'd still like to know precisely what changed, though. It had to be some update because I wasn't experiencing these issues immediately after installing .672.

 

fwiw, I'm using ImgBurn 2.4.2.0 with NOD ver 3.0.669.0 on WinXP/SP2 and haven't had any problems. ImgBurn was installed after NOD, and I didn't have to do anything in NOD to enable ImgBurn at all.

 

If you're using the default settings, you will probably never have any problems (with ImgBurn or any other s/w).

It seems to me that these types of issues come into play when you're using one or more of the "higher" settings (e.g. AH, RTP enabled). Even then, the issues seem to appear *only* after certain updates in conjunction with certain builds.

Thus, you would need to install .672 and then enable AH in ThreatSense parameters to experience this particular issue.

 

I run NOD32 v3.0.672.0 using BlackSpear config and with AH enabled and I've no problem with ImgBurn. what used to slow ImgBurn startup down was Comodo for me. uninstalled comodo and everything's fine now.

 

Well, just for laughs I went ahead and re-enabled AH and was able to run ImgBurn without any anomalies. However, my PC still froze when I tried to run jv16PowerTools.

Anyway, I'm really tired of trying to figure this out; sometimes everything runs just fine while at others, depending upon the build and update, trying to run certain programs with AH enabled results in a freeze. I think I'll just leave the AH box unchecked in ThreatSense parameters for now.......maybe forever since I'm not even sure what the heck it does (considering AH is enabled by default for newly created and modified files).

 

It must be noted that AH is enabled only for newly created and modified files .

If you touch where you shouldn't , then it is not ESET fault . Even Blackspear have noted it:



I use pretty much the default configuration + detection for potentially unsafe appl. enabled + a few web sites excluded from check and have never had such problems. By default AH is enabled for newly-created files , it is enabled in on-demand scanner , it is enabled in the memory scan and enabled in web scanner - and this is safe enough .

 

No argument there.

But that begs the question: Is there even a scintilla of risk associated with AH being enabled only for newly created and modified files? If not, then why bother including the AH setting in ThreatSense parameters? I'm just curious, basically, primarily due to a lack of understanding of some of the more advanced settings.

 

If you use the default settings (with AH being enabled only for newly created and modified files)

If you come accross a malware that is detected thanks to AH but in a moment NOD32 doesn't detect the sample at all , you'll get infected . Then at a later moment NOD32 can detect this sample but it still needs the AH . Because of the fact the file will be present in the disk but the AH will be disabled for on-access , NOD32 real-time protection will still fail to detect that file . However , at a later time , thanks to the memory scanner or in an on-demand scan , the threat will be picked up.


If you do NOT use the default settings (with AH being enabled for all kind of files)

The difference , If you come access a malware ... Because of the fact the file will be present on the disk and the AH will be enabled for ALL kind of files , detection will appear ASAP . You will not have to wait for a while until memory scan is performed or until you perform on-demand scan.

The detection difference is too small to worry about but emulating each and every PE file will cost your processor a lot .

 

Wow! No more problems with ImgBurn. It seems Eset had fixed the problem.

 

I reckon the problem occurred with runtime packers enabled on access (not set by default). This was one of the files that were compressed with high compression ratio and thus it took several seconds to unpack it. We've whitelisted 2 such files that some of you have complained above.

If someone is experiencing a problem with high cpu usage when scanning avi/log files, please let me know. We'll be glad if you could assist us in pinpointing the issue.

 

The "freeze" problem occured with Guild Wars Visions, too.
I have send it to analyse with an comment.

Link to download: http://gw.onlinewelten.com/articles,id71,0,guildwars_visions.html