Classic Shell: Forum

Win 10 build 10240, updated.

This seems to have grown in probability since I first reported it against the beta. It happens a lot now. I can pretty much count on a few second delay if I haven't clicked on the Start button recently. It will always pop open instantly on another second click done shortly thereafter. It seems almost like a "times out and spins down" kind of thing - though I don't think "spin down" of disks can be directly accurate/applicable insofar as my Win 10 test system is a VMware VM backed by only SSD storage.

Very specifically:

1. I move my mouse to the TOP of the screen (I've moved my Taskbar up there) and the Taskbar unhides (I prefer to keep it hidden).

2. I slide my mouse to the left and click on the Start button. Usually that means a Taskbar Live Preview thumbnail of the old Win NT CLOCK32.EXE application will show, as it starts on logon and is the leftmost running application.

3. I wait somewhere between 2 and 3 seconds when nothing happens. I can type, as though into the search box, and it will show in the search box once the Classic View menu opens.

4. The Start menu finally appears. If I've done any typing, it appears in the Search box.

I provided some data during the beta to try to isolate the issue, and I'm posting here mainly to ask if others who might see this would note "me too" if you're also seeing delays after clicking the Start button.

FYI, I have the same version of Classic Shell installed on my Win 8.1 x64 Pro/MCE host system and I do not see a delay there.

No doubt it's something I've configured / reconfigured / deconfigured on my Win 10 system - and which Classic Shell doesn't expect - that's causing it. I welcome suggestions on how to isolate this delay further.

Could this be happening because Explorer.exe is blocked from making all network connections by the firewall?

-Noel

If the delay is more than a second, you can use procdmp to capture a series of dumps that will show the problem.

I've used a lot of debugging aids, but procdmp is new to me. Do you have a link?

EDIT: Never mind - I see: viewtopic.php?f=12&t=6

-Noel

Can you save and attach your Classic Start Menu settings XML on Windows 10? The delay could be happening only with some specific settings.

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

Sorry I haven't had time to do a series of dumps so far. I had 5 minutes but failed to

Here's a copy of my Win 10 settings:
http://Noel.ProDigitalSoftware.com/temp ... ttings.zip

This really is feeling like some kind of "virtual drive spin-down", since it's NEVER reproducible a second time right away, and it always seems to catch me when I've returned to the VM to do something after leaving it alone for a while. However I've just checked the power plan settings for the Nth time and the settings are properly at "Never spin down".

I need to leave a command window set up to capture the dumps to remind me to run it when I come back to the VM.

-Noel

OK, that strategy worked. I thought to start the dump sequencing process before clicking the Start button, and sure enough caught a delay.

I believe I clicked the Start button around the time of dump 1 being created and the menu opened around the time of dump 3.

Here's the lot of them: http://Noel.ProDigitalSoftware.com/temp ... e_dmps.zip

This is from an up-to-date 10240 build. Let me know if I can provide anything more.

-Noel

At the time of the second dump it was trying to resolve the location of your Pictures folder. And so Windows goes on to read your profile from disk.
I don't know if that's the cause of the slowdown. It may just happen to be what was in progress while the dump was taken.
But see if there is something funky going on with the Pictures folder on your end.

The Pictures folder itself is intact, though I have hidden it from display under "This PC" in the Navigation pane by tweaking the registry (I can look up the specifics if you'd like; I don't remember them off the top of my head - I think it was a matter of setting an IsPinnedToNamespaceTree value to 0).

A fundamental question is, though... Why does ClassicShell try to resolve the location of Pictures? I don't have that showing in any menus.

-Noel

It resolves the few special folders in advance in case they are needed. And it is not clear from the start if they are needed. Some folders require special case handling, so even if you add it manually by path the special behavior must be used. However I don't know it is a special folder unless I know the path of that special folder.

I coded up a little app (with help from the good folks at StackOverflow) to dump out the status of the drive. It shows the one and only virtual drive - C: - is powered-up the whole time. So it's not some kind of virtual power-down state.

// DrivePowerStateCheck.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
for (int DriveNumber = 0; DriveNumber < 128; ++DriveNumber) {
TCHAR Drive[128];
_stprintf(Drive, _T("\\\\.\\PHYSICALDRIVE%d"), DriveNumber);
HANDLE hDevice = CreateFile(Drive, 0, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);
if (hDevice != INVALID_HANDLE_VALUE) {
BOOL DeviceIsOn = FALSE;
if (GetDevicePowerState(hDevice, &DeviceIsOn) != 0) {
_tprintf(_T("Physical Drive %d is Powered %s (DeviceIsOn=%d)\n"), DriveNumber, DeviceIsOn ? _T("On") : _T("Off"), (int) DeviceIsOn);
}
CloseHandle(hDevice);
}
}

return 0;
}


I guess I can go through resurrecting a virgin installation, and add all my tweaks and augments in methodically, all the while testing for the recurrence of this problem (assuming it doesn't happen in the virgin Win 10 setup).

Would capturing another sequence of logs help you?

-Noel

I don't think this has anything to do with spinning down. Simply the information is cached in RAM, and if it is not used for some time it is purged. So next time it is slow.

A few more successful dumps will help confirm if this problem is indeed related to the Pictures folder or that was just a random sample.

No, this system is too fast for there to be a 3 second delay in doing anything. The VM has 16 virtual processors and runs from an SSD array. Plus the problem occurs after leaving it alone for a while. Nothing is causing the cache to flush.

Here's another sequence of dumps. I believe either the 2nd or 3rd one will show Explorer waiting on whatever is causing the delay.

http://Noel.ProDigitalSoftware.com/temp ... xe_dmp.zip

-Noel

Yes, same thing - it is trying to resolve the Pictures folder. Here's the callstack:
ntdll.dll!NtCreateFile
KERNELBASE.dll!CreateFileInternal
KERNELBASE.dll!CreateFileW
windows.storage.dll!CCachedINIFile::Load
windows.storage.dll!CPrivateProfileCache::_AddNewINIFromFile
windows.storage.dll!CPrivateProfile::Initialize

Appears it tries to load some INI file from disk and that is taking a long time. I don't have the exact name of that file because this is a minidump and it doesn't include that piece of memory. Possibly the INI file has some expiration date, like 5 minutes. So after that time it has to be loaded again.

You may try Process Monitor to catch which exact file is being read and then try to determine why it is being slow.

Hm, I have been trying all day to capture the problem in ProcMon and it's not been cooperating.

After your second confirmation that the problem might somehow be related to my Pictures folder, I went looking there (I don't normally use that, AT ALL).

There were 3 subfolders, and within one of them was a small file: C:\Users\NoelC\Pictures\Screenshots\Screenshot (1).png

Since I don't use that folder and can't imagine how that file got there, I opened it up with Irfan View. It was all black. It opened immediately, but then I figured since I didn't create it (on purpose) and had no use for it maybe I ought to just get rid of it, so I moved it to my TEMP folder. It's just a 160 x 23 pixel black image, in a file that's 176 bytes long.

Since then I haven't seen one slow startup of the Classic Shell start menu, but I am only cautiously optimistic since I also was running ProcMon in every case and that of course changes the timing of everything.

I'm going to try some more today WITHOUT ProcMon and see whether the problem comes back.

-Noel

I don't think the contents of the Pictures folder matter. The menu is just trying to find the path for the folder and is reading your profile from disk where all such paths are stored.

Saw one delay just now. I did not set up any special monitoring and just clicked the Start button on an otherwise quiet system to shut it down.

This time I caught Classic Shell failing to access 184.167.173.1 port 80 (Explorer tried to access www.ClassicShell.net, presumably to check for updates, was blocked by my Firewall; I need to set up a specific exception for that).

This was the first time I saw a delay today, and the delay seemed shorter than usual.

-Noel

FINALLY! FOUND IT! ProcMon finally showed it clearly.

It wasn't Pictures, it was Favorites.

A long time ago I experimented by making the Favorites folder under my username on my VM into a reparse point using MKLINK /D, so that it would point to my host system's Favorites folder. I'd forgotten to undo that experiment, because frankly it worked perfectly (same account name/password on both systems).

For whatever reason occasionally the networking connection between the guest VM and host system takes noticeable time to re-establish.

I'm sorry to have wasted your time with this!

-Noel