An attempt to fix infinite explorer crashing issue with dynamic taskbar creation check #268

mclt0568 · 2026-01-07T11:54:18Z

Instead of relying on timeout (1000ms) to wait for taskbar to become stable (which in many case stabilisation takes more than a second), now relies MainWindow.ExplorerRestarting as a flag to determine if taskbar is stable

The ExplorerRestarting flag is flipped to true when WM_TASKBARCREATED is received, then flipped back to false when WaitForExplorerReadyAsync() returns, indicating its ready.

WaitForExplorerReadyAsync() works by probing taskbar every 200ms, checking if window exists (FindWindow()) and has a valid geometry. This happens until taskbar is ready or timed out (defaulted to 8000ms).

Copilot

Pull request overview

This PR attempts to fix infinite Explorer crashing issues by replacing a timeout-based approach with a dynamic taskbar readiness detection mechanism. Instead of waiting a fixed 1000ms for the taskbar to stabilize, the code now uses a MainWindow.ExplorerRestarting flag that is set when WM_TASKBARCREATED is received and cleared when the taskbar is confirmed ready.

Key Changes:

Introduces ExplorerRestarting volatile flag to coordinate taskbar recovery across threads
Implements WaitForExplorerReadyAsync() to probe taskbar readiness every 200ms with an 8-second timeout
Refactors WndProc message handler to defer tray icon recreation until Explorer stabilizes
Simplifies error recovery logic in TaskbarWindow.UpdatePosition()

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 14 comments.

File	Description
FluentFlyoutWPF/MainWindow.xaml.cs	Adds explorer restart detection logic with `ExplorerRestarting` flag, implements async probing for taskbar readiness, and refactors tray icon recreation to use safer deferred approach
FluentFlyoutWPF/Windows/TaskbarWindow.xaml.cs	Makes Win32 API methods public for cross-class access, adds early return in `UpdatePosition()` when explorer is restarting, and simplifies recovery logic by removing retry attempt tracking

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-07T12:16:49Z

FluentFlyoutWPF/MainWindow.xaml.cs


    private TaskbarWindow? taskbarWindow;

+    internal static volatile bool ExplorerRestarting = false;


The volatile keyword alone does not guarantee thread-safety for flag operations that involve reading and writing. While volatile ensures visibility of changes across threads, it doesn't provide atomicity for read-modify-write operations. If ExplorerRestarting is checked and then set in a non-atomic way, race conditions could still occur. Consider using Interlocked operations (e.g., Interlocked.Exchange) or a lock to ensure proper synchronization, especially since this flag is being used to coordinate critical operations across multiple threads (UI thread in WndProc and background tasks in UpdatePosition).

Copilot · 2026-01-07T12:16:50Z

FluentFlyoutWPF/MainWindow.xaml.cs

+                    else
+                    {
+                        Logger.Warn("Explorer did not stabilize within timeout; keeping integration disabled");
+                    }


The ExplorerRestarting flag is never reset to false when WaitForExplorerReadyAsync() times out (returns false). This means if Explorer fails to stabilize within 8 seconds, the flag remains true indefinitely, permanently disabling taskbar integration until the application is restarted. The flag should be reset even in the timeout case to allow recovery attempts.

Copilot · 2026-01-07T12:16:50Z

FluentFlyoutWPF/MainWindow.xaml.cs

+    //private nint WndProc(nint hwnd, int msg, nint wParam, nint lParam, ref bool handled)
+    //{
+    //    // Listen for TaskbarCreated message (when explorer.exe restarts)
+    //    if (msg == WM_TASKBARCREATED)
+    //    {
+    //        //Logger.Info("TaskbarCreated message received - recreating tray icon");
+    //        //nIcon.Visibility = Visibility.Collapsed; // remove tray icon
+
+    //        //if (SettingsManager.Current.NIconHide)
+    //        //    return 0;
+
+    //        //nIcon.Visibility = Visibility.Visible; // re-add tray icon
+    //        //nIcon.Register();
+    //        Logger.Debug("Restarted without tray icon stuff cus its buggy asf");
+    //    }
+    //    return 0;
+    //}


Large block of commented-out code (30+ lines) should be removed rather than left in the codebase. Commented code creates maintenance burden and confusion. If this recovery logic needs to be preserved for reference, it should be documented in version control history or in a design document.

Suggested change

//private nint WndProc(nint hwnd, int msg, nint wParam, nint lParam, ref bool handled)

//{

// // Listen for TaskbarCreated message (when explorer.exe restarts)

// if (msg == WM_TASKBARCREATED)

// {

// //Logger.Info("TaskbarCreated message received - recreating tray icon");

// //nIcon.Visibility = Visibility.Collapsed; // remove tray icon

// //if (SettingsManager.Current.NIconHide)

// // return 0;

// //nIcon.Visibility = Visibility.Visible; // re-add tray icon

// //nIcon.Register();

// Logger.Debug("Restarted without tray icon stuff cus its buggy asf");

// }

// return 0;

//}

Copilot · 2026-01-07T12:16:50Z

FluentFlyoutWPF/Windows/TaskbarWindow.xaml.cs

+            //    Logger.Warn("Taskbar Widget window handle is zero, attempting recovery...");
+
+            //    Dispatcher.BeginInvoke(async () =>
+            //    {
+            //        await Task.Delay(1000); // delay before recovery to let taskbar stabilize
+            //        try
+            //        {
+            //            _mainWindow?.RecreateTaskbarWindow();
+            //        }
+            //        catch (Exception ex)
+            //        {
+            //            Logger.Error(ex, "Failed to signal MainWindow to recover Taskbar Widget window");
+            //            _recoveryAttempts++;
+            //        }
+            //    }, DispatcherPriority.Background);
+
+            //    return;
+            //}


Large block of commented-out code (28 lines) should be removed. The new implementation at lines 435-451 replaces this logic, so the old code serves no purpose and reduces code clarity.

Suggested change

// Logger.Warn("Taskbar Widget window handle is zero, attempting recovery...");

// Dispatcher.BeginInvoke(async () =>

// {

// await Task.Delay(1000); // delay before recovery to let taskbar stabilize

// try

// {

// _mainWindow?.RecreateTaskbarWindow();

// }

// catch (Exception ex)

// {

// Logger.Error(ex, "Failed to signal MainWindow to recover Taskbar Widget window");

// _recoveryAttempts++;

// }

// }, DispatcherPriority.Background);

// return;

//}

Copilot · 2026-01-07T12:16:51Z

FluentFlyoutWPF/Windows/TaskbarWindow.xaml.cs

-                        Logger.Error(ex, "Failed to signal MainWindow to recover Taskbar Widget window");
-                        _recoveryAttempts++;
-                    }
+                    _mainWindow?.RecreateTaskbarWindow();


The simplified recovery logic no longer includes error handling or recovery attempt tracking. The previous implementation had a try-catch block to handle exceptions during RecreateTaskbarWindow and tracked recovery attempts to prevent infinite loops. Without these safeguards, if RecreateTaskbarWindow() throws an exception, it could lead to unhandled exceptions in the dispatcher queue. Consider adding error handling around the RecreateTaskbarWindow call.

Suggested change

_mainWindow?.RecreateTaskbarWindow();

try

{

_mainWindow?.RecreateTaskbarWindow();

}

catch (System.Exception ex)

{

Logger.Error(ex, "Failed to recover Taskbar Widget window");

}

Copilot · 2026-01-07T12:16:52Z

FluentFlyoutWPF/MainWindow.xaml.cs

+            IntPtr taskbar = TaskbarWindow.FindWindow("Shell_TrayWnd", null);
+            if (taskbar != IntPtr.Zero)
+            {
+                if (TaskbarWindow.GetWindowRect(taskbar, out TaskbarWindow.RECT rect))


Replace this call with a call to managed code if possible.

Copilot · 2026-01-07T12:16:52Z

FluentFlyoutWPF/Windows/TaskbarWindow.xaml.cs

    // --- Win32 APIs ---
    [DllImport("user32.dll", SetLastError = true)]
-    private static extern IntPtr FindWindow(string lpClassName, string? lpWindowName);
+    public static extern IntPtr FindWindow(string lpClassName, string? lpWindowName);


Minimise the use of unmanaged code.

Copilot · 2026-01-07T12:16:52Z

FluentFlyoutWPF/Windows/TaskbarWindow.xaml.cs

+    public static extern bool GetWindowRect(IntPtr hWnd, out RECT lpRect);



Minimise the use of unmanaged code.

Suggested change

public static extern bool GetWindowRect(IntPtr hWnd, out RECT lpRect);

private static extern bool GetWindowRectNative(IntPtr hWnd, out RECT lpRect);

/// <summary>

/// Safely retrieves the bounding rectangle of the specified window as a managed <see cref="Rect"/>.

/// </summary>

/// <param name="hWnd">Handle to the window.</param>

/// <param name="rect">On success, receives the window rectangle.</param>

/// <returns><c>true</c> if the rectangle was retrieved successfully; otherwise, <c>false</c>.</returns>

public static bool TryGetWindowRect(IntPtr hWnd, out Rect rect)

{

rect = Rect.Empty;

if (hWnd == IntPtr.Zero)

return false;

if (!GetWindowRectNative(hWnd, out RECT nativeRect))

return false;

var width = nativeRect.Right - nativeRect.Left;

var height = nativeRect.Bottom - nativeRect.Top;

rect = new Rect(nativeRect.Left, nativeRect.Top, width, height);

return true;

}

Copilot · 2026-01-07T12:16:53Z

FluentFlyoutWPF/MainWindow.xaml.cs

+            if (taskbar != IntPtr.Zero)
+            {
+                if (TaskbarWindow.GetWindowRect(taskbar, out TaskbarWindow.RECT rect))
+                {
+                    if (rect.Right > rect.Left && rect.Bottom > rect.Top)
+                    {
+                        return true; // taskbar exists and has geometry
+                    }
+                }


These 'if' statements can be combined.

Suggested change

if (taskbar != IntPtr.Zero)

{

if (TaskbarWindow.GetWindowRect(taskbar, out TaskbarWindow.RECT rect))

{

if (rect.Right > rect.Left && rect.Bottom > rect.Top)

{

return true; // taskbar exists and has geometry

}

}

if (taskbar != IntPtr.Zero

&& TaskbarWindow.GetWindowRect(taskbar, out TaskbarWindow.RECT rect)

&& rect.Right > rect.Left

&& rect.Bottom > rect.Top)

{

return true; // taskbar exists and has geometry

Copilot · 2026-01-07T12:16:53Z

FluentFlyoutWPF/MainWindow.xaml.cs

+            if (taskbar != IntPtr.Zero)
+            {
+                if (TaskbarWindow.GetWindowRect(taskbar, out TaskbarWindow.RECT rect))
+                {
+                    if (rect.Right > rect.Left && rect.Bottom > rect.Top)
+                    {
+                        return true; // taskbar exists and has geometry
+                    }
+                }


These 'if' statements can be combined.

Suggested change

if (taskbar != IntPtr.Zero)

{

if (TaskbarWindow.GetWindowRect(taskbar, out TaskbarWindow.RECT rect))

{

if (rect.Right > rect.Left && rect.Bottom > rect.Top)

{

return true; // taskbar exists and has geometry

}

}

if (taskbar != IntPtr.Zero &&

TaskbarWindow.GetWindowRect(taskbar, out TaskbarWindow.RECT rect) &&

rect.Right > rect.Left &&

rect.Bottom > rect.Top)

{

return true; // taskbar exists and has geometry

mclt0568 · 2026-01-07T12:25:08Z

that was brutal 😿
tho please actually double check my changes doesn't break the app in other aspects, since im not extremely familiar with win API while attempting the fix..

unchihugo · 2026-01-07T12:38:41Z

Hi, thank you for contributing, I appreciate it!

Quickly looking through the code the implementation looks great, but I noticed that you left a lot of commented code in and removed some try catch blocks and logging. If possible, could you add them back in areas where needed?

Other than that, do you think we should keep ExplorerRestarting flag to true even if the 8 second loop has passed?

Thanks again!

mclt0568 · 2026-01-07T13:07:51Z

I've updated the comments and added the try-catch block back.

I think if taskbar isnt ready after 8 seconds is kinda sus, either the taskbar is never ready, maybe due to other plugins that modifies the taskbar and causing issue?

One known issue i observed is that an app called start11 could modify the taskbar window causing further instability, but this would be subjected case-by-case to any third party plugins and their implementation, and would be abit of a pain to just create a case for each one of them.

I think flipping the flag back to false after 8 seconds would mean that this PR essentially increases the 1000ms fixed wait time to 8000ms wait time, but allow wait to end earlier if the taskbar is ready; OR if never flipping it to false, then the taskbar features are never loaded again, maybe consider exit the program or showing a message telling the user that taskbar is buggy?

The easier solution would be yes, flipping it back to false, I think 8 seconds is more than enough for any heavy loading, but I think the ultimate decision of this would be how you imagine the app behave.

What do you think? I'll finalise the relevant changes in the next commit, depending on what we decide here.

mclt0568 · 2026-01-07T13:19:08Z

Or, keeping it as true, and maybe the next explorer restart externally (by the buggy plugin, or by the user manually) solves the buggy taskbar, then the taskbar window can reload properly, but never actively triggers a explorer restart by force loading TaskbarWindow, I think would be a better option?

In this case since it would be handled again when this app receives WM_TASKBARCREATED, so nothing needs to be changed in the current code i think

unchihugo · 2026-01-07T17:02:43Z

Thanks for the quick implementation :)

I guess your points make sense! In that case we can keep it set to true, but for edge-case scenarios where the taskbar might take longer than 8 seconds to restart (like really slow computers), perhaps we should extend the timeout to a minute (maybe with exponential backoff if it's resource intensive?), what do you think?

EDIT: I also noticed that there's a duplicate import and the formatting could be fixed up just a little bit. Are you able to look into that as well? thanks!

mclt0568 · 2026-01-07T18:51:17Z

sorry for the messy code 😭, should be fixed now

i think exponential backoff would be a great idea, i might get it in later, its getting late today, for now its 1 minute timeout

fix infinite explorer crashing issue with dynamic taskbar creation check

97f42b4

github-actions bot added MainWindow / Media Flyout Changes to MainWindow.xaml or MainWindow.xaml.cs Taskbar Widget Changes to TaskbarWindow.xaml or TaskbarWindow.xaml.cs labels Jan 7, 2026

mclt0568 mentioned this pull request Jan 7, 2026

[BUG] Windows Insider version 26220.7523 is experiencing constant application crashes. #234

Open

unchihugo requested a review from Copilot January 7, 2026 12:12

Copilot started reviewing on behalf of unchihugo January 7, 2026 12:13 View session

Copilot AI reviewed Jan 7, 2026

View reviewed changes

re-introduced the try-catch when recreating taskbar window

ae6b248

mclt0568 added 2 commits January 8, 2026 05:47

style fix: remove unused imports and collapsed if statements

10d2aa2

increase explore ready wait time to one minute

0a1d03a


		private TaskbarWindow? taskbarWindow;

		internal static volatile bool ExplorerRestarting = false;

		public static extern bool GetWindowRect(IntPtr hWnd, out RECT lpRect);

-    public static extern bool GetWindowRect(IntPtr hWnd, out RECT lpRect);
+    private static extern bool GetWindowRectNative(IntPtr hWnd, out RECT lpRect);
+    /// <summary>
+    /// Safely retrieves the bounding rectangle of the specified window as a managed <see cref="Rect"/>.
+    /// </summary>
+    /// <param name="hWnd">Handle to the window.</param>
+    /// <param name="rect">On success, receives the window rectangle.</param>
+    /// <returns><c>true</c> if the rectangle was retrieved successfully; otherwise, <c>false</c>.</returns>
+    public static bool TryGetWindowRect(IntPtr hWnd, out Rect rect)
+    {
+        rect = Rect.Empty;
+        if (hWnd == IntPtr.Zero)
+            return false;
+        if (!GetWindowRectNative(hWnd, out RECT nativeRect))
+            return false;
+        var width = nativeRect.Right - nativeRect.Left;
+        var height = nativeRect.Bottom - nativeRect.Top;
+        rect = new Rect(nativeRect.Left, nativeRect.Top, width, height);
+        return true;
+    }

Uh oh!

An attempt to fix infinite explorer crashing issue with dynamic taskbar creation check #268

Are you sure you want to change the base?

An attempt to fix infinite explorer crashing issue with dynamic taskbar creation check #268

Conversation

mclt0568 commented Jan 7, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

mclt0568 commented Jan 7, 2026

Uh oh!

unchihugo commented Jan 7, 2026

Uh oh!

mclt0568 commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mclt0568 commented Jan 7, 2026

Uh oh!

unchihugo commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mclt0568 commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mclt0568 commented Jan 7, 2026 •

edited

Loading

unchihugo commented Jan 7, 2026 •

edited

Loading

mclt0568 commented Jan 7, 2026 •

edited

Loading