Classic Shell: Forum

This isn't very easy to describe, but here goes. In comparison with Windows 8.x, when I press the Start button right after the startup sequence (boot-up) is complete and the PC is ready for use, Classic Start Menu is slow to react. The button will look "pressed" for 5-10 seconds and then the menu will appear. Hard disk activity is normal and not excessive at that point. When the menu appears for the first time, it'll work fine after that. It also works fine if I wait longer after the PC starts before pressing the start button.

It's a new Windows 10 installation, with very few programs and startup items installed and I'm fairly sure I do not press the start button too early (same way I was using it with Win 8, anyway). Not referring to this now solved issue.

Maybe Windows 10 is indeed slower to boot, requires more stuff to load in the background and will only "allow" the Classic Start Menu to start a bit later after the Desktop is presented and available to the user? (using 4.2.4, Classic with two columns)

_________________
Windows 10 Pro x64

Well for quite a number of Windows releases now (starting with Vista, with the exception of Windows 7), Microsoft has been delaying or slowing down the speed at which programs load at startup.

_________________
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 am seeing the same problem/event (slow start of Classic Shell). In my case very slow. CS takes approx 1 minute to load after desktop first appears.
In 8.1 CS was available immediately or close to. As a comparison Stardock's Start 10 is available immediately as, of course, is W10's start.

Is there a fix for this or one in the making or do we have to just accept it?
In my opinion Classis Shell is by far the best 'Start' available but this slow load is annoying.

Upgraded to W10 from W8.1. Using Classic Shell Ver 4.2.4

Thanks to everybody for your great work

TraxJax

If your hardware is slower, Windows 10 can be slower to boot. But it should definitely not take 1 minute for Classic Shell to load. Make sure that the folder %localappdata%\ClassicShell is writable and has no permissions issues. It should have a file called DataCache.db where some data like icons and frequent program data is cached so the menu will load faster. You could try deleting it or delete the %localappdata%\ClassicShell folder itself, and log out and log in again. After this, the first startup will be slow as the Datacache.db file is rebuilt but subsequent startups of the Start Menu should be faster.

If the menu is simply being launched late in the boot cycle, create a shortcut to C:\Program Files\Classic Shell\ClassicStartMenu.exe and paste it in your Startup folder at C:\Users\<your user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.

Make sure no other Start Menu replacements are installed along with Classic Shell or you can get problems.

If your startup is still slow, follow these steps:
1. Open Regedit and go to HKCU\Software\IvoSoft\ClassicStartMenu\Settings
2. Create a new DWORD value named LogStartup
3. Restart and log in
4. Go to the folder %LOCALAPPDATA%\ClassicShell and look for a file named StartupLog.txt
5. Attach it here

_________________
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.

Thanks for the reply Gaurav.
"Make sure that the folder %localappdata%\ClassicShell is writable and has no permissions issues"
Full permission
"delete the %localappdata%\ClassicShell folder itself, and log out and log in again."
Did this and then CS loads fast/immediately BUT after restart/shutdown CS again takes about 1 minute to load.
"create a shortcut to C:\Program Files\Classic Shell\ClassicStartMenu.exe and paste it in your Startup folder "
Did this and it makes no difference.
"Create a new DWORD value named LogStartup" - "Restart and log in"
Did this but after restart/shutdown there is no 'StartupLog.txt' in %APPDATA%\ClassicShell
Tried DWORD value of 1 and 0. Searched all of C: but no Startuplog.txt file.


I only have one start program running at any time and as previously stated CS was/is fine in W8.1 (I still run 8.1 as well)


Running Windows 10 Pro


Thanks

The log should be in %LOCALAPPDATA%\ClassicShell after setting it to 1 and restarting.

_________________
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.

From my personal experience, the Windows 10 boot-up is quicker than 8.x to show the desktop screen, but it takes longer than 8.x before the user can actually start opening programs and using the PC. It kind of "cheats" a feeling of being faster than 8.x, but it actually isn't it - pretty much the same.

As a general suggestion, I'd recommend the use of the excellent Startup Delayer, especially if you have several startup entries. You can greatly customize, speed-up and improve your startup-sequence, for example make Classic Shell start first while delaying the less important stuff.

_________________
Windows 10 Pro x64

Guarav
Here is the .txt file. My bad I created the DWORD in HKCU\Software\IvoSoft\ClassicStartMenu instead of HKCU\Software\IvoSoft\ClassicStartMenu\Settings
Just timed CS start time more accurately and it was 70 secs. BTW CS is fine, as would be expected, with hibernate.




MenuPeak
I will check out Startup Delayer if we can't get this sorted.


Thanks

The startup log looks OK.

Let's try to determine if this is a Windows startup problem or a start menu startup problem. Turn off the setting "Start automatically for this user" from the General Behavior tab in the settings. Then restart - the menu shouldn't load. Wait 5 minutes and start ClassicStartMenu.exe and see if the menu takes long time or not.

If it loads quickly then the problem is that it competes with other programs during startup.

If it loads slowly, then restart again, and use the technique here: viewtopic.php?f=12&t=6 to capture series of dumps while the menu is starting up.

"Wait 5 minutes and start ClassicStartMenu.exe and see if the menu takes long time or not"
Now here is something strange. After waiting 5 minutes and starting Classic Shell it starts immediately and I can run/start progs from within the start menu BUT then on an immediate second attempt to open 'Start' once again it takes approximately 60/70 secs to load. After that it's fine.

Haven't done the dumps yet as above may alter your suggestions.

Thanks

Are you sure there's no security software interfering with CS? If you have antivirus/firewall software installed, I'd try disabling them completely first, add exceptions for Classic Start Menu and even try completely uninstalling it, for testing purposes.

_________________
Windows 10 Pro x64

Ivo



Attached is the dump file (rar). I ran about 12 dumps but this doesn’t covers the time taken for Classic Shell to load on the *second* attempt – see below.

“procdump -n 12 -s 1 explorer.exe”

Windows 10 was fully loaded when dump was taken. CS took about 40 seconds to load but it normally is 60/70 secs.

As stated earlier the 60/70 load is the same for ‘auto load’.



For the dump I manually started CS and as previously written it loads fine (or appears to) on this *first* use and programs can be loaded/run from the menu. However on the *second* attempt (dump taken then) CS took about 40/50 secs to be usable.



Also please note no other program *pined to the taskbar* can be started during this CS load period. Also, and I don’t know if this means anything, the CS start icon ‘slips’ behind the taskbar during this load period if you click on it.



MenuPeak

The first thing I did was to completely uninstall/install Classic Shell 4.2.4. Also shutdown Firewall/Malware progs.

Doing that changed nothing.



Remember Guys this only became a problem when I upgraded from W8.1 pro to W10 pro. Everything was/is fine in 8.1. No other programs have been installed in W10 and as far as I can tell at this stage everything else is ok.

Thanks

Sorry Dump file is too big. Max allowed is 5Mb. This rar is 11.4 Mb.(12 dumps)
Here is 5 dumps if that helps.

You can drop the file here: http://www.mediafire.com/filedrop/filed ... ca5151aa1d

Ok have uploaded file to mediafire
DMP_70.rar

It appears stuck trying to load the icon for this program: c:\program files (x86)\avs4you\avsvideoconverter\avsvideoconverter.exe
I don't know why. Open that folder in Explorer right after you reboot and see if the EXE icon shows up right away or after a while. Maybe you have a bad sector or something on your disk and it takes many retries to read it.
Another possibility is AV software blocking or delaying access to that program for some reason, causing Explorer to retry.

Have completely uninstalled avs4you. Makes no difference.
As mentioned AV software is switched off as is Firewall.
No bad sectors. Has been checked.

Any more ideas? Seems it involves W10 and/or CS in W10.

Thanks

The few dumps I examined are few seconds apart and look for different icons inside the avs4you folder. A single folder should not take much time at all.

Icons are normally cached in the file %LOCALAPPDATA%\ClassicShell\DataCache.db, so even if they are slow they won't be loaded more than once. Check if that file exists and has a recent timestamp.

I have the same problem, the menu takes a very long time to show in Windows 10, almost 30 seconds. The fix that I found was to disable "Pre-cache icons" and "Delay loading of icons", now the menu shows much faster but the searches take longer. To be true Classic Shell is a must have for Windows 8.1 and below and Server 2012, but if Microsoft fixes a few bugs with their start menu (mainly the hardcoded 512 start menu items), I'll probably use the standard one, it does what I need. Nothing to take off from Classic Shell anyway, it has always been and still is an outstanding program.

Just as a suggestion (maybe it's a stupid thing), why don't just scrape the icons and content in a separate thread with low priority (possibly as an additional option).