Classic Shell: Forum

Classic Start Menu 4.2.5, Win10-64 Pro. Sometime after left click on "Start" button taskbar (including "Start" button) stops responding until Windows Explorer restarted in Task Manager.

You could capture a dump when this happens. For instructions, click on "How to capture crash dumps" at the top of this page.

The provided instructions for procuring a crash dump didn't work for me. I always got a "[xx:xx:xx] Multiple processes match the specified name." message and no crash dumps. You should update the instructions to tell people to turn off the "Launch folder windows in a separate Process" option and to kill any extraneous Explorer.exe instances (or reboot PC).

_________________
Windows 10 Pro x64

I updated the instructions, Franpa.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

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

Set registry as described, will wait for bug to appear again. Most of Windows Explorer crashes (almost 100%) happened after attempt to update Nvidia (FeForce GTX 660) drivers from 358 to 361. It always finished with "Install error" until with "Clean install" I completely lost drivers. During that time after every restart Windows Explorer stopped working until restart in Task Manager.
Since then I erased old installs with Display Driver Uninstaller, recent driver installed and works so far without errors. Since upgrade Win7 to Win10 got maybe 2-3 WE not responding on those 358 drivers.

I think we're having the same problem at the school I work at too.

The Start Menu and entire Taskbar will sometimes freeze, seemingly at random. Restarting Explorer would fix it, but that's not a workable solution for hundreds of staff and students, most of whom don't have access to Task Manager anyway (and would find it too cumbersome to grasp the process even if they did).

I've put a crash dump (7-Zip compressed on Ultra) from when it's in the "hung" state on my workstation here if it helps:

https://drive.google.com/open?id=0B67oB ... HczOTNfREE

According to the dump, the start menu is trying to access this folder: "%APPDATA%\ClassicShell\Pinned"
Is it possible that folder is on a network share that is slow or currently inaccessible?

That's entirely possible, but if so there's nothing I can do about it. The network or file server may well be congested at times and we've no money to replace (bits of) either. I imagine the problem is the same as in this thread:

viewtopic.php?f=12&t=3256

Based on that, could we ask that something along the lines of what's requested there is included in the next version please? It would seem the dump I've provided (which is as far as the OP there got) confirms the issue reported back then.

I realise the whole "redirected AppData" debate is ongoing, but we're in the same position as "nathanlock" - it's a school, so everyone is hot-desking all the time and mandatory profiles are in effect, so preserving AppData between sessions is the only way for students to be able to maintain a number of per-app settings. Also, in our case, there are no pinned apps and there never will be - we have it set to automatically skip them and open the All Programs folder. Ideally there could perhaps be an option for Classic Start Menu not to check that folder (or any folder) every time it's opened? Or just a "disable pinned items" option? Or could there just be a timeout of e.g. 5 seconds if it can't see it?

Aside: "GauravK" notes in that other thread that changing the setting to "Use Start Menu folder" might help - but as I understand it, that would check the central folder in ProgramData along with the user's personal Start Menu folder - which is ALSO inside redirected AppData...

Pretty, pretty, pretty please?

You can switch the pinned programs to be placed in the start menu folder instead of a dedicated folder. In the Main Menu tab switch "Pinned Programs folder" to "Use Start Menu folder".
But if the start menu is also on the network, it might not actually make a difference.

That's my point, hence the feature request...

I'm not sure what your request is - if the start menu folder is on the network, and the network is slow, the start menu will be slow. There is no way around that.

True, but if the Classic Start Menu didn't try to access AppData\Roaming\ClassicShell\Pinned every time it's clicked, that wouldn't matter. We don't use or need pinned apps. Obviously other people would, but a configurable option to disable them (defaulting to off) shouldn't inconvenience any other users.

Also, just to clarify: the problem isn't that it's "slow", i.e. it just takes a few seconds to appear... once Classic Start Menu / Taskbar is in that state, it NEVER appears and seems to get locked in that state. If you restart Explorer through the Task Manager, everything is fine (but normal users can't do that and wouldn't know how to anyway). It almost seems like if it can't access the required location just momentarily, it becomes unusable indefinitely until restarted - which for most users will mean logging off/on. That was what gave me the "timeout" idea.

If you switch the "Pinned Programs folder" setting, the start menu will not try to access AppData\Roaming\ClassicShell\Pinned folder.

Quoting you above:
"But if the start menu is also on the network, it might not actually make a difference."

Presumably because it will try to access "AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu" instead. Anything on AppData\Roaming is redirected to the same server, over the same network, so whether it's "AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu" or "AppData\Roaming\ClassicShell\Pinned" makes no difference. The problem occurs when accessing redirected folders, so the solution would be to not check anything that is redirected - i.e. not check for pinned apps at all in this case.

Similar to how the datacache.db was moved from %appdata%\ClassicShell\ to %Localappdata%\ClassicShell\, couldn't the Pinned programs folder also be %Localappdata%\ClassicShell\Pinned in a future version of Classic Shell? That would of course require the users using the new version to migrate the shortcuts from %appdata%\ClassicShell\Pinned to %Localappdata%\ClassicShell\Pinned but it would be a one time thing. Or the menu could move those shortcuts on its own.

For those who want roaming pinned programs, they can use the Start Menu folder since it can be redirected.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

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

I'm not talking about the pinned folder. I'm talking about the actual start menu folder %APPDATA%\Microsoft\Windows\Start Menu. That's where the start menu keeps its per-user shortcuts.

That's right, Gaurav - it's about an option to use %Localappdata% instead of %Appdata% (which might be redirected) by default.

I am not talking about an option. Since both, the Start Menu folder and the Pinned folder are inside %appdata%, redirecting appdata to a network causes issues. The design can be changed so one of the folders is always in %localappdata%. If users want their pinned shortcuts in their roaming user profile, they can switch to the Start Menu folder.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

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

The only way to stop using the roaming folder is to:
1) Set the pinned folder to use the start menu folder
2) Use the policy "Start Menu folder" to point the start menu folder to a local path

If you do both, then the start menu will be local and the pinned folder will be local.

In 2), do you mean a Group Policy setting?

yes

There are two problems with that:

1) The Start Menu does need to remain redirected for us. Either way...
2) The Group Policy setting to redirect the Start Menu is designed to essentially point the "All Programs" folder list at the specified location. It does NOT change the Windows "pinned items" location, which is still "AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu"... and that is redirected because it's part of AppData\Roaming.

The solution, then, would be an option to have the ClassicShell\Pinned folder created in - and subsequently accessed from - AppData\Local, rather than AppData\Roaming.

1) If you use the "Pinned Programs folder" setting to point to the start menu then the folder "%APPDATA%\ClassicShell\Pinned" will not be accessed. The start menu folder will be used instead. If you insist to place the start menu folder on the network then the pinned feature is the least of your problems. The entire start menu will be slow, not just the pinned items.

2) Yes, the group policy only affects the start menu. It has no effect on the rest of Windows, which may or may not use AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu (however Classic Shell doesn't use that folder at all)

@Ephelyon, Oh OK I see what Ivo means now. The Start menu folder itself (and its Programs subfolder) will be slow when it is redirected even if Pinned was inside %localappdata% defeating the purpose. First, try switching to the Start Menu folder and pin your shortcuts again. See if the slowdown goes away. If not, then it means the Start Menu folder is redirected and everything inside it (all the shortcuts in All Programs).

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

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

Alrighty, we'll give that a go - it's half-term this week so they can come back to a bit of a different look-and-feel on the Start Menu

Ephelyon, did you try out the suggestion, and did it make a difference? We're running into the exact same issue. If changing the Pinned Programs folder works, it'll fix it for us, as we leave the Start Menu folder as part of the roaming profile, rather than redirecting the folder.

Apologies for not responding earlier - yes, it's made a dramatic difference! Many thanks again to those who contributed above.

Thanks for the update! We're going to change it for a key user group and see if it takes care of the issue for us as well.

Update: while the change above did improve the situation, the problem is still occurring. Persistent interface hangs are causing whole classes to have to move rooms! :/

I'm sorry, but the start menu needs the folders to be responsive to do its work. If you need to redirect the folders to a network location, it has to have the necessary performance characteristics to serve all the users you have connected to it. If the file share hangs then the start menu will hang as well.

My issue with that is that we do NOT experience fileshare performance issues in any other respect on this network that would indicate a problem. Also, the Start Menu redirection works absolutely flawlessly on all Windows 7 machines (using the built-in shell) and always has, as indeed on any Windows 10 workstations where I disable Classic Shell.

Same network, same servers, same endpoint devices - no issues.

Update: our entire network (i.e. all the switches) is currently being refreshed, so I've been logged on as a local admin user all day with no redirected Start Menu. I've still been experiencing the issue with Classic Start though. Here is a link to a dump file I created during an explorer.exe hang today:

https://drive.google.com/open?id=0B67oB ... jNJQ3h2M0U

(On a side note: is there an easy way for me to analyse the dump file to check for the same information as you i.e. what was it trying to get to, or is it a lot more complicated than that?)

I also have the same problem after I use classicshell in combination with Windows 10 and roaming profiles. I have two separate clients with small offices (e.g. 10 Windows10 pc's + 2012 AD / File server, Simple Gigabit Switch), on both offices the problem exists on all machines when using classicshell. After some right clicking, the taskbar and start menu are just freezing and won't come back unless explorer.exe process is ended. All open applications are also not accessible when this happends. It happends all the time and driving me and my clients crazy. Unfortunately I removed ClassicShell from all machines now until there is a fix. Both offices succesfully used ClassicShell on the clients with Windows7 and Windows 8.1. These same client machines were upgraded to Windows 10, and then ClassicShell the problems start.

Situation on both offices: I use standard roaming profiles (loaded on logon from a profiles$ share) with folder redirection for the folders Documents, Video's, Pictures, Favorites, Contacts, Links. So, when a user logs on, the profile itself (startmenu etc.) is created (or read from share and created locally) on the client machine itself. So I cannot imagine that it has something to do with accessing the shared folder at any time during the right clicks.

I am glad that I came across this forumpost to see that I am not the only one with this problem. Took me multiple hours to learn that it was Classicshell that created this problem.

Same thing happening for me, its very frustrating as i wanted to roll windows 10 out this summer but its holding me back because of these issues with classicshell.

explorer is freezing and cannot access start menu and all shortcuts on desktop cease to function, restarting explorer brings them back but its not good.

Any news on this at all??

@willowfield2012, The reason for an Explorer crash is different on every user's PC. It may or may not be related to Classic Shell. You can help fix any crashes by capturing a dump like this: 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 did Classic Shell's testing and usability/UX feedback.

I have ver 4.30 and am experiencing this issue since upgrading to 4.30. I have win 10 pro on a home PC, and this has just started since the upgrade. I have had ClassicShell for years.

Symptoms: I will notice in my taskbar that certain office apps are not fully releasing when closed and within a few taskbar clicks, (TaskMan to try and EndTask the apps) The TaskBar and Start button become Non-responsive to all inputs. My resolution? Ctrl-Alt-Del, start TaskMan, and restart Windows Explorer task (cant end this one )

The reason for an Explorer crash is different on every user's PC. You can help fix any crashes by capturing a dump like this: 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 did Classic Shell's testing and usability/UX feedback.

I've uploaded a dump file earlier in the thread.

Here it is again:

https://drive.google.com/open?id=0B67oB ... jNJQ3h2M0U

I seem to have this problem when my laptop wakes from sleep. For now I've uninstalled Classic Shell, but man do I miss the features. I'm going to see if it happens with plain ol explorer.

Edit: Yep. Windows Shell itself works just fine. I'll try re-installing Classic Shell and collecting logs.

More and more people have been reporting this... :/

http://www.edugeek.net/forums/windows-1 ... ost1489015
http://www.edugeek.net/forums/windows-1 ... nding.html

@Ephelyon, can you capture a slowdown dump? 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 did Classic Shell's testing and usability/UX feedback.

Looks like the menu is trying to list the contents of the Start Menu folder, which is on a network share \\mhs_file01. The share may be busy or slow to respond.

That would not explain why Windows 7 clients (without Classic Start Menu) on the same network never experience this issue.

We've had another issue recently too. In this instance, the shell, taskbar and Start Menu continued to be unresponsive (and showing the busy cursor when highlighted) even after several restarts of both Explorer.exe and ClassicStartMenu.exe - the only solution was for the user to log off/on.

I managed to take dumps of both files while in this state, and they are here:

https://drive.google.com/open?id=0B67oB ... m50MXR3b3M

This doesn't appear to be related to Classic Shell. Explorer is stuck trying to show a tooltip for the taskbar.

Thanks, good to know.

Do you know of a way for me to find out these things myself from crash dumps, by the way, without bothering you about it?

My technical level: advanced sysadmin, but not programmer.

Okay, I'm now redirecting the Start Menu locally to test the networking side of things. I say locally, it now points to a \\127.0.0.1\Start_Menu share, which is hosted on each local workstation and we sync from the central Start Menu on startup. The reason it needs to be a share of some description and not a direct local path is because we require Access-Based Enumeration.

I've since experienced the same issue with the Taskbar / Start Menu hanging and never returning unless we kill and restart Explorer and I've taken a dump of it in that state which is here:

https://drive.google.com/open?id=0B67oB ... 05jZzliMGc

Does this look as if it's struggling to access \\127.0.0.1, as a previous dump showed with \\mhs_file01? I'd find that very strange as traffic to localhost should never leave the local machine... :/

This one looks different. Explorer has created a ton of COM threads for some reason. Other people have reported a similar issue in the past. But I don't know what is causing it or how to fix it.