.NET Core: Form Size Not Updating Correctly When DPI Scaling Exceeds 200%

[vimalrajsf5014]

.NET version

.NET 90

Did it work in .NET Framework?

No

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

Not applicable — this issue was observed on .NET Framework. I have not verified behavior on earlier .NET Core or .NET 5+ releases.

Issue description

When adding a control of size 500x500 pixels (at 100% scaling = 96 DPI) to a Microsoft Form, the control is anchored and its size is measured at different points in the lifecycle:

• After InitializeComponent
• After OnHandleCreated
• At 100% scaling, these measurements are identical.
• At DPI scaling greater than 200%, the control size differs depending on when it is measured, which causes layout problems.

I have attached a simple sample project and images that demonstrate the issue.

Screenshots

• 100% Scaling:

• 125% Scaling:

• 150% Scaling:

• 175% Scaling:

• 225% Scaling:

• 250% Scaling:

• 300% Scaling:

• 400% Scaling

• 500% Scaling

SimpleSample

MicrosoftFormSimpleSample.zip

Actual Behavior

• For DPI scaling greater than 200%, the control’s size measured after InitializeComponent and after OnHandleCreated differs.
• This mismatch causes layout problems and breaks anchored layouts.

Expected Behavior

• The control size should remain the same between creation and display, regardless of the DPI scaling level.
• Anchored layouts should not break due to differences between InitializeComponent and OnHandleCreated measurements.

Steps to reproduce

Step 1 : Run the attached simple sample project.
Step 2 : Click the MicrosoftForm button.
Step 3 : Ensure that DPI awareness is set to true in the app.manifest file.
Step 4 : The sample creates a control sized 500x500 pixels at 100% scaling (96 DPI) and anchors it to the parent form.
Step 5 : Observe the control size measured:

• After InitializeComponent
• After OnHandleCreated

Step 6 : Change the display scaling level to 200% or higher (e.g., 225%).
Step 7 : Compare the measurements — they should be the same, but at scaling >200% the values differ.

[LeafShi1]

Duplicate of #14197

[Olina-Zhang]

Not repro it on different System DPI setting 100%->125%->175%->200%->225%->250%->300%->350% when running provided testing app:
100%:

125%:

150%:

175%:

200%:

225%:

250%:

300%:

350%:

[vimalrajsf5014]

Thank you for testing across different DPI settings. Could you please share the specific system DPI configuration you used (for example, the Windows display scaling percentage and monitor resolution)?
The issue occurs regardless of whether the app is run on an internal or external monitor. The specific monitor resolution does not affect reproducibility—1920x1080 is sufficient to observe the problem.
I have attached my system details and a video for your reference. This will help me reproduce the same environment and confirm whether the issue is resolved.

System Details
Edition : Windows 11 Enterprise
Version : 24H2
Installed on ‎: 1/‎13/‎2025
OS build : 26100.7462
Experience : Windows Feature Experience Pack 1000.26100.275.0
Display Scaling Tested: 125%, 150%, 175%, 200%, 225%, 250%, 300%, 350%, 400%, 450%
Control Behavior: Control is anchored to the parent form
Custom Styling: None applied
Display Resolution: 1920x1080

ReplicateVideo

ReplicateVideo.zip

[Olina-Zhang]

@vimalrajsf5014 I pick up the same display resolution: 3840x2160 with different DPI Scale values, to run app from File Explorer or Visual Studio on primary monitor.

[vimalrajsf5014]

Thank you for confirming the tests at 3840×2160 with different DPI scale values. For further troubleshooting, could you please set the display resolution to 1920×1080 on the primary monitor, apply different DPI scale values, and then run the application from File Explorer or Visual Studio? This resolution reliably reproduces the reported issue .

[Olina-Zhang]

When setting display resolution with 1920x1080, the maximum scale value is 175%.

If custom scaling with value > 200%, this issue can repro. The system has some notice about Custom scaling, I am not sure whether it's a valid scenario. It's need to our engineering team to confirm.