Missing taskbar icon when Form constructor is delayed by blocking operation

[mkarpacts]

.NET version

.NET Framework 4.7.1

Did it work in .NET Framework?

No

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No response

Issue description

If a blocking operation (such as Thread.Sleep) is placed in the constructor of a form before the call to InitializeComponent(), and this operation takes longer than approximately 5000 milliseconds, the application's icon does not appear in the Windows taskbar until the form is fully initialized.

This creates confusion for users, as they may think the application has not started at all.

I would highly appreciate it if your team could review this behavior and confirm whether it is a known issue or potentially a bug that could be fixed in future versions of WinForms.

For your information, this issue has been reproduced on the following operating system:
OS Name: Microsoft Windows 11 Pro
Version: 10.0.26100 Build 26100

Steps to reproduce

I have prepared a minimal WinForms application to demonstrate this behavior. The code includes two constants:

• 4000 ms – the icon appears correctly
• 5000 ms – the icon does not appear

You can switch between them in Form1.cs to observe the difference.

I’ve attached a ZIP

WinFormsTaskbarBugDemo.zip

archive with the full project and a README file explaining the steps to reproduce the issue.

[merriemcgaw]

This is the expected behavior when you have a blocking operation in the constructor. The icon is not an application bound entity, it is the host form. If the form isn't constructed, you can't have access to the icon.

[mkarpacts]

Hello, @merriemcgaw

Thank you for your response.

I understand that blocking operations in the constructor can delay the form creation, which may cause the taskbar icon to appear with a delay. However, in my case, the issue is more serious: the taskbar icon never appears at all, even after the constructor finishes and the form is fully initialized.

To clarify:

• The application runs correctly after the blocking call.
• The main window becomes interactive and fully usable.
• But the icon in the Windows taskbar never appears, which misleads users into thinking the application didn’t launch, even though it’s already running.

This issue only occurs when the blocking operation before InitializeComponent() takes longer than approximately 5000 milliseconds. Shorter delays (e.g., 4000 ms) do not cause this behavior.

I would appreciate it if the team could review this behavior once again to determine whether this is a potential bug or something that could be improved in future versions.

[merriemcgaw]

I'll reopen this issue, and we'll take another look as time permits.

[KlausLoeffelmann]

What you're seeing is by design, and it does not have to do with WinForms, but is standard Windows behavior. After about 5,000 ms, if your App did not start (or stopped) handling of the message queue, Windows starts counter measures to prevent a hung App to be too disruptive in terms of blocking access to other UI elements: It is "ghosting" your App. Not seeing the App Icons is one of the outfalls of this.

You should consider to move the heavy workload for the initialization (I know, it's often easier said than done, but it's really important for a stable app!) to a later point in time. And maybe, you can do it even asynchronously, so it wouldn't block the App at all.

Opportunities to spin-off (Async) initialization workloads could be:
(This is from a test app I once wrote, which has a FrmMain which shows a FrmTest and logs, what stage it reached when and with what call stack.)

[00:00.000] 1. CreateParams  (called from:Control:Void .ctor(Boolean))
[00:00.029] 2. Constructor  (called from:frmMain:Void Start_Click(System.Object, System.EventArgs))
[00:00.036] 3. CreateParams  (called from:Control:System.Drawing.Size SizeFromClientSizeInternal(System.Drawing.Size))
[00:00.037] 4. CreateParams  (called from:Control:Void UpdateBounds(Int32, Int32, Int32, Int32))
[00:00.038] 5. OnResize  (called from:Control:Void OnSizeChanged(System.EventArgs))
[00:00.040] 6. CreateHandle  (called from:Control:IntPtr get_Handle())
[00:00.040] 7. CreateParams  (called from:Control:Void CreateHandle())
[00:00.043] 8. OnHandleCreated  (called from:Control:Void WmCreate(System.Windows.Forms.Message ByRef))
[00:00.050] 9. CreateParams  (called from:Control:Void UpdateStylesCore())
[00:00.055] 10. OnCreateControl  (called from:Control:Void CreateControl(Boolean))
[00:00.056] 11. OnLoad  (called from:Form:Void OnCreateControl())
[00:00.056] 12. OnLayout  (called from:Control:Void PerformLayout(System.Windows.Forms.LayoutEventArgs))
[00:00.057] 13. OnVisibleChanged  (called from:Control:Void WmShowWindow(System.Windows.Forms.Message ByRef))
[00:00.072] 14. OnActivated  (called from:Form:Void set_Active(Boolean))
[00:00.093] 15. OnShown  (called from:Form:Void CallShownEvent())
[00:00.122] 16. OnPaint  (called from:Control:Void PaintWithErrorHandling(System.Windows.Forms.PaintEventArgs, Int16))

[00:00.000] 17. OnFormClosing  (called from:Form:Boolean CheckCloseDialog(Boolean))
[00:00.003] 18. OnFormClosed  (called from:Form:Boolean CheckCloseDialog(Boolean))
[00:00.004] 19. OnDeactivate  (called from:Form:Void set_Active(Boolean))
[00:00.010] 20. OnVisibleChanged  (called from:Control:Void WmShowWindow(System.Windows.Forms.Message ByRef))
[00:00.038] 21. OnHandleDestroyed  (called from:Control:Void WmDestroy(System.Windows.Forms.Message ByRef))