Microsoft Security Essentials

[ChrisJakarta]

Since upgrading to the latest version of Microsoft Security Essentials (MSE) v2.1.1116.0, I have found that at least one of my compiled scripts runs very slow. I cannot be sure that MSE is the cause (it might perhaps be one of the recent Windows updates, although it is the same on my XP desktop and my Win7-32 notebook), but adding the .exe file to the Excluded files list in MSE solves the problem.

Has anybody else experienced this? Is there a way to exclude all AutoIt compiled programs, for example by listing a .dll?

Chris

[MvGulik]

Since upgrading to the latest version of Microsoft Security Essentials (MSE) v2.1.1116.0, I have found that at least one of my compiled scripts runs very slow. I cannot be sure that MSE is the cause (it might perhaps be one of the recent Windows updates, although it is the same on my XP desktop and my Win7-32 notebook), but adding the .exe file to the Excluded files list in MSE solves the problem.

It would be more interesting/helpfull to know what part in that script is responsible for the slowdown.

Has anybody else experienced this? Is there a way to exclude all AutoIt compiled programs, for example by listing a .dll?

This makes no sense at all. Excluding all autoit build files just because just one is giving you a problem. But no, there is no direct(easy) way to see if a exe is a autoit build executable.

[ChrisJakarta]

Thanks for the swift response.

It would be more interesting/helpfull to know what part in that script is responsible for the slowdown.

Yes, I guess I should try to find the time to investigate further, although at this stage I'm not sure how I'd start. One of the problems with investigating further (and perhaps the reason for the additional question) was that there is no slow-down in the response when running the un-compiled script. I'm not sure what that suggests. But I was rather hoping to find out if anyone else had experienced problems before digging deeper.

This makes no sense at all. Excluding all autoit build files just because just one is giving you a problem. But no, there is no direct(easy) way to see if a exe is a autoit build executable.

Thanks. That's rather what I expected. But I guess I don't quite see what the problem would be excluding all autoit build executables from a virus scan, since I can be confident that they are not infected.

Chris

[MvGulik]

that there is no slow-down in the response when running the un-compiled script.

That sound like some account login situation/problem. Having something similar laying around (wip) ... but it could of course also be something else.

since I can be confident that they are not infected.

If there your own builds, I would doubt that to.

I would block the dev folders from AV scanning (assuming already done), and keeping a list of the filenames of your autoit tools that u use across your system to be imported into the AV exclution list.

(and ... reporting them as false positives to the AV creators.)

Edited July 20, 2011 by iEvKI3gv9Wrkd41u

[BrewManNH]

Thanks. That's rather what I expected. But I guess I don't quite see what the problem would be excluding all autoit build executables from a virus scan, since I can be confident that they are not infected.

Chris

The problem with excluding all AutoIt executables is that some malware out in the wild has been written in AutoIt and by excluding them from your AV scanner, you're opening your computer to this malware.