Quickbooks dbdata11.dll and Vipre/MAV

Friday morning (6-26-2015) I started receiving calls from several of my customers saying that they could not run Quickbooks, and that they were getting an alert that the file “dbdata11.dll” has been quarantined.

image

With the help of other members of The ASCII Group, we quickly determined that it was a false positive due to a bad definition file update from Vipre (or the RMM version called MAV).

Soon after, MAXFocus (previously GFI) sent out a service status alert of the issue, and that it had been resolved with definition version 41468 and above. It was recommended to add the file (dbdata11.dll) to the Vipre/MAV exception list, before updating systems with the newer definition file.

Note: make an exception only for the file, and not the folder and file, as the folder name is randomly generated by QuickBooks.

That should have been it. Right? … Wrong!

I received a call from one of my users saying that one of their systems with QuickBooks installed on it had locked up. At about the same time they reported this issue, I received an email alert from the RMM service I use saying that the C: drive of this system had dropped to below 20% free space.

Once we got the system rebooted, I logged in and discovered that there 44,175 folder taking up nearly 62GB of disk space. The location of these folders were in C:\Users\QBDataServiceUser22\appdata\local\temp. Each of these folders contained a single file: dbdata11.dll.

It turns out that every time Vipre/MAV quarantined this file, QuickBooks created a new temp folder with the same file!

So once I had the A/V definition file updated, and we rebooted the system, I went in and safely deleted all 44,175 folders! 

What a fun way to spend a Friday!

Comments

  1. Interesting to note that the folder name is not randomly generated. It all depends on the version of Quickbooks. The only part of the folder name that changes is the last number – this is sequentially increased with each copy made.

    If you’ve come here after Vipre has updated their definitions to resolve this issue and it’s still happening to you, take a look at your software restriction policies on your network/machine, if any. We were blocking DLL files from being executed from within the %Temp% dir, so adding an explicit path rule for the DLL file here resolved the issue. This is the path we used for the SRP:

    %Temp%\{16AA8FB8-4A98-4757-B7A5-0FF22C0A6E33}_1101_1\dbdata11.dll
    Set to ‘unrestricted’

Leave a Reply