[Windows][34.0.1] Periodic local file traversal triggers ~56k Microsoft Defender real-time scans in ~2 minutes

[kjfalf]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I have searched for it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

On Nextcloud Desktop Client 34.0.1 on Windows, the client periodically appears to traverse a large part of the local sync tree. These file accesses trigger tens of thousands of Microsoft Defender real-time scans in a very short period.

The user-visible symptom is a sudden increase in fan speed for approximately one minute, accompanied by significant CPU and disk activity from Microsoft Defender's Antimalware Service Executable. This happens intermittently, typically around every two hours, while the machine is otherwise idle or under comparable low-load conditions.

No application is manually started when this occurs.

A Microsoft Defender Performance Analyzer recording was captured during one occurrence. The recording shows that almost all Defender real-time scan activity during the capture was initiated by nextcloud.exe.

AI disclosure: This issue report was drafted with the assistance of OpenAI ChatGPT. The interpretation and analysis of the Microsoft Defender Performance Analyzer results below were also generated with AI based on the machine-generated logs supplied by the reporter. The underlying measurements were produced by Microsoft Defender/Windows and were not generated or modified by AI. Conclusions derived from those measurements should therefore be treated as potentially flawed

Defender Performance Analyzer results

Recording interval:

• Start: 2026-08-11 19:32:45
• End: 2026-08-11 19:34:27
• Recording duration: approximately 102 seconds

Overview:

Metric	Result
Real-time scans	56,742
Cumulative real-time scan duration	469,290.679 ms
Maximum individual scan duration	1,687.214 ms
Median scan duration	7.749 ms
Skipped scans	227

Top process:

Process	Scan count	Cumulative scan duration	Average	Maximum
C:\Program Files\Nextcloud\nextcloud.exe	56,202	466,877.604 ms	8.307 ms	1,687.214 ms
C:\Windows\System32\mmc.exe	309	2,077.167 ms	6.722 ms	15.652 ms

Thus, during this recording, approximately 99% of all Defender real-time scan events were associated with nextcloud.exe.

The scan entries are consistently reported as:

ScanType: RealTimeScan
Reason:   OnOpen
Process:  nextcloud.exe
Path:     D:\Nextcloud\...

The accesses are not limited to a particular file or file type. They span large numbers of files throughout the local Nextcloud tree.

Examples of extension counts during this single recording:

Extension	Scan count
.JPG	23,524
.m4a	10,542
.jpg	8,619
.PNG	2,907
.mp3	2,270
.png	1,983
.mp4	1,111
.itc2	1,219
.heic	705
.HEIC	574
.MOV	554

There are also accesses to executables, PDFs and other file types.

This suggests that the Defender load is a secondary effect: nextcloud.exe opens a very large number of local files, and Defender subsequently scans those files through its normal real-time OnOpen protection.

No regular Defender quick/full scan was logged at the time of the captured occurrence. A separate Defender quick scan had taken place several hours earlier. Therefore, the observed event does not appear to be a scheduled Defender scan.

Possibly related issue

This looks potentially related to:

#10491

That issue describes a regression in Desktop Client 34.0.0 where discovery repeatedly re-reads local directories even when they are unchanged. It was closed with milestone 34.0.1.

The current report is specifically for 34.0.1, where a large number of local file opens can still be objectively observed through Microsoft Defender's performance tracing.

I cannot yet confirm that this is the exact same code path as #10491. No controlled downgrade comparison has yet been performed for this machine.

Expected behavior

see below

Actual behavior

Periodically, nextcloud.exe opens a very large number of files throughout the local synchronization tree.

Microsoft Defender consequently performs tens of thousands of OnOpen real-time scans. During the captured occurrence:

• 56,742 Defender real-time scans occurred in approximately 102 seconds.
• 56,202 of those were attributed to nextcloud.exe.
• The accesses covered photos, music, videos, application files and other unrelated parts of the synchronization tree.
• Microsoft Defender temporarily showed substantial CPU and disk activity.
• The laptop fan increased to an unusually high speed for approximately one minute.

The event then subsides and the system returns to normal until the next occurrence.

Steps to reproduce

1. Run Nextcloud Desktop Client 34.0.1 on Windows with a local synchronized directory containing a large mixed file collection.
2. Leave Nextcloud running normally.
3. Do not manually start a sync or open large parts of the synchronized directory.
4. Wait for the periodic background activity to occur. On this system it happens intermittently, typically approximately every two hours.
5. Observe that Microsoft Defender's Antimalware Service Executable suddenly consumes significant CPU and disk resources and the laptop fan ramps up.
6. Capture the event using Microsoft Defender Performance Analyzer:

New-MpPerformanceRecording -RecordTo "$env:USERPROFILE\Desktop\Defender.etl"

7. Stop the recording after the activity subsides and analyze it using:

Get-MpPerformanceReport `
    -Path "$env:USERPROFILE\Desktop\Defender.etl" `
    -TopProcesses 20 `
    -TopFiles 30 `
    -TopExtensions 20 `
    -TopScans 100 `
    -Overview

8. The resulting report shows tens of thousands of RealTimeScan / OnOpen events caused by nextcloud.exe across the local synchronization tree.

Expected behavior

When the synchronized data and server state are largely unchanged, the desktop client should not repeatedly open tens of thousands of local files during a short background cycle.

An idle or unchanged synchronization tree should not cause enough local file activity to trigger approximately 56,000 Microsoft Defender real-time scans within about two minutes.

The client should return to and remain in an idle state without periodically causing substantial CPU, disk and thermal load.

Which files are affected by this bug

The behavior is not isolated to a specific file. Files throughout the local sync root are accessed The Defender recording shows tens of thousands of accesses covering JPG/JPEG, PNG, HEIC, M4A, MP3, MP4, MOV and other formats. The full Defender report contains personal filenames and paths and is therefore not attached publicly in unredacted form. A sanitized report or additional measurements can be provided if useful.

Operating system

Windows

Which version of the operating system you are running.

Windows 11

Installation method

Official Windows MSI

Nextcloud Server version

32.0.12.1 according to status.php

Nextcloud Desktop Client version

34.0.1

Did this occur after an update or on a clean installation?

Major version update (i.e. 4.0.0 → 33.0.0)

Are you using the Nextcloud Server Encryption module?

Yes

Are you using an external user-backend?

• Default internal user-backend
• LDAP or Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No corresponding server-side error has yet been identified.

The observed workload is local: Microsoft Defender tracing shows `nextcloud.exe` opening large numbers of files under the local synchronization root.

Nextcloud Desktop debug logs covering the same occurrence have not yet been correlated with the Defender trace.

Additional info

During a normal occurrence, Windows Task Manager showed Antimalware Service Executable at approximately 23% CPU usage and approximately 53.5 MB/s disk activity.

The Defender Operational event log did not contain a corresponding normal Defender scan-start event at the time of the occurrence. A separate quick scan had completed several hours earlier.

The Defender Performance Analyzer report also contained one performance hint that a particular executable in the synchronization tree was not trusted. This does not appear sufficient to explain the overall event because the captured activity consists of more than 56,000 scans across many unrelated media and data files.

Based on the trace, my current hypothesis is:

1. Nextcloud performs a broad local discovery/file traversal.
2. nextcloud.exe opens tens of thousands of files.
3. Microsoft Defender reacts normally to those opens with RealTimeScan / OnOpen.
4. Defender therefore becomes the visible CPU/disk consumer even though the initiating process is Nextcloud.

This hypothesis and the analysis above were generated with AI from the captured Defender data and are not intended as a definitive identification of the faulty Nextcloud code path.

[tomse]

I have the scan folder traversal issue as well... it happens every now and then that a client is released with this problem.
devs: add 100.000's of files to a HDD (non flash) and test sync against this before releasing - you'll know the constant crunching of the HDD head.

otherwise happy NC user since early days of owncloud - keep up the great work

[ralftar]

Same behaviour here on 34.0.1 / Windows 11. Timing measurements posted in #10491 (comment) — full local discovery is ~32× slower than on 33.0.7 over an identical 4,436-directory tree, reproducible across 11 consecutive runs with a 0.7% spread, and produces zero file transfers.

The remote query reports ParentNotChanged for every directory while the local query still runs NormalQuery, so the traversal happens even when the server reports the tree unchanged. That looks like the same root cause as the one #10491 was closed for.

[johnwaynesn]

Seems like i have the same issue on my side. I think it first occoured after the client upgrade to 34.0.0. But on my side it holds my 3TB HDD in my PC on 100% busy for a long time (30-60min). I think it happens when i add, modify or delete a file locally in a folder, synced by the nextcloud client. But not always - it just finished scanning and i created a new file but no imidiate rescan. So maybe a background task, which can be triggered by file actions?

I have a huge repository with around 1.35TB and 125k files of any different types synced with my nextcloud. I am now on 34.0.1 with my windows client and the issue happend a few times in the last days, seems like everytime i modify files in a synced folder. tbh i dont think its on a schedule, cause i am working on that same pc the whole day and if that would happen randomly i would notice since the HDD is pretty noicy in action. During the Defender scan nothing is actually synced and the nextcloud client hangs every now and then. After Defender has finished, everything is fine again.

My nextcloud server is aswell running on 34.0.1. I am using this setup for a few years now and i never experienced something like that before client version 34.0.0. My server backend got updated a few days before but the issue first occured on the very first start of nextcloud client 34.0.0.

[ralftar]

Root cause

Root cause for the traversal described here. Timing measurements are in #10491.

The cost is a per-file CreateFile issued during local directory enumeration.

To be clear about scope: this is not an antivirus problem. The client issues one file open per file per
discovery pass regardless of what else is installed. Real-time scanning and a mechanical disk change how
expensive each of those opens is; they do not cause them. On a machine with neither, the same tree still
incurs tens of thousands of unnecessary opens on every pass — the wall-clock cost is simply lower. The
scan count in the title of this issue is a symptom of the traversal, not its cause.

https://github.com/nextcloud/desktop/blob/v34.0.1/src/libsync/discoveryphase.cpp#L408-L413

// Access lock state on the worker thread so a blocking open cannot freeze the GUI #10464
if (!i.isSymLink && !i.isVirtualFile && !i.isDirectory) {
    const auto absoluteLocalPath = localPath + QLatin1Char('/') + i.name;
    i.isLocked = FileSystem::isFileLocked(absoluteLocalPath, FileSystem::LockMode::SharedRead);
    qCDebug(lcDiscovery) << "File" << absoluteLocalPath << "isLocked" << i.isLocked;
}

This sits inside the entry loop of DiscoverySingleLocalDirectoryJob::run(), so it runs once per regular file on every local discovery pass. On Windows FileSystem::isFileLocked opens the file itself:

https://github.com/nextcloud/desktop/blob/v34.0.1/src/common/filesystembase.cpp#L732

Enumerating a directory is no longer a metadata operation — it opens and closes every file in it.

How it got here

• 33.0.7 — no lock check in discovery
• 34.0.0 — isFileLocked() called inline in handleExcluded(), on the GUI thread, and for directories as well
• 34.0.1 — moved to the worker thread, skips directories, symlinks and virtual files

34.0.1 fixed the GUI freeze and the directory case. It did not reduce how often the call is made for regular files, which is why the wall-clock regression survives at 32×.

Against my tree the arithmetic lines up: 2,455 s across roughly 44,000 files is ~55 ms per file open, which is what a physical open costs on a spinning disk with real-time scanning in the path.

Why most of these calls appear unnecessary

The only consumer of the flag is handleExcluded():

https://github.com/nextcloud/desktop/blob/v34.0.1/src/libsync/discovery.cpp#L357

For an entry whose local metadata already matches the database record, the instruction resolves to no action whether or not the file is locked, so the lock state appears to have no bearing on the result. Those files are opened anyway. In a tree that is almost entirely unchanged between passes, that is nearly every file.

I have not traced every path through handleExcluded(), so please treat that as an observation rather than a conclusion.

Possible directions

• Evaluate the lock state lazily, at the point of use, keeping it on the worker thread so 34.0.0 hangs on Windows #10464 does not return
• Skip the check during enumeration when the local entry already matches the database record
• Defer it to propagation, where a locked file is what actually produces an error, matching the original intent of the 34.0.0 change

I am happy to prepare a patch, but I have no Qt build environment on this machine and could not verify the improvement myself.

Related

• Desktop client 34.0.0: ~500× sync-cycle regression vs 33.0.7 — discovery re-reads every local directory each cycle; client never reaches idle; spurious "Unable to connect" banners #10491 — the 34.0.0 regression this originates from, closed as completed against milestone 34.0.1. Timing measurements for 34.0.1 are in Desktop client 34.0.0: ~500× sync-cycle regression vs 33.0.7 — discovery re-reads every local directory each cycle; client never reaches idle; spurious "Unable to connect" banners #10491 (comment)
• 34.0.0 hangs on Windows #10464 — the GUI freeze that motivated moving the lock check to the worker thread in 34.0.1, referenced in the code comment quoted above
• fix(upload): skip locked files during upload to avoid errors #9810 — where the lock check was introduced, with the stated intent of skipping locked files during upload. That intent is what the third suggestion above would restore. The commits that placed it in the discovery path:
  • 0cf36eb fix(lockedFiles): try to silently ignore locked files
  • ce593d5 fix(lockedFiles): ensure locked files seen during discovery are known
  • e55cb6b chore: only ignore locked files when uploading them
• https://help.nextcloud.com/t/client-start-always-triggers-antivirus-microsoft-defender-which-makes-100-usage-of-hdd-every-startup/247887 — independent report of the same traversal on 34.0.0 / Windows, worked around with a process exclusion

[ralftar]

Forgive me for reaching out without triage — @mgallien, would you mind a quick look?

A suggestion, in case it saves time. The flag is only consulted when the entry is otherwise a sync candidate, so an entry whose local metadata already matches its journal record has nothing to upload and its lock state cannot change the outcome. Skipping those in the listing keeps the check on the worker thread, so #10464 stays fixed, and removes nearly all of the opens.

The obstacle is ordering: listFilesInPath() is read in ProcessDirectoryJob::process(), which asserts both queries are already done, so the records are not available when startAsyncLocalQuery() launches the listing. Hoisting that read into start() and handing the records to the job would close the gap:

// discoveryphase.h
explicit DiscoverySingleLocalDirectoryJob(const AccountPtr &account,
                                          const QString &localPath,
                                          OCC::Vfs *vfs,
                                          bool fileSystemReliablePermissions,
                                          QHash<QString, SyncJournalFileRecord> knownRecords,
                                          QObject *parent = nullptr);

// discoveryphase.cpp, replacing the current block in the entry loop
if (!i.isSymLink && !i.isVirtualFile && !i.isDirectory) {
    const auto known = _knownRecords.constFind(i.name);
    const auto unchanged = known != _knownRecords.constEnd()
        && known->_modtime == i.modtime
        && known->_fileSize == i.size
        && known->_inode == i.inode;

    if (!unchanged) {
        const auto absoluteLocalPath = localPath + QLatin1Char('/') + i.name;
        i.isLocked = FileSystem::isFileLocked(absoluteLocalPath, FileSystem::LockMode::SharedRead);
    }
}

process() would then reuse the records it was handed instead of querying again.

One design note before any of this is worth doing: ce593d54a reads like discovery-time detection was deliberate, so a locked file stays known and gets picked up once the lock is released. If that is right, moving the check to propagation would lose it, and this narrowing would be the gentler option — unless I have missed something.

[johnwaynesn]

Updated to 34.0.2 and removed the workaround (Defender Exclusion on nextcloud.exe) and restarted nextcloud. The issue reoccurred immediately. A lot of MsMpEng.exe on all my files synced by nextcloud. This time my hdd drive is only on 40% utilization (last time it was stuck on 100% till done). So it should take a lot longer now but i will not wait for it (its going for 10min now) while nextcloud Activities shows "Checking folder changes". So i added the Defender Exclusion again and it stopped immediately.

[joseph-valenti]

Independent corroboration of @ralftar's analysis above, from two machines tested on 34.0.3 today.
I'm the reporter of #10491 (the ~500× sync-cycle regression), which was closed "completed" on
2026-08-06 — before 34.0.2 or 34.0.3 shipped. Both are still affected.

I measured true sync duty cycle: the union of all Sync started → Sync finished intervals from
the client's own log, divided by wall clock.

	33.0.7	34.0.3
Machine A — sync duty	2%	85%
Machine A — largest folder (400,800 files, USB 7200 rpm HDD)	28 s median / 167 s max (136 runs)	1,536 s, then 1,658 s
Machine B — sync duty	12%	36%
Machine B — same tree, local NVMe SSD	19 s	283 s

Both rolled back to 33.0.7 the same day; Machine A returned to 1% duty and reaches idle again.

This supports the isFileLocked()-opens-every-file mechanism specifically, because the damage
tracks storage latency rather than data size. Identical file set, identical server, identical
account config — 55× degradation on the mechanical USB disk versus 15× on NVMe. If discovery were
merely re-reading metadata the two would scale together; they don't. A per-file open() at ~55 ms
versus well under a millisecond is exactly the observed ratio, and it is the same work that is
generating your ~56k Defender scans.

Two traps worth recording, because I fell into both today:

1. Process CPU is not a usable signal. The client sat at ~1% of total CPU (about 5% of one core)
   while its sync duty cycle was 85% — the work is I/O-bound. Any "is the client busy?" check based
   on CPU or Task Manager looks completely healthy while the machine is crippled.
2. isFileLocked / WindowsError: 57 count is now 0 on 34.0.3. 34.0.2's "properly test for
   locked files" removed the failing call's log spam, not the per-file open. Verifying a fix by
   grepping for that error yields a false pass — I recorded one before measuring duty cycle.

Full method, per-folder tables and the rollback verification are in
#10491 (comment)

I have complete client debug logs for both machines across 33.0.7 → 34.0.3 → 33.0.7 and can supply
sanitised extracts or re-run any specific measurement.

[ralftar]

@camilasan — sorry for the nudge before triage, but I don't think the scope shows
from the individual reports: this has been in the Windows client since 34.0.0 in
late July, it's still in 34.0.3, and it has no owner.

Since #9810 landed in 34.0.0, FileSystem::isFileLocked() runs once per regular
file on every local discovery pass:
https://github.com/nextcloud/desktop/blob/master/src/libsync/discoveryphase.cpp#L408-L413
On Windows that's CreateFileW + LockFile + UnlockFile + CloseHandle per
file — a real byte-range lock on every file in the tree, every pass.

The same call has produced four issues, and each fix removed a symptom while the
per-file work stayed:

• [Bug]: [v34 RC5] Client crashes during discovery with WindowsError 57 (ERROR_INVALID_PARAMETER) in OCC::FileSystem::isFileLocked #10444 crash and log flooding → chore(common): print filename if error occurs in file locking check. #10470, fix(filesystem): do not attempt to lock directories on Windows #10487 — 34.0.1
• 34.0.0 hangs on Windows #10464 GUI hang → fix(discovery): move file lock state off the GUI thread. #10500 (moved to the worker thread) — 34.0.1
• Bug: Desktop client 34.0.1 falsely flags new files as "locked", blocking sync for entire containing folder #10569 files falsely flagged locked → fix(windows): properly test for locked files #10584 — 34.0.2
• Desktop client 34.0.0: ~500× sync-cycle regression vs 33.0.7 — discovery re-reads every local directory each cycle; client never reaches idle; spurious "Unable to connect" banners #10491 / this one, performance → nothing yet

#10491 was closed as completed against 34.0.1 on that basis. Cost is file count ×
per-file latency, so it's invisible on a small tree on SSD and severe on a large
one — reported often, reproduced rarely. @joseph-valenti measured 34.0.3
yesterday: sync duty cycle 2% → 85% on 400,800 files on a USB HDD, 12% → 36% for
the same tree on NVMe, both back to baseline on rollback to 33.0.7.
#10491 (comment)
Note the WindowsError: 57 spam is gone since 34.0.2 but the work isn't, so
checking for that warning gives a false pass. #10613 and #10687 look related.

Suggested fix in
#10580 (comment) — skip
the check when local metadata already matches the journal record, which keeps it
on the worker thread so #10464 stays fixed. Glad to write the patch; I just have
no Qt build environment to verify it.

Asking for triage and an owner. Thanks for looking.

[RTechSn]

It's not only slower, but the UI becomes unresponsive while sync is in progress.