Start Menu Debugging - Githubissues

Tray icons do not work on left click when using windows 11 taskbar. seems something had recently changed, as expected in build .258. If using windows 10 taskbar with windows 10 flyouts, clock and sound work will work. restoring the 2 files in the SystemResources folder fixes this, but breaks right click in start menu.

This should be avoidable by combining the decompiled code from both .pri files, the ones from build 21996.1 and the ones from the latest build.

If not otherwise, this could be technically solved by detecting how that file gets loaded at runtime (which API loads it and how), hooking early in the Start menu (a trick is to create a DLL with the same name as a system DLL from which a function gets invoked very early when StartMenuExperienceHost.exe starts executing, that being your entry point, placing the DLL in the Start menu folder and also creating and redirecting all the original DLL’s exports to the original DLL) and then intercepting the call that loads the file and redirecting it to the old one which makes it work fine.

A similar strategy could be achieved regarding the menu freezing the UI when closing, if you figure out what the file responsible for that is. Or, for that, as a “quick fix”, maybe detect a function that gets executed when the menu is dismissed, hook that function and simply do an “exit(0)”; the menu is automatically restarted anyway…

Also, the old menu could be enabled with newer files as well if you hook it early and redirect the “IsPPIEnabled” function (or the Win32 API call it makes in there to find the nature of the Windows install) to return 1. The old menu will then be loaded but with broken context menus and the closing delay bug.

Idk, just some ideas… What so you mean by decompiling the pri files, what output do you get from that?

Thanks

Sorry I never saw your comment, my bad!

I'm not really up to speed on creating my own dll's and hooking functions, got any good tutorials maybe?

I've been mostly using processmon to see what startmenuexperiencehost.exe had been interacting with, and viewing the stacks for a lot of events to try to figure out where the problems are. That's how I traced back to those 2 pri files. I never came across IsPPIEnabled, but that makes sense since I wasn't looking in a debugger. Is that function in startmenuexperiencehost.exe? I assumed there must be some special build for some type of embedded device that would retain the windows 10 menu, and figured it might be of help here, but I never saw any version check come up.

By using makepri.exe, you can use the dump function to decompile the pri files to xml, though this really is only good enough to compare what has changed between versions. It skips the embedded binary data, leaving just the resource names behind, but I find xml easier to look at and skim through. It was of moderate help in finding that the pri files from build .51, rather than the leaked build, solves the right click crash and tray icons issue.

However the main issue still stands, which is the delay on exit. I'm still not sure yet what exactly is causing the brief lockup, but I believe its due to a buffer that is being over run and causing a fast fail exception. I was going to attempt to patch the exe directly if I can find what's calling the exception, but I haven't gotten that far yet. Not a very clean approach, but may do the trick for testing purposes. Of course, your solution sounds like a much better option. I'll have to learn to hook functions... that said, if you wanted to, say, implement it in the meantime while I learn this... nahh don't mind me, I'm sure you're already staying up 40 hours a day ;)

After that its just pin/unpin that's still slightly bugged but still works, and no easy toggle for those who want full screen start (Group policy still works). Otherwise at this point, its fully functional in build .318

cheers :)

Attach with WinDbg to StartMenuExperienceHost.exe and see if it spits out anything when the menu closes. Maybe that will help you see what causes that, trace it back to some area in the disassembly. Then, of course, patching something there is advisable.

Of course, runtime patches are preferable, hooking is one of the methods to do that. There are multiple methods to install, even Windows officially provides some (like SetWindowsHookEx), or via IAT patching, or directly hooking whatever function you are interested into by installing a trampoline. There are helper libraries for this as well, I usually use funchook or Microsoft Detours. Check ExplorerPatcher's source code.

What is the minimal set of files required to fix the menu? Like, with StartMenuExperienceHost.exe from 22000.51, you can have it open on 22000.318 as well as that basically replaces the check for IsPPIEnabled with a check for Start_ShowClassicMode. Then, one's of course left with the 2 problems: right click and delay at closing. So, what's the bare minimum of files required for right click to work again? Mixing the pris you said might work? Can you elaborate a strategy on that, something that is as less invasive as possible. As it currently stands, the repository contains too big of a list of files to replace, so it's very hard to maintain. And are those replacements all really necessary? Here's the call stack after a crash happens when right clicking (reproduce this by attaching with WinDbg to the process):

[0x0]   KERNELBASE!RaiseFailFastException + 0x152   
[0x1]   combase!RoFailFastWithErrorContextInternal2 + 0x4d9   
[0x2]   Windows_UI_Xaml!DirectUI::ErrorHelper::ProcessUnhandledError + 0xf4   
[0x3]   Windows_UI_Xaml!DirectUI::FinalUnhandledErrorDetectedRegistration::OnFinalUnhandledErrorDetected + 0xbc   
[0x4]   Windows_UI_Xaml!Microsoft::WRL::Callback::__l2::<lambda_fa46ac39691f4ca87fe78d9a3f2f4de1>::operator() + 0x1d   
[0x5]   Windows_UI_Xaml!Microsoft::WRL::Details::DelegateArgTraits<long (__cdecl Windows::Foundation::IEventHandler_impl<Windows::Foundation::Internal::AggregateType<Windows::ApplicationModel::Core::UnhandledErrorDetectedEventArgs *,Windows::ApplicationModel::Core::IUnhandledErrorDetectedEventArgs *> >::*)(IInspectable *,Windows::ApplicationModel::Core::IUnhandledErrorDetectedEventArgs *)>::DelegateInvokeHelper<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<2>,Windows::Foundation::IEventHandler<Windows::ApplicationModel::Core::UnhandledErrorDetectedEventArgs *>,Microsoft::WRL::FtmBase>,<lambda_fa46ac39691f4ca87fe78d9a3f2f4de1>,-1,IInspectable *,Windows::ApplicationModel::Core::IUnhandledErrorDetectedEventArgs *>::Invoke + 0x23   
[0x6]   twinapi_appcore!Windows::Internal::Details::GitInvokeHelper<Windows::Foundation::IEventHandler<Windows::ApplicationModel::Core::UnhandledErrorDetectedEventArgs * __ptr64>,Windows::Internal::GitPtr,2>::Invoke + 0x64   
[0x7]   twinapi_appcore!Windows::ApplicationModel::Core::UnhandledErrorInvokeHelper::Invoke + 0x24   
[0x8]   twinapi_appcore!Microsoft::WRL::InvokeTraits<2>::InvokeDelegates<<lambda_e478ebca019219710ec18bdfd8216607>,Windows::Foundation::IEventHandler<Windows::ApplicationModel::Core::UnhandledErrorDetectedEventArgs * __ptr64> > + 0x62   
[0x9]   twinapi_appcore!Microsoft::WRL::EventSource<Windows::Foundation::IEventHandler<Windows::ApplicationModel::Core::UnhandledErrorDetectedEventArgs * __ptr64>,Microsoft::WRL::InvokeModeOptions<2> >::DoInvoke<<lambda_e478ebca019219710ec18bdfd8216607> > + 0x78   
[0xa]   twinapi_appcore!Microsoft::WRL::EventSource<Windows::Foundation::IEventHandler<Windows::ApplicationModel::Core::UnhandledErrorDetectedEventArgs * __ptr64>,Microsoft::WRL::InvokeModeOptions<2> >::InvokeAll<std::nullptr_t,Windows::ApplicationModel::Core::UnhandledErrorDetectedEventArgs * __ptr64> + 0x29   
[0xb]   twinapi_appcore!Windows::ApplicationModel::Core::CoreApplication::ForwardLocalError + 0x79   
[0xc]   twinapi_appcore!Windows::ApplicationModel::Core::CoreApplicationFactory::ForwardLocalError + 0x77   
[0xd]   combase!CallErrorForwarder + 0x150   
[0xe]   Windows_UI!Windows::UI::Core::CCoreAsyncBase<Windows::Foundation::IAsyncAction,Windows::Foundation::IAsyncActionCompletedHandler,&Windows::UI::Core::AsyncActionName,&Windows::UI::Core::CoreAsyncActionName>::`scalar deleting destructor' + 0x393cf   
[0xf]   Windows_UI!Windows::UI::Core::CCoreAsyncBase<Windows::Foundation::IAsyncAction,Windows::Foundation::IAsyncActionCompletedHandler,&Windows::UI::Core::AsyncActionName,&Windows::UI::Core::CoreAsyncActionName>::Release + 0x69   
[0x10]   Windows_UI!Windows::UI::Core::CDispatcher::ProcessInvokeItem + 0x29a   
[0x11]   Windows_UI!Windows::UI::Core::CDispatcher::ProcessMessage + 0x211   
[0x12]   Windows_UI!Windows::UI::Core::CDispatcher::WaitAndProcessMessagesInternal + 0xc0   
[0x13]   Windows_UI!Windows::UI::Core::CDispatcher::ProcessEvents + 0x7b   
[0x14]   Windows_UI_Xaml!CJupiterWindow::RunCoreWindowMessageLoop + 0x60

There seems to be some problem in Windows.UI.dll (frame 0xe)...? I don't understand how they can break their own ABI so much between builds, compared to when things were done classically, using Win32 APIs, that were always stable and produced executables that are immortal basically, but that's today's software quality, I guess...

By the way, in newer Windows 11 builds, they seem to be preparing this registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Control Center with a DWORD called UseLiteLayout set to 1 to have the UI run in a legacy mode where some Windows 10 components show by default, like the old network flyout, old Action Center etc (this works at least for some things hosted by ShellExperienceHost.exe).

I appreciate the super quick reply, I know you're very busy

That makes sense, using the .51 build of startmenuexperiencehost.exe without the show_ClassicStartMode entry, the windows 10 menu doesn't work.

Windbg indeed does spit something out, but on launch, not on exit. If I attach to process, I get an error in dcomp.dll. onecoreuap\windows\dwm\dcomp\dll\kerneltokenfactory.cpp(36)\dcomp.dll!00007FFD601B6E70: (caller: 00007FFD60149E7F) ReturnHr(3) tid(247c) 887A0004 The specified device interface or feature level is not supported on this system. onecoreuap\windows\dwm\dcomp\dynamicpoolset.cpp(43)\dcomp.dll!00007FFD60147BF5: (caller: 00007FFD60169E31) ReturnHr(4) tid(247c) 887A0004 The specified device interface or feature level is not supported on this system.

If I launch app package, I get a similar but not identical windows.ui.dll error to the one you're getting. I'm sure the difference in output is due to us not having the same set of file versions.

If I !analyze, I see the last thing that happens before the crash is
StartUI!StartUI::App::GetFrameType+0x523

From my limited knowledge, it seems to me that maybe startui is failing during handoff to dwm to compose the exit animation?I'm not really sure, I've never really used windbg or any debugger really, just learning now.

Besides the startmenuexperiencehost.exe and the other files in that location, the other files needed are:

JumpViewUi.dll in C:\Windows\ShellExperiences\
The 2 pri files in C:\Windows\SystemResorces\Windows.UI.Shellcommon
Appresolver.dll in System32 (fixes pin/unpin to start from outside the start menu)

Since I was initially replacing dll's almost blindly, I was swapping out whole folders at a time to see how it affected behavior, so yes not all the files I had uploaded a few weeks ago are actually required, and probably change nothing. I narrowed it down to the files above after some trial and error. Not the best approach I know. I unfortunately didn't have a lot of time to read up due to various bs family related things going on surrounding the pandemic.

All the files in my repository are from build .51. Switching over from the files from build 21996.1 fixed all issues except the closing delay, and the pin/unpin to start option within the start menu. There should no longer be a need to combine sets of pri files, thankfully. yay.

interestingly, I don't have that Registry Key at all, although I do have it on my windows 10 build. Huh. I had the old action center flyout by again replacing shellexperiencehost.exe and some related dll's in that folder. It too had the same exact issue as the start menu on exit.

By the way, thanks for the insight, and I have been looking through both your source code and your detailed posts. Very informative for someone like me!

thanks again!

Interesting, yeah, the exit delay thing is very weird indeed, as it doesn’t crash there at all, it just does that. Maybe it waits for some reply it never gets, and after some time it times out and is closed anyway. The architecture is incredibly complicated for a fucking menu. Simple old things from 20-30 years ago work today just fine, while this breaks in the first few builds where it’s not a default. Same with the network flyout, battery flyout etc.

Anyway, thanks as well and keep investigating this, maybe you find something. Then, we can narrow it down and polish those areas and maybe one day all the issues will be figured out. Thank you.

@bbmaster123 I have taken a shot at this and was able to fix it so that it works fine on regular (22000-based) Windows 11 builds. I still haven't pinpointed what causes the closing delay, for example, but I have successfully worked around that. The implementation lives in ExplorerPatcher, pre-release 22000.493.42.18 and up. More details here.

Thank you very much for the pointers from this repo, it narrowed the scope quite a bit, knowing what goes where and what is needed to pull it off.

bbmaster123 / 10SM

Start Menu Debugging #3