Dr. Web v.4.33 problems

For what it is worth, If I adjust Spider Guard to "scan running programs and modules" when I apply this change, indeed, the CPU goes up to 100 percent and contiues to fluxuate wildly. I haven't checked into it much at this point but it seems if I uncheck and apply the option to scan running programs and modules cpu usage goes to normal. Further, if I make other changes to the guard setings other then the aforementioned one I see no cpu issues other than a momentary spike as the program stops and unloads/loads or whatever it does so the changes can take effect.
I can't help but wonder if this cpu problem, as it relates to changing the guard settings, is not due to the way Spider Guard is handling the unloading/loading so the new settings can take effect. Of course DR Web users know that before 4.33 any changes to the Guard settings required a reboot.

 

Yet an other thing that I forgot to show. Because M$ is doing their best to make my programs unusable, I have to set my Windows DEP to like this. You can see what I mean from here, because my WinXP Home system is Finnish, look at what Blackcat wrote in post 22.

https://www.wilderssecurity.com/showthread.php?t=90542

PS. The "guard" is from Ewido and "Automaattiset päivitykset" is "Windows auto updates".

Best regards,
Firefighter!

 

Today I received two answer fro Dr. Web support!

no.1 regarding CPU spikes:

>When the tray menu is selected or when I make changes to SpiderGuard and select the OK button, CPU usage spikes to 100% and so everything freezes.

These are two different issues.

1) When you click on the SpIDer Guard icon it starts to search for language files (dwl files) in order to build "Language" menu. To do that SpIDer opens every file in its working directory and checks its format.

2) When you click OK or Apply buttons, SpIDer reloads drweb32.dll and *.vdb files, then starts to scan files of loaded images (processes and DLLs).

Both issues seem to be fixed by now (still testing).

--
Serge Popov <sjp@drweb.com>
Doctor Web, Ltd.

No.2 regarding my problems with deleting large files:


>When deleting large files (25 Mb) to the recycle bin, it takes very long to complete deletion. Also copying these large files from one folder to another, takes very long.
>Somehow these files are being scanned by Spiderguard and this process takes a very long time and this was not with version 4.32.

Deleting to Recycle Bin is actually a move/rename operation. Obviously, SpIDer Guard would hook these operations and scan files being moved to Recycle Bin. This is by design. You may exclude Recycle Bin from scanning by adding its physical path to SpIDer's "excluded path".

If I recall right, you've described ypur case in more detail in Wilders Security Forums. Your 25M .exe file is actually a NSIS istallation container. In version 4.33 we started to unpack/scan these containers, and this leads to significant slowdown it your case.

I believe what in the upcoming service release of Dr.Web 4.33 most of performance problems will be resolved.

--
Serge Popov <sjp@drweb.com>
DrWeb Team

I believe we can probably understand better what's happening now and I'll be waiting for the fix!
For the moment I'll add the reclycle bins to the exclude paths for now.

Tip from Firefighter: .............
I have added some limits to the drweb32.ini file, to [SpIDerGuardNT] section I added "MaxFileSizeToExtract = 25000
MaxFileSizeToScan = 40000".

I have done this and for now it narrows down the problem with these large files.

Hope other posters have received an answer as well.......and I'll be looking forward to reading that.

Good luck...... Putin

 

This is good news. Thanks for posting, putin

Not yet by email

But I have received an answer to my problems by Serge Popov over on the Dr Web forums.

So they must have been very busy with the testing of the new service release coming up.

 

These limits work very well for me now indeed......GREAT TIP!!!!! I'll leave it this way for the time being and wait for the fix.
Thanks Firefighter!

Putin

 

Thanks Putin
I will wait for the Service Release.
Cheers

 

This is very good news indeed...

 

Just upgraded from 4.33.0.10030 to 4.33.0.10090 and it even slowed my computer more down...........with just simpel surfing.
I have really had it just now! I'm in for a licence renewal, but won't go for it after frigging around for so many days already.

I made a switch today and stick to that for a while!

Hope they sort it out soon, but I'll pass for the time being.

Putin

 

Strange, I understood that DrWeb was upgrading automaticly! When I looked at my own version, it was only 4.33.0.09273. After that I clicked the brand new DrWeb installer downloaded from the web, there was said that it was updating the DrWeb version to 4.33.0.10090. But after rebooting it was still the 4.33.0.09273.

Best regards,
Firefighter!

 

You are completely right.....nothing changed! I didn't look till now, but I did notice another slowdown.
Strange thing.....but enough for me.

Putin

 

Just before I uninstalled the whole DrWeb thing, deleted all DrWeb folders left, cleaned the registry with EasyCleaner 2.0.6.380 and rebooted always when needed. Then installed the DrWeb again with the installer v.4.33.0.10090, but after all these, DrWeb scanner showed again that the same old version with me.

Best regards,
Firefighter!

 

Strange thing........and gives a lot of static. If they don't fix these things soon, they'll lose a lot of users.

Putin

 

Oh boy.... I don't like the sounds of this ..... coming from the two users who know more about Dr. web than I do.... this is so not good.
Where did you guys get 4.33.0.10xx ?
I still have the following:
Engine 4.33.0.09273
Scanner 4.33.0.09262

Hi Putin
Did you get back to them and let them know about the continuing problems with the new version?
Just asking
Cheers

 

When you download the install from Dr. Web and start installing it over the running Dr.Web, it states it will upgrade to 4.33.0.10090. But when checking the version like you do.......nothing is upgraded according to the versions showing, it still shows what you have now.

I am going to wait for a service release and see what happened. For the time being I'm using a different AV. I won't contact support just now, as they seem to read these postings as well.

Putin

 

I'm gonna believe that this 4.33.0.10090 is somehow a code to the latest update of that engine, not the upgrade, which was before 4.30.a/b/c etc. There just can't be a new version of the engine each day.
I don't even know what's the latest code of DrWeb's engine just now, when I'm not working at my own laptop with DrWeb on.

Best regards,
Firefighter!

 

You're probably right, we'll just wait and see........

Putin

 

Putin, why don't you simply revert back to version 4.32 until the service release?

 

But it will automatically upgrade to 4.33, won't it?

Putin

 

Some good news from the DrWEB folks. Mike Kolyadko replied to my email and acknowledged the Processguard issue. They are working to resolve it now. Just maybe it'll be part of the upcoming service release...

 

Hope it's no taking too long.....

But at least, there's a reply from support.

Putin

 

My laptop didn't last weekend it just reflected the new updates to the bases.
Of course then I uninstalled and downloaded 4.33. Anyway, my best guess is that I don't think it will at this point. There was talk of "forcing" the upgrade soon after the 4.33 release but I have a feeling that has been delayed because of the problems some users have reported.

 

Ok, didn't realise this.....I might go back to 4.32.

Thanks for te tip.

Putin

 

It's a pitty that you just can't use the new 4.33 version, because even today I picked up a quite new nasty, that were not detected by 4.32b version but was easily detected by the new 4.33 heuristics. Look at scanning results in VirusTotal (DrWeb version 4.32b) and Jotti's on line scan (DrWeb 4.33).

Best regards,
Firefighter!

 

Doing a good job......great. I can use 4.33 allright, but I have to disable archive scanning and add limits to the dr.web ini file in order to make use of a fast and light dr. web. And therefore I don't see why I should this as my main av scanner. I have 4.32b running now on my wife's computer and my son is still using 4.33 and I'll be waiting for the fixes. In the mean time, I am using another good AV for the moment.

Thanks for the update!!

Putin

 

There is no need to disable archive scanning in DrWeb's On-Demand scanning. Just exclude those files that are too heavy to the new engine just now. I have only 2 such kind of files in my laptop, the first is a 100+ Megs "cap" archive and the second is a HP PSC 1215 driver installer container about 162 Megs.

The SpIDer Guard does not need Archive scanning, Only scan "smart" and scan files "by format" is enough to prevent infections.

Best regards,
Firefighter!