Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Missing taskbar icon when Form constructor is delayed by blocking operation #13357

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mkarpacts opened this issue Apr 23, 2025 · 3 comments
Open
Labels
needs-area-label untriaged The team needs to look at this issue in the next triage

Comments

@mkarpacts
Copy link

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

@mkarpacts mkarpacts added the untriaged The team needs to look at this issue in the next triage label Apr 23, 2025
@merriemcgaw
Copy link
Member

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.

@merriemcgaw merriemcgaw closed this as not planned Won't fix, can't repro, duplicate, stale Apr 29, 2025
@dotnet-policy-service dotnet-policy-service bot removed the untriaged The team needs to look at this issue in the next triage label Apr 29, 2025
@mkarpacts
Copy link
Author

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 merriemcgaw added the untriaged The team needs to look at this issue in the next triage label May 6, 2025
@merriemcgaw
Copy link
Member

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

@merriemcgaw merriemcgaw reopened this May 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-area-label untriaged The team needs to look at this issue in the next triage
Projects
None yet
Development

No branches or pull requests

2 participants