FreeFileSync on Windows 10: Runtime Broker high CPU usage

Posts: 28 · petrovski80 5 Sep 2015, 18:18

Does anyone who uses Windows 10 experience high CPU usage of the process RunTimeBroker during and even after syncing using FreeFileSync? In my case, I observe three scenarios:

1) RunTimeBroker high CPU/MEM usage during sync but drops as soon as the sync is done
2) RunTimeBroker high CPU/MEM usage during sync and stays high when sync is done
3) Hanging FreeFileSync sync job combined with RunTimeBroker high CPU/MEM usage

Note that since there are a lot of complaints about RunTimeBroker process on the internet if you Google it, and I had zero problems with FFS on Windows 7, I'm thinking this issue is cause by Microsoft itself instead of FFS. Unless of course Microsoft dictates a different way of file access or disk IO operations on Windows 10 that FFS still needs to implement, I don't know. Just curious to find out if I'm the only FFS user on Windows 10 that sees RunTimeBroker freak out during FFS syncs.

Posts: 28 · petrovski80 9 Sep 2015, 17:11

For the record: a workaround for this issue is to disable the TimeBroker service via the registry (sevices.msc GUI does not allow to set this service to disabled).

Posts: 13 · bob_down 29 Sep 2015, 20:43

For the record: a workaround for this issue is to disable the TimeBroker service via the registry (sevices.msc GUI does not allow to set this service to disabled).petrovski80

Having very similar issues, since updating from Win 8.1 to Win 10. I have FFS running in batch mode at a scheduled time. Around half the time it seems to complete ok, the other half of the time it "stops responding" during the source file scan and Windows offers to close the application. Needless to say that's a disaster in unattended mode.

If I kill a non-responsive batch run and then run FFS manually, it seems to always work ok,

Have been updating to the latest versions as they become available, but the problem persists.

Disabling the TimeBroker service is not a viable workaround. That stops any Store Apps from running.

Posts: 7211 · Zenju 30 Sep 2015, 10:08

Can you send me a process explorer dump file when FFS hangs again? This should help to get some idea what is going on:
https://freefilesync.org/faq.php#crash

Posts: 13 · bob_down 4 Oct 2015, 02:13

By "dump", do you mean File -> Save?

[Attachment was removed! File name: Logfile.7z (10974969 bytes)]

Posts: 7211 · Zenju 4 Oct 2015, 09:40

By "dump", do you mean File -> Save?bob_down

I was referring to "Process Explorer", not "Process Monitor". (However having a pml file for analysis never hurts...)

Posts: 13 · bob_down 7 Oct 2015, 20:28

I was referring to "Process Explorer", not "Process Monitor". (However having a pml file for analysis never hurts...)Zenju

You mean this then? https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Forgive my confusion, but you actually asked for Process Monitor. :)

If the answer is yes, do you want a minidump or a full dump?

Posts: 13 · bob_down 7 Oct 2015, 20:31

I thought the remote machine may have been part of the issue, but I am now syncing with a different PC entirely and the issues persist.

Posts: 7211 · Zenju 9 Oct 2015, 11:06

You mean this then? https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Forgive my confusion, but you actually asked for Process Monitor. :)

If the answer is yes, do you want a minidump or a full dump?bob_down

Yes, Process *Explorer*. A full dump is better of course, ideally a few ones (this is monte-carlo debugging...)

Posts: 13 · bob_down 11 Oct 2015, 01:19

Yes, Process *Explorer*. A full dump is better of course, ideally a few ones (this is monte-carlo debugging...)Zenju

It wouldn't let me. when I tried to save a dump with Process Explorer it complained about something and refused (permissions I believe). I'll try to make a note of the error next time. It's rather hectic here for unrelated reasons.

Posts: 13 · bob_down 11 Oct 2015, 02:48

Yes, Process *Explorer*. A full dump is better of course, ideally a few ones (this is monte-carlo debugging...)Zenju

FFS seems to be bogging down on every run now, Windows 10 keeps offering to close the program. I assume you wanted a dump of both exes? It's not easy uploading such large files, sourceforge keeps timing out on me.

[Attachment was removed! File name: FreeFileSync.7z (5210053 bytes)]

Posts: 13 · bob_down 11 Oct 2015, 02:56

Yes, Process *Explorer*. A full dump is better of course, ideally a few ones (this is monte-carlo debugging...)Zenju

Nah, I can't get the dump for the 64bit exe to upload. The zip file is about 40meg and sourceforge keeps barfing before the upload completes.

Posts: 13 · bob_down 11 Oct 2015, 03:07

Nah, I can't get the dump for the 64bit exe to upload. The zip file is about 40meg and sourceforge keeps barfing before the upload completes.bob_down

One more try

[Attachment was removed! File name: FreeFileSync_x64.7z (40423436 bytes)]

Posts: 13 · bob_down 11 Oct 2015, 20:57

Yes, Process *Explorer*. A full dump is better of course, ideally a few ones (this is monte-carlo debugging...)Zenju

The problem seems to be related to the external drive connected to the PC running FFS. I'm sitting here now, watching FFS go through a run, it's just into its second hour on what is normally a 3 minute sync. It's copying new files over to my 4tb USB3 drive and it's very slow. I just manually copied 5 gb of files back and forward to this drive from C: and the speeds are normal.

Files in the FFS window are showing a transfer rate around 700 bytes/sec, whereas manually copied files are around 60-100 MB/s.

This ties in with anoth thing I've observed. Sometimes, when the scanning portion is extremely slow, if I stop FFS, unplug the USB drive and plug it back in, FFS will then scan through at normal speed. I've never observed it copying so slowly before, but then I usually kill the task well before we reach this stage. (or I've not been here to observe)

Yes I have done a full chkdsk on both the internal and usb drives quite recently. When I first observed the scanning slowness I checked for file system problems. I use the USB drive myself all day every day and I've not noticed any access issues in normal use.

Posts: 13 · bob_down 11 Oct 2015, 20:58

Yes, Process *Explorer*. A full dump is better of course, ideally a few ones (this is monte-carlo debugging...)Zenju

Also, at the moment, I can't create a dump again. I'm told "error opening process - access is denied"

Posts: 7211 · Zenju 12 Oct 2015, 09:20

One more trybob_down

Is this snapshot taken during a "stops responding" situation? Except for a lot of threads scanning directories in parallel, the main thread is not blocked with file I/O.

Posts: 13 · bob_down 14 Oct 2015, 07:06

Is this snapshot taken during a "stops responding" situation? Except for a lot of threads scanning directories in parallel, the main thread is not blocked with file I/O.Zenju

Yes... This particular one is a slow responding, not a stops responding. Sometimes it struggles on just at really poor speeds.

Which exe do you actually need the dump from?

Posts: 13 · bob_down 14 Oct 2015, 07:25

Is this snapshot taken during a "stops responding" situation? Except for a lot of threads scanning directories in parallel, the main thread is not blocked with file I/O.Zenju

Here's a log of a similar run.

[Attachment was removed! File name: SyncSettings 2015-10-12 060551 [Warning].log (770094 bytes)]

Posts: 7211 · Zenju 14 Oct 2015, 14:01

The problem seems to be related to the external drive connected to the PC running FFS. I'm sitting here now, watching FFS go through a run, it's just into its second hour on what is normally a 3 minute sync. It's copying new files over to my 4tb USB3 drive and it's very slow. I just manually copied 5 gb of files back and forward to this drive from C: and the speeds are normal.

Files in the FFS window are showing a transfer rate around 700 bytes/sec, whereas manually copied files are around 60-100 MB/s.

This ties in with anoth thing I've observed. Sometimes, when the scanning portion is extremely slow, if I stop FFS, unplug the USB drive and plug it back in, FFS will then scan through at normal speed. I've never observed it copying so slowly before, but then I usually kill the task well before we reach this stage. (or I've not been here to observe)

Yes I have done a full chkdsk on both the internal and usb drives quite recently. When I first observed the scanning slowness I checked for file system problems. I use the USB drive myself all day every day and I've not noticed any access issues in normal use.bob_down

I suspect the general system non-responsiveness issues are caused by the USB3 driver. USB3 drivers are still flaky even on Windows 7 where they lead to exactly the symptoms you describe. Practically speaking the best solution is to upgrade to the most recent USB3 drivers available for your mainboard, or if nothing helps use an USB2 connection.

Posts: 13 · bob_down 14 Oct 2015, 20:33

I suspect the general system non-responsiveness issues are caused by the USB3 driver. USB3 drivers are still flaky even on Windows 7 where they lead to exactly the symptoms you describe. Practically speaking the best solution is to upgrade to the most recent USB3 drivers available for your mainboard, or if nothing helps use an USB2 connection.Zenju

The logs provided were taken *while* the drive was on a USB2 connection. The type of interface is not the problem. The problem occurs whther the drive is connected to a USB3 or USB2 port. I've been using the drive on a USB2 port for some time now, in order to eliminate the possibility that the USB3 drivers are at fault.

The problem is with FFS. When the problem occurs, I can manually copy files to and from the external drive at full speed, at exactly the same time that FFS is struggling along (usually at about 700bps). I even setup Synctoy to copy files to and from the same drives, it runs at normal speeds, whilst FFS is slow.

The problem has only commenced since the PC was updated to Windows 10. Previously this PC had run Windows 8.1 and 7 and had never had an issue with FFS. I still have no issues with copying files manually, nor with other utilities.

The problem is also random. This morning FFS completed normally, yet the hardware has not been touched since the last 'bad' run. I'll attach the log for this morning's run.