Hello All,

We had an incident yesterday where the scheduled virus scan (using the latest antivirus definition) removed a custom dll associated with an application. Apart from affecting a few hundred users[:@], who had to re-install their application, we also created an exemption in the antivirus real time scan to exempt the dll until the next definition was released.

I was wondering if there is a recommended way to prevent this happening with future packages (it wasn't one of ours, but it could have been). The dll in question is dwspy36.dll; which has had some issues with it's name before. Can we protect certain dll's etc from being replaced with spyware, or as in this case removed by a 'false' positive[8D].
Any thoughts, recommendations, greatly appreciated.

0 Comments   [ + ] Show Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


You can lock down files from the Virus scanner if you really want to but that might just create another bad situation if a bad dll gets placed on the machine in a secured location. I'd be more inclined to beat on the AV vendor for putting out a bad signature.
Answered 02/09/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
Thanks kkaminsk,

Yeh, we got onto them pretty smart, but the damage was already done. As mentioned the dwspy36.dll (and dwspy5.dll) has had issues associated with it ,since spyware became a major headache in enterprise networks.
Is there a case for us, as network support, to request the application vendor to look at repackaging/redesigning their application to not include 'sus' named files that give false positives like this? The said file was also installed in the system32 directory, I believe this should be changed.

I appreciate your feedback, thanks.

Answered 02/09/2006 by: WayneB
Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity