28/12/2025 Topic: Win11 client machine takes long time to settle Shadohz	I have SyMenu running on a host machine with is networked to a couple of Win11 client machines. The client machines have offline syncing enabled (Win11 feature). The problem is that SyMenu is taking between 15-30 minutes to stop loading when Offline Syncing is disabled and 40minutes to +1hr when Offline Syncing is enabled. By "settle" I mean for SyMenu to stop scanning or whatever it is that it's doing that makes that its icon flicker. The times are from Reboot (i.e. startup) to when the Symenu program gives me access to installed SyMenu applications. The only thing I can say for sure is that Offline Files extends this abnormal behavior. I can't explain why there's a huge time difference in the startup-to-settle times. I read a couple of similar posts about applications being at the root of the SyMenu application folder but that isn't the case here. All the Symenu apps are under Z:\ProgramFiles\SPSSuite\SyMenuSuite. I installed custom apps to \..\SPSSuuite\Custom_Programs. Any explanation or resolution for this? Any way to stop this scan behavior on the client machines?
31/12/2025 Topic: Win11 client machine takes long time to settle Shadohz	As far as the configuration is concerned it's a typical workstation-to-workstation setup. The host and clients are Win 11 Pro. The Symenu is a share on Cdrive with FC to Everyone (i.e. no permission nor rights issues). The clients are mapped to the "symenushare" as Zdrive. Sync Center (aka the Offline Files mode) operates much like Google Drive or OneDrive. It makes a local cache of the selected network files to client machine so the files/apps will operate if/when the client is disconnected or goes mobile. It operates pretty much the same as well: Select 'Make Available Offline" for specific files and folders. Sync Center does some sort of indexing/file compare scan on startup. This behavior doesn't duplicated when you disconnect/reconnect mapped drives. Only on startup or if syncing is manually ran. As I noted earlier this bad behavior from Symenu occurs during startup whether or not Sync Center is enabled. Sync Center only makes it worse as it adds to the delayed response time from SyMenu. I'll have to look at additional troubleshooting steps and time tests later today/later. As you can see just doing one run takes a fair bit of time. Replication will take even longer as I'll have to map a different drive and notate the apps being used in each consecutive test (and Sync Center doesn't attempt to purge the original zdrive files).
09/01/2026 Topic: Win11 client machine takes long time to settle Shadohz	Good news. Bad News. Good news. I found the majority culprit. It was Windows Defender. I ran timed tests with it disabled an immediately noticed the difference in timing. From launch-to-settle, the time took an average of 5:30 for the existing installation. At least for the time being I have excluded SyMenu share from scanning - though it isn't an optimal solution. Bad news. I deviated from your original troubleshooting suggestion after coming to the realization Windows Defender was scanning every execution. I compared my existing install to a net-new install to net-new install with garbage files. I found three problematic areas: 1) launch time 2) many files 3) clean-up/integrity check on launch. Launch time: Regardless if it was a net-new install or my existing installation there was a delay between clicking on the SyMenu application to open to when it finally appeared in the SysTray. That time ranged from 1:44 -3:17. This might falsely lead some users to think the application isn't running/wasn't selected (like it did me initially). Many Files: Regardless if it is a valid install with many applications or as I did with the net-new install by dumping a bunch a files into its structure SyMenu runs slower the more files added to it. Clean-up/integrity check: The features aren't problematic in themselves. They just add additional settle time to SyMenu. Since I'm running SyMenu from a host machine I don't really want the client machine(s) altering the SyMenu installation and running an integrity scan on every launch. The latter seems to be what impacting Windows Defender and also adding additional settlement time. With my original installation I was getting a launch time of 5:24-5:35 (147, 503 files, 12977 folders, 19.4GB). With the Net-new install I was getting various launch times with different scenarios: 2:20-4:30 (clean install), 15:30-18:00 (clean-up/deleting invalid files/folders), 9:27 (scanning with a files in Trash). Yes, merely having files in Trash increases the settlement time. Note: These are the numbers without Sync Center enabled because once its back in play timing becomes a major problem again. The latest recorded time with my original installation was over 40 minutes (23:57 from user sign-in to icon appearance, 25:54 from icon appearance to access (settlement)). Comparing this with PortableApps which under the same testing scenario took 10:30 (7:08 from user sign-in to icon appearance, 2:25 from icon to access (settlement)). I've used PA for over a decade so ironically enough I looked to LibreKey and SyMenu as potential replacements due to its seemingly sluggish behavior and archaic handling of file/app errors and customization. So I guess this brings me back to my original question is there a way to stop or bypass this on-launch scanning behavior.
10/01/2026 Topic: Win11 client machine takes long time to settle Shadohz	SyMenu and PortableApps are near-images of each other. Any programs that exist with PA and SyMenu I downloaded from the SyMenu repository to SM. Save a few applications like ThunderMail and JDownloader where I have custom files or personal data files within their respective app directories, everything is almost the same. There are only a couple of applications exclusive to SM that I've download that don't exist in my PA install. In SM there are 85 application folders, which means at minimum there are 85 application files. The previous number I gave is what Windows Explorer's report of SM share which is 147,000 files/12K folders (irrespective of their designation). However I hand counted all apps shown in SM menu list and there are 96 total. SM exists on "C:\mydata\symenushare" on the server. I have it mapped on the server as "z:symenushare" (i.e. z:\ = c:\mydata). Now stay with me. If I go into File Explorer and launch SM from C: drive location, the launch is instantaneous. The Systray icon appears immediate and the SM icon flickers for a brief moment (seconds), then I have access to the application. HOWEVER very same machine, very same install when I launch SM from the Z: location there is a 10-ish second delay before the Systray icon appears and it flickers longer (25 seconds). So same machine, same (big) installation: Accessing from C: drive takes a total of 10 secs but accessing from Z: drive takes 36 secs. This is exit, relaunch, exit, relaunch testing. The access (from z: on the same machine) slowdown is more sluggish when first signing on (last test was at 4 minutes from icon appearance to access). That very same large SM installation copied to the Client Machine works just as fast as the Server machine if I access SM from the C:\ of the client machine. 10 secs, tops. If I map a network drive to shared drive where SM resides and access it (in this case V, guess what happens. Yep, it slows down again. 48 secs from launch to icon appears and 53 secs from flicker to access for a total of 1:41. So we have a pattern that SyMenu seems to run slower when pointed towards a network location despite the fact it's on the same machine. 36 secs and 1:41 aren't that bad until you look at it from the perspective that the are three times and ten times slower than accessing from C: pathing on the very same machines. Now back to my original problem. Sync Center aka Offline Files (or Offline Mode if you prefer) allows applications to think they are running from a network location by copying the files to a local cache. It is fundamentally that same as I did above. In "airplane mode" or if the network goes down, the application(s) run from the local copy as if it were a remapped local drive. There should be no "network delay" as there is no network to access. - If I turn Sync Center off/disabled AND the network is connected (client to server), SyMenu is terribly slow to access (this is Part A of the original problem and the times I reported). - If I turn Sync Center off/disable AND the network is disconnected, SyMenu doesn't work (as it should). - If I turn Sync Center on/enable AND the network is connected, SyMenu is *slower* than Condition #1 to reach the point of access (this is Part B of the original problem that Sync Center makes it worse) - If I turn Sync Center on/enabled AND network is disconnected, Symenu is still slow to access. - Once I reach the point of access, SyMenu runs fine as far as functionality and how fast the supported programs launch and work. I did net-new/clean install time testing along side testing my original installation and gave you the numbers. There are still noticeable time differences with the clean installation with the exact same perimeters. "No, there isn't. And there is no reason to prevent it because this is not your real problem." I'm just going to migrate everything back to PortableApps.

---