Bug: Files UI takes 25 seconds to be responsive at launch

[SilverGreen93]

Description

When launching Files 3.9.12.0/3.9.13.0 for the first time (i.e. without being ran in background), the interface is frozen for about 25 seconds before I can interact with it.

This issue is not reproducible in Files 3.9.1.0.

Steps To Reproduce

1. Make sure there is no Files process running.
2. Open Files 3.9.12.0 or 3.9.13.0
3. Try using the interface by clicking with the mouse.
4. The interface is frozen for about 25 seconds, then it works fine.

Files Version

3.9.12.0

Windows Version

10.0.26100.4770

User ID

a4572e3c-4109-43f3-aad3-3fd6e544edc2

Log File

debug.log

[yaira2]

Is this only the first launch? This is one of the downsides of self-contained .net. By bundling it with the app package, it adds more files for the antivirus to scan contributing to slow performance on the first launch. Future launches shouldn't be affected.

Fyi @hez2010

[SilverGreen93]

Is this only the first launch? This is one of the downsides of self-contained .net. By bundling it with the app package, it adds more files for the antivirus to scan contributing to slow performance on the first launch. Future launches shouldn't be affected.

So from my tests, this happens every time when I launch Files-Preview if it is NOT running already in the background. If it is already running in the background, it is faster to respond (under 1 second compared to ~25 seconds).

But Files 3.9.1.0 does not have this problem. It is responsive even if it is or not already running in the background almost immediately, that's why I suspected something that was introduced in a subsequent version is triggering this.

[yaira2]

Can you check with a fresh install of v3.9.1?

[SilverGreen93]

Can you check with a fresh install of v3.9.1?

I uninstalled Files and reinstalled it. Works fine, launches pretty quick, the same as before.

[yaira2]

Can you please upload the log file for preview?

[SilverGreen93]

Can you please upload the log file for preview?

Sure, uploaded the log in the report.

[yaira2]

This is possibly related to #17088.