F*cking DLL! Avast false positive trashes Windows code libraries A misfiring signature update from anti-virus developer Avast triggered all sorts of problems on Wednesday. Avast acted promptly by withdrawing the definition update but not before numerous users had fallen foul of the problem. The withdrawn update incorrectly labelled various libraries (dlls) on Windows PCs as potentially …
" Even though testing procedures have been improved, mistakes still occur: mostly because the volume of signature definition updates has shot through the roof over the last decade in parallel with the boom in Windows malware."
Stop being an apologist for the A/V industry!
There is NO excuse for ANY signature update to flag STANDARD Operating System files, NO excuse at all. How many variations of Windows are there? Frankly, a handful, it can't take a significant amount of time for these people to TEST EVERY UPDATE on currently-supported O/Ses at the very least.
Sure, it's probably unreasonable for them to check their updates against every third-party driver but nearly all these kinds of reports are dealing with standard Windows DLLs etc..
Since the article describes the problem occurring whilst installing certain software, it would be reasonable to assume that the library DLLs in question are not core operating system files, but optional libraries (otherwise they would already be installed).
It's still not great that it flags these files, but there are a LOT of library DLLs out there provided by various entities, for example OpenXml DLLs for working with MS Office file formats, etc. etc.
It is entirely possible that if you were to try to install all potentially affected DLLs on one machine for testing purposes, you would get into a situation where there would be some serious compatibility issues, which would make this impractical if not impossible.
For instance, DLLs often have dependencies on other DLLs, and if one DLL requires one version of a dependency, and another requires a different version, it is not always possible to have both versions installed. Later versions of things are not always backwards compatible, for various reasons, from poor design, to needing exclusive access to some resource.
"DLLs often have dependencies on other DLLs, and if one DLL requires one version of a dependency, and another requires a different version, it is not always possible to have both versions installed. "
I thought DLL Hell had allegedly been sorted by assemblies and manifests and other SideBySide (SxS) related stuff, implemented in 98SE and Win2K and later?
Of course in the way of all things hip and trendy, SxS has itself gone to the software archive in the sky. Are we saying that its replacement brings DLL Hell back again?
"I thought DLL Hell had allegedly been sorted by assemblies and manifests and other SideBySide (SxS) related stuff, implemented in 98SE and Win2K and later?"
Well for one, .NET assemblies are DLLs.
The issue in question isn't confined to DLLs, however. They are just the container. It is in the nature of dependencies.
For instance, I have seen the same thing in Linux software where X depends on A and Y depends on A', but A and A' are incompatible versions of the same library.
Good software design mitigates the issue to some degree, where newer versions of a library should always add to the functionality of the older version, and maintain what was already there for backward compatibility. However, if a newer version of something implements its functionality in a wholly different way this is not always possible, and if the library is providing some core functionality, such as disk IO or graphics rendering, it is probably not at all wise to have more than one library attempting to do the same thing at the same time.
One of us is misunderstanding. May be me. Would welcome clarification.
Application A requires DLL P version 1
Application B requires DLL P version 2
Don't give a monkeys about .NET one way or the other, not immediately relevant.
"it is probably not at all wise to have more than one library attempting to do the same thing at the same time."
Absolutely correct. That'd lead to DLL Hell. Lots of folk have been there seen that.
That's why (aiui) SxS came into being - a workaround so that multiple independent applications can each have their own independent copies of (versions of) the DLLs they need, without treading on each others toes.
SxS is what allows/allowed this to happen, on the same system, at the same time?
Allegedly this describes how it works:
http://en.wikipedia.org/wiki/Side-by-side_assembly
nuked the windows system file that allowed network log on. That one borked about half the 1200 machines at the office where I worked. I think we spend about three days working out a solution then going around to all the PCs to manually fix all of them. I do remember skipping lunches by drinking Coke and three days later heading to the doctor for a kidney stone.
The spagetti code that is windows IS difficult to test against BUT these guys are responsible for updates that cause systems to go tits up....but not legally by their user agreements. They face no liability other than a hit to their reputation which they usually overcome. Somehow that doesn't seem fair does it?
The day a perfect AV is released - one that has 100% accuracy, 0% false-positives, is quiet, consumes next to no system resources and never affects compatibility, usability or productivity - the world will be a much better place for computer users.
But, until that day, AV will continue to be a trade-off. It's not perfect and, given the level it operates at, there will continue to be the possibility that a scan will affect the operation of some software or operating system function.
Given the prevalence of 'zero-day' exploits, AV updates (as well as software patches) will always be a matter of trying to get people protected as soon as possible while still testing compatibility as much as practical. This is the way of patches and updates - for security reasons, they should be released and applied as soon as possible, but for compatibility and stability they should be tested as thoroughly as possible.
As I said - it's a trade-off.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
