|
samo Posts: 4
26 days ago
|
hi Gian,
I have a very old symenu installation I'm using daily for many years.
I'm using syncthing on my 4 computers, to sync the whole symenu folder, 11GB, and I noticed a weird behaviour.
Maybe it was partly present before, but now it started to be very noticable.
1, The startup of symenu takes 1-2 minutes now. While "frozen", the splash image is displayed with 50% brightness, and symenu systray icon has a green square blinking rapidly in its bottom right corner.
2, at random time while using PC, symenu UI freezes completely. Sometimes while clicking on symenu systray icon, sometimes while browsing options, doing app updates, etc. This freezed state lasts 2-3 minues, after that, symenu continues to work as usual.
This is not an issue of having all apps in root, discussed here on forums before.
I have maybe 60 entries in symenu, apps and a few custom exe file launchers. see the screenshot here - https://drive.google.com/drive/folders/1sar-DplI-VFQif7hj9xEHLD5KIV7cmWD?usp=sharing
could you advice on how to debug this, before I embark on a difficult way - installing a fresh new symenu and copying all my apps and settings there?
edited by samo on 17/02/2026
|
|
|
link
|
|
Gianluca Administrator Posts: 1378
26 days ago
|
Hi Samo, there’s absolutely no need to reinstall anything. SyMenu doesn’t write to the system registry, so it doesn’t accumulate junk over time. Your first run is exactly the same as your last one.
Before giving you what is not a solution but a possible cause list, I suggest you try this:
- back up your SyMenu\Config folder somewhere safe
- delete SyMenu\Config\SyMenuConfig.zip
SyMenuConfig.zip is where SyMenu stores its settings, not your items configuration, so you can safely delete it.
When you start the program again, it will ask you to configure everything (language, license, privacy, contextual menu elements, colors, and so on).
With a non‑customized menu (no autoxec, no gestures, no custom shortcuts), try using it for a while to see whether the issue is actually related to SyMenu.
But trust the old man: this probably won’t be your solution.
What you’re describing strongly suggests:
- synchronization issues
- antivirus interference
- storage problems
If you’re experiencing the exact same issue on all four of your PCs (you didn’t mention that), it’s probably the antivirus slowing down access to one of your program folders.
Synchronization can easily stall the filesystem, as we learned from another user who abandoned SyMenu because it couldn’t handle his complex sync setup (https://www.ugmfree.it/forum/messages.aspx?TopicID=959).
If the problem occurs only on one PC, check the disk, it might be time to replace it.
Let me know if any of this resonates.
|
|
|
link
|
|
samo Posts: 4
15 days ago
|
Hello Gian,
thank you for a quick and comprehensive answer,
I followed the steps, tested it on multiple PCs, and at the end, I realized it is related only to one PC, where symenu is taking much more time, so it is in the startup setup I use on that PC only.
I didn't resolve it completely, but it is apparently not a problem of symenu app itself,
thank you for supporting us and keeping this project going on strongly!
|
|
|
link
|
|
Maaspuck Posts: 5
7 days ago
|
Hi,
just as an information. I encountered a very similar problem with extremely nasty freezes and lags using SyMenu starting a few weeks ago. I even tried a new "installation" of SyMenu with no programs in it. It was just the same problem then. I figured out, that scanning times were extremely long (SyMenu Symbol with flashing green dot) after start of SyMenu and after updating SyMenu. I am using a NAS with three configured network drive letters. NAS is only switched on, when it must be used, so it is not running 24/7. When NAS is on and network drive letters are available, SyMenu is as fast as it used to be.
Until now, I didn't expect, that the network drives are the root of my problem as I am using a comparable configuration of network drives on a NAS not switched on 24/7 together with a SyMenu Installation of 18 GB of data for many years now. Though I changed my NAS Installation (QNAP TS 451+ from QTS to OMV), I think that there must have been any change in scanning process of the operating system. SyMenu directory was always excluded from Defender Antivirus.
My System:
ASUS X570-E Gaming
32 GB DDR4
AMD Ryzen 5800X3D
Nvidia RTX 4070
Soundblaster AE-5
Corsair MP600 1 TB
Samsung 990 Pro 4 TB (Symenu is installed this SSD)
Samsung 860 QVO 2 TB
WD 6 TB HDD
Software: Windows 11, MS Office 21, PhotoLab 9, Game Launchers (EPIC, UbiSoft, EA, Gog, Steam), MSI Afterburner + RTSS, Citrix Workspace, MS PowerToys and many more
edited by Maaspuck on 08/03/2026
edited by Maaspuck on 08/03/2026
|
|
|
link
|
|
Gianluca Administrator Posts: 1378
7 days ago
|
Finally, this is something really interesting.
To recap: it seems that when a network drive is mapped but the device is offline, SyMenu asks Windows to enumerate the folders to begin its scan. Instead of returning an immediate error (like 'not found' or 'unavailable'), the OS keeps trying to access the drive until a very long timeout is reached.
Dear Windows, old boy... anyway, let's try to work around it as we usually do.
I need a log from SyMenu.
To enable logging, you need to start the application from the command line with a special argument:
SyMenu.exe -logger
If the lag occurs, please close SyMenu and send me the log file privately. You will find it in the SyMenu root folder, named something like LogFile.20260308.txt.
Also, if possible, I’d like you to try this test:
Move all your items (programs, folders, etc.) that point to the mapped drive into a SyMenu subfolder.
For example, if you have an item like Z:\myprogram.exe directly in the SyMenu root, create a new container/folder and move it inside.
Then, restart SyMenu and let’s see if the startup delay disappears.
|
|
|
link
|
|
Maaspuck Posts: 5
7 days ago
|
Hi, i will come back with a log soon
Meanwhile, I created a skript connecting network drive letters only a start of NAS and deleting them during shutdown to be sure no network drive letters of non existing connections exist.
Concerning programs that point to the network drives.....there is none as far as I know (unless I haven't make any mistake, I must check this). I habe one complete symenu folder on my local ssd and did not add any "external" program so far.
|
|
|
link
|
|
Gianluca Administrator Posts: 1378
7 days ago
|
I don't understad... you have no SyMenu items (folders or programs) pointing to one of the NAS but if the NAS is offline, SyMenu suffers the same. Is it possible?
The only scenarios in which this is possible is:
- when you navigate through folders with SyMenu but, again, SyMenu loads every folder content only if you want to open it.
- if you mapped some NAS resources in your Start Menu. SyMenu scans your start menu to link whatever it finds inside. In this case any broken link is ignored. But, if the OS needs a long timeout to tell SyMenu that one resource is broken... well you got your delay.
|
|
|
link
|
|
Maaspuck Posts: 5
7 days ago
|
yes, I know it sounds very strange....
I tried with a complete new download of symenu without any program....and its slow again if network drives are not available.
Of course, when I hover the mouse over "my computer", syMenu starts to scan again and it takes its time then again.
|
|
|
link
|
|
Gianluca Administrator Posts: 1378
7 days ago
|
I need your help to check the workaround I created.
I’ve built a new beta version, identical to the current one, but with a new system designed to prevent Windows from 'hanging' while trying to access inactive or unavailable network drives. This was indeed the root cause of the freezes you experienced in SyMenu.
You can download the beta and use it to overwrite your current installation, or simply run it in parallel only to test the fix.
One important note: since this is a manual download, Windows might trigger its security protection. To avoid any issues, please remember to unblock the ZIP file after downloading it, as explained here for plugins: https://www.ugmfree.it/manual#SyMenuPluginBlocked.
The beta URL is available here: https://www.ugmfree.it/public/SyMenuBeta/SyMenu.8.12.9563.beta.zip
Please let me know if this resolves the issue.
|
|
|
link
|
|
Maaspuck Posts: 5
7 days ago
|
Hi,
you will find some logfiles in PN. I always started symenu.exe -logger from the command line as stated above.
With network drive letters available, but not accessible, the start is still slower. I did not use a stop watch, but I had the feeling that it was a bit more reliable though slow.
A big improvement is, that though drive letters are available, the menu in "My computer" did not show them and SyMenu did not try to access them making this menu fast again independently from network drive letter existance.
After "deleting" the network drive letters using "net use X: /delete", SyMenu started within a second as expected with no programs installed.
With accessible network drives SyMenu started fluent au usual including fast "My Computer" Menu.
So overall, I would state, that the "My Computer" Menu is fast again, even with unaccessible network drives but start of SyMenu is still slower with unaccessible network drives than without.
|
|
|
link
|
|
Gianluca Administrator Posts: 1378
7 days ago
|
Ok then my workaround works and this is the good news, but probably I have to apply it in another place too. So stay tuned!
|
|
|
link
|
|
Gianluca Administrator Posts: 1378
6 days ago
|
Now the problem is finally clear.
Windows uses a component called the Network Redirector to manage communications with network drives.
Unfortunately, it has a very long default timeout (10-20 seconds) before declaring a unit unreachable. As we know... networks can be slow by definition.
In my previous attempt, I only partially solved the problem. I used an API that 'wakes up' the Network Redirector on the first unit checked (X: in Masspuck's case). This still required those 10-20 seconds for the first check, but at least the Redirector was smart enough to realize that other units on the same IP were also down. Good boy, Redirector.
Before this update, SyMenu didn't trigger this behavior, causing timeouts to pile up one after another.
Since there’s no way to change how Windows works, I decided to run every check on separate threads in parallel.
Why didn't I do this in the first place? Because SyMenu loads so fast that I was afraid a user might click on a unit before it was actually ready.
With hindsight... well, who cares? If a user is that fast, they’ll be smart enough to understand they just need to try again.
As I get older, I tend to become more and more cautious, so now the behavior is slightly different: you won't see a network unit until it's confirmed as ready. So, if you’re quick enough, you might actually see a mapped unit appear in 'My Computer' right before your eyes.
I’m quite confident the problem is now solved, but I’m looking forward to your feedback.
A word for Maaspuck:
Without your help, I couldn't have solved this. You have been great, fast, and precise in your reporting. If all users were like you, SyMenu would have been bug-free for years!
The new beta is here: https://www.ugmfree.it/public/SyMenuBeta/SyMenu.8.12.9564.beta.zip
|
|
|
link
|
|
Maaspuck Posts: 5
6 days ago
|
Hi,
the new beta works fantastic.
11 GB of programm data and 3 non accessible network drive letter configured.... start in 1 second !!! Brilliant :-)
@Gian
Thanks a lot for your kind words and thanks a lot for your quick support.
|
|
|
link
|