[Vm-dev] [squeak-dev] PSA | Slow .changes access | Real-time protection in Windows Defender

Marcel Taeumel marcel.taeumel at hpi.de
Thu Dec 2 15:42:36 UTC 2021

Hi Eliot --

Since it is that easy for a user to add that exclusion ... yes, we might indeed check the performance of #forceChangesToDisk and give advice if it takes too long.

We had a similar discussion regarding #isLowerPerformance. A relative measurement would be nice. In this case, it would be like: "If writing to a new file takes this long, your #forceChangesToDisk should take that long."

Am 02.12.2021 16:19:41 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi Marcel,

On Dec 2, 2021, at 5:31 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:

Oh, this do-it seems to be enough to trigger the Windows Defender:

'</a>' size

Am 02.12.2021 14:08:31 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi all --

Provided that you have a .changes file that is bigger than a couple of bytes (here: ~200 MiB), you might experience a serious lag (here: ~5 seconds) when:

- Starting the .image
- Evaluating some do-its (or print-its)
- Saving a method

All operations that typically read from or write to the .changes file.

The Windows Defender's "real-time protection service" seems to monitor file access. Whatever triggers it, the defender might try to get exclusive read access to a file. Then it scans the last bytes and if it finds something strange, it will continue, eventually scanning THE ENTIRE FILE!

So, what is "something strange"? Well, try to evaluate this:

'<a href="https://www.microsoft.com"></a>' size.

Now, depending on the size of your .changes file, the Windows Defender will begin to scan the entire file for more such patterns. Note that the Defender will never complain or blacklist that file. It is just curious for the moment.

Why is the Defender able to get exclusive read access on a do-it? Take a look at SmalltalkImage >> #forceChangesToDisk. There, you can see that we close and re-open the .changes file. That's exactly the time when the Windows Defender kicks in. Avoid closing that file, and you will not experience any lag.

Try to save a method with such contents. You will be able to observe the same amount of extra lag.

Why is regular read access during code browsing not affected? Because we already have the open file handle to the .changes and .sources files. The Defender seems to need exclusive read access. In my experience, this happened, for example, during VM/image startup.

(Note that this has nothing to do with the Defender sending stuff to Microsoft via Internet. I did all the tests offline. No Ethernet connection. No WiFi.)


What can we do about it? Different approaches work:

- Save a method (or do-it sth.) to add about 1000 bytes of uninteresting content to the .changes file; then everything is fast again
- Shrink your .changes file via #condenseChanges (and don't forget to save your image afterwards!!) to speed up the Defender's scan
- Disable the "real-time protection service" in the Windows settings (not recommended)

Much better is to turn it off for a single file:

https://support.microsoft.com/en-us/windows/add-an-exclusion-to-windows-security-811816c0-4dfd-af4a-47e4-c301afe13b26 [https://support.microsoft.com/en-us/windows/add-an-exclusion-to-windows-security-811816c0-4dfd-af4a-47e4-c301afe13b26]

Go to Start > Settings > Update & Security > Windows Security > Virus & threat protection. Under Virus & threat protection settings, select Manage settings, and then under Exclusions, select Add or remove exclusions. Select Add an exclusion, and then select from files, folders, file types, or process.

(Me again) now what we really want is some check performed in Windows that checks Windows Defender’s settings, presumably the registry. eg if an operation on the changes file takes too long, or on startup, the image would check if it’s changes file is being monitored and would warn and/or prompt and/or offer to the user to set the exclusion.

- Avoid strange content in your source code (or do-its)
- Do not close the file so often. #primFlush: is not affected.


_,,,^..^,,,_ (phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20211202/aed321cf/attachment.html>

More information about the Vm-dev mailing list