Classic Shell: Forum

Sometimes when I open Classic start menu it takes 5-10 seconds to open. This seems to happen the first time I use it for a while. If I open it immediately again it will be quick. But if I go another 2 hours without opening it and then open it again it will be slow the first time again.

I'm on windows 10 1607. Version 4.3.0 of Classic start menu.

Any thoughts?

Hello CS Team,

I observe EXACTLY the same problem on all my Windows 7 systems since, as far as I remember, 4.2.5 version or even earlier. Maybe it is caused by very similar configuration applied on all computers, maybe not. Even measured delays are the same I reconciled to this, as this is just delay (not crash or something like this), so I'll take a deep breath and... Start Menu appears after a while. It could be great to fix this, or at least guide us what to check. Despite this, many, really many thanks for cool piece of software

Best regards,
Mario

You can capture a slowdown dump as per the instructions here: viewtopic.php?f=12&t=6

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.

I have this exact problem, however it's not only that the start menu takes time to open, it's Windows explorer.exe (explorer.exe) in general that becomes slow while using classic shell. It seems to be random encounters but anything related to explorer, like opening the start menu, control panel, this pc, any harddrive, folder, etc can take a good 5-10 seconds. However when it occurs and finishes, everything will work just fine afterwards.

My posting could have been EXACTELY like yours, bambula
Including your
- I'll take a deep breath and... (), ... It could be great to fix this, or at least guide us what to check...()
- Despite this, many, really many thanks for cool piece of software

@FlaX - your dumps also didn't reveal anything suspicious. Possibly the slowdown is caused by something outside of the Explorer process, or is too short to be caught by the ProcDump method.
Usually such intermittent slowdowns are caused by accessing files over the network, or accessing a device that is in sleep mode - maybe your disk drive spins down if it is not used for a while?

Hello CS Team,

I'm sorry for long delay, but I tried to catch CS slow response last days without any success (CS worked without any issues ). But today he capitulated - dumps in attachment. Unfortunately I captured only 6 dumps, I suppose first 4 show explorer.exe "slowness", last 2 - explorer.exe "recovery". If it is not sufficient I'll try to capture new dumps ASAP.

Best regards,
Mario

The dumps show that the menu is stuck inside this function: https://msdn.microsoft.com/en-us/library/ms675983(v=vs.85).aspx
It is trying to find the name of the domain controller. Possibly you are in a network with a non-responsive domain server or something. I don't know much about Active Directory to tell you what may be the problem and how to fix it.

Check out the section "Notes on Domain Controller Stickiness" in that MSDN page. It shows how to set up the rediscovery interval for the domain controller.

Hello Ivo,

Thank you for your really valuable explanation. Can you analyze also these dumps, please ? I'm curious, if you find the same AD-related issues.

Best regards,
Mario

Yes, that looks like the same issue.

Hello Ivo,

What you wrote is 100% true My home DC was turned off when CS slowness was observed. I'm very impressed . Let me make tests with DC turned on. Thank you Ivo for your support.

Best regards,
Mario

Hi Ivo.


We are encountering exactly the same issue, however we have a number of domain controllers which look to be fine so I'm not sure it is the same issue there. I have attached a process dump, can you please analyse this one too? The delay should be recorded in the first or second one. I noticed that in the StartMenuLog.txt there is a big difference in the numbers at the start (I assume they are milliseconds) before the Open Menu appears in the log. We only started encountering this issue after installing Office 2016 and maybe some Windows Updates too. We were running version 4.1 and have upgraded to 4.3 however the same issue occurs in it too.


Slow load

0: ItemOptions[31]=3
0: ItemOptions[32]=3
0: ItemOptions[33]=3
3515: Open Menu, ptr=000000000CFD3790, index=-1, options=00000608
3515: Loading user image: 'C:\ProgramData\Microsoft\User Account Pictures\user.png'


Normal load

0: ItemOptions[31]=3
0: ItemOptions[32]=3
0: ItemOptions[33]=3
31: Open Menu, ptr=000000000CFD3790, index=-1, options=00000608
31: Loading user image: 'C:\ProgramData\Microsoft\User Account Pictures\user.png'

The dump shows something about the C:\Program Files (x86)\Citrix\System32\Sfrhook64.dll.

Wow, thanks for your quick reply! We are using Citrix with VDA version 7.6.300.7020 installed. The server we are encountering it on is exactly the same as another server image except for Office 2016 and a different PDF program installed which we are trialling. We are also running this combination of Citrix version and Classic Shell on a number of other servers with no issues. That hook handles "Special Folder Redirection" for XenApp. I'll try to disable the hook as a troubleshooting step. Can you see in the dump that it delays the startup by 3.5 seconds or are you just wondering what it is?

No, sorry. The dumps have no way of showing any direct relationship between the operations and the specific times. It simply captures a snapshot at certain intervals in the hopes that whatever operation takes a long time will be captured. The fact that the Citrix operation was captured doesn't mean conclusively that it is the problem, just that it is one of the most probable culprits.

But in general, anything involving network operations can be slow, because the other side may be slow to respond for a large number of reasons - network congestion, cache being out of date, server going into low-power state because of inactivity, etc.

Ok, thanks Ivo. It seems to be something with this server though as other servers pointing to the same shortcuts on a network server don't encounter the issue. I don't really want to rebuild it from scratch. I noticed that the dump was only for Explorer, is there any further debugging for the Classic Shell process that will show it waiting for Explorer?

No, the ClassicStartMenu.exe process is non-essential to the operation of the start menu.

Hi Ivo. I found that it operated fine if the Classic Start Menu Group Policy (created pointing to a folder with Office 2016 shortcuts) wasn't applied, so started adding in settings one by one and testing and found that there was an incorrect path in the policy. Correcting the path fixed the issue as it doesn't try then timeout on the invalid path so there is no delay now! Thanks for your help.

Hi, i have the problem that usually a bit time before start menu appear after click mouse on it. I upload procdump.zip for find a solution. Thanks

The dump did not catch anything interesting. You need to capture a series of dumps while the menu is opening.

I have the same problem, windows 7 64bit - I will try and get a dump file but I've noticed that explorer will wake up my external drives before the start menu will open. This happens every time the start menu freezes, once the drives are awake (I hear them spinning up) then the menu will open. I don't have anything pinned to the menu which is on another drive so not sure why this happens.

You can use Process Monitor to identify what is being accessed on those drives. Maybe if you have This PC pinned to the menu, it needs to refresh the drive icons?