Sign in / up

back to article 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 …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *
  1. Kraggy
    FAIL

    " 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..

    14 13 Reply
    1. Anonymous Coward
      Reply Icon
      Stop

      From the article, it seems nothing to do with core Windows DLL's

      17 0 Reply
    2. Loyal Commenter Silver badge
      Reply Icon

      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.

      9 0 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        When did DLL Hell come back then?

        "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?

        6 1 Reply
        1. Loyal Commenter Silver badge
          Reply Icon

          Re: When did DLL Hell come back then?

          "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.

          1 0 Reply
          1. Anonymous Coward
            Reply Icon
            Anonymous Coward

            Re: When did DLL Hell come back then?

            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

            0 0 Reply
      2. Werner McGoole
        Reply Icon

        Just thought I'd point out that to test AV software against a set of files (like dlls) you don't actually have to install those files. This sort of problem can be avoided by just plonking all the files somewhere in a big heap and scanning them.

        4 0 Reply
    3. Martin Summers Silver badge
      Reply Icon

      RTFA not just the headline!

      4 0 Reply
  2. Tom 13

    So bad, but not as bad as when McAfee

    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.

    0 2 Reply
    1. psychonaut
      Reply Icon

      Re: So bad, but not as bad as when McAfee

      I'd get a different doctor next time if he wanted to give you a kidney stone

      12 0 Reply
  3. Howard Hanek
    Childcatcher

    How do they test?

    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?

    3 2 Reply
    1. Irongut
      Reply Icon

      Re: How do they test?

      Read the article. No systems went tits up or became unbootable. Some people who had not bothered to update their free AV this year were unable to use TeamViewer or Corel. Hardly the end of the world is it?

      2 0 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: How do they test?

        It depends on whether you use Corel to manage Black Hole Production at the LHC via Teamviewer...

        1 0 Reply
  4. Crazy Operations Guy

    I can understand why Team Viewer got caught up in this

    I have seen far more malicious installs of TeamViewer than legitimate, so its not too surprising to see it become a false-positive.

    2 0 Reply
  5. x 7

    note it was out of date superceded versions of Avast which were affected

    4 0 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Shhhhh, don't ruin the angry peoples fun.

      3 0 Reply
    2. TheDillinquent
      Reply Icon

      The latest version isn't much better...

      I installed the latest version of Avast Pro and it stopped working completely, called Avast and they couldn't fix it using remote control, claiming that I had had an infection since 2012.

      0 0 Reply
  6. dan1980

    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.

    0 0 Reply

POST COMMENT House rules

Not a member of The Register? Create a new account here.

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like