After seeing glowing recommendations for the heuristic-based ThreatFire anti-malware app from PC Tools, I decided to install it to complement my antivirus scanner and other anti-spyware tools such as Spybot-S&D and Ad-Aware.

Initially, it worked fine. While I don’t know how much protection it really added, it was intuitive, easy to configure and didn’t slow down my system like many other real-time scanners might have. However, I ran into some trouble with my web development environment, consisting of Apache, MySQL and PHP (in the form of XAMPP) that I could only attribute to ThreatFire’s presence.

The symptoms

With ThreatFire installed and enabled, requesting any pages from Apache that would result in MySQL access took painfully long. Accessing static pages or scripts that did not use the MySQL database did not hang. At first, I thought it was a problem with the application/scripts I was working on, but other popular third-party scripts, such as phpMyAdmin, were also slow or unresponsive. The server appeared to “hang” for about 10-15 seconds before producing any response. This was on a local server.

I tried several different courses of action, such as:

• Enabling logging of slow queries with the --log-slow-queries option.
• Adding the MySQL binaries (mysqld.exe and mysqld-nt.exe) to the ThreatFire exclusion/ignore list
• Reinstalling XAMPP

None of these worked. In particular, logging slow queries did not produce any logs, which seemed to indicate that MySQL was hanging even before the queries were executed. Surprisingly, logging the execution time of PHP scripts did not seem to indicate any problems either. The queries I was executing and that datasets I was working on were also small and unlikely to be a contributing factor – any query, no matter how simple, seemed to hang.

When I suspended or removed ThreatFire, the problems immediately went away. Strangely, as I noted above, adding the MySQL binaries to the exclusion list did not help. What was more interesting is that ThreatFire did not popup any warnings. Usually, when “suspicious behaviour” is detected, ThreatFire will prompt you for a decision. I did not notice any of this.

ThreatFire is not bad

The purpose of this is not to bash ThreatFire; it’s clearly a good tool and has definitive advantages, but just may not be well-suited to development environments where multiple servers are running. I also wanted to provide this information to anyone else who may have been struggling with a slow/unresponsive server because of the same situation as mine.