Incorrect DPI Scaling in WinForms Custom Control with PerMonitorV2 on Multi-Monitor Setup

Question

Incorrect DPI Scaling in WinForms Custom Control with PerMonitorV2 on Multi-Monitor Setup

Monika Theerthagiri 5

When using a custom WinForms control in a dual‑monitor setup with PerMonitorV2 DPI awareness, the application does not scale correctly based on the monitor where it is launched.

I tested the application in a configuration where primary and secondary monitors use different DPI scaling (175% and 100%, swapped between scenarios). Even when launching the application on the secondary monitor, the rendering appears to follow the primary monitor’s DPI.

Screenshots:
Primary 175%, Secondary 100% – Application Launched on Secondary Monitor
Image (2)

Primary 100%, Secondary 175% – Application Launched on Secondary Monitor
Image (1)

The application builds successfully, but the UI layout and scaling behave incorrectly at runtime:

The window is scaled based on the primary monitor instead of the active monitor
Moving the window between monitors does not adjust DPI correctly
Changing the primary monitor DPI affects rendering on the secondary monitor

Is this expected behavior when using PerMonitorV2 DPI awareness in WinForms?
Is this a known limitation of WinForms or custom controls under .NET Framework?
Or is this a potential issue?

Danny Nguyen (WICLOUD CORPORATION) 7,345 Reputation points Microsoft External Staff Moderator

2026-05-11T11:12:52.6133333+00:00
Hi

I tested this with a small WinForms on .NET 10 repro using PerMonitorV2:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net10.0-windows</TargetFramework> <UseWindowsForms>true</UseWindowsForms> <ApplicationHighDpiMode>PerMonitorV2</ApplicationHighDpiMode> </PropertyGroup> </Project>

[STAThread] static void Main() { ApplicationConfiguration.Initialize(); Application.Run(new Form1()); }

public Form1() { InitializeComponent(); AutoScaleMode = AutoScaleMode.Dpi; }

In that repro:

launching on a 100% monitor gave DeviceDpi = 96

launching on a 175% monitor gave DeviceDpi = 168

this also worked when the window started on a non-primary monitor

So based on that, this does not look like expected PerMonitorV2 behavior in WinForms. It looks more like either:

the process is not actually running as PerMonitorV2, or

the custom control is not updating DPI-dependent layout/resources correctly

I would verify that the app really enters PerMonitorV2, that the form uses AutoScaleMode.Dpi, and that the custom control handles DPI changes such as WM_DPICHANGED.

Hopefully this helps.
David Lowndes 2,750 Reputation points MVP

2026-05-12T17:00:27.5766667+00:00

With a simple WinForm, .NET 10 application with the form set to AutoScaleMode DPI, the form border style as FixedDialog, and <ApplicationHighDpiMode>PerMonitorV2</ApplicationHighDpiMode>.

The form doesn't resize correctly across displays of different scales and appears with controls in slightly different places when started on a display at 125% and moved to the 100% display.

All I did was create a form with 2 buttons and placed them at the top left and bottom right edges of the form and then ran it and observed the behaviour I noted.

Here's the form on the 125% screen:

And when moved to the 100% screen, notice that the button1 text appears proportionally lower and button3's border gets clipped:

Furthermore, I note that if I start the application with both monitors set to 100%, and then while it's still running, change the main monitor to 125%, then it appears fine when its moved across the displays!
The issue seems to arise when the primary monitor is set to 125% (or presumably just not 100%).

3 answers

Your answer

Danny Nguyen (WICLOUD CORPORATION) 7,345 Reputation points Microsoft External Staff Moderator

2026-05-11T11:12:52.6133333+00:00

Hi

I tested this with a small WinForms on .NET 10 repro using PerMonitorV2:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net10.0-windows</TargetFramework> <UseWindowsForms>true</UseWindowsForms> <ApplicationHighDpiMode>PerMonitorV2</ApplicationHighDpiMode> </PropertyGroup> </Project>

[STAThread] static void Main() { ApplicationConfiguration.Initialize(); Application.Run(new Form1()); }

public Form1() { InitializeComponent(); AutoScaleMode = AutoScaleMode.Dpi; }

In that repro:

launching on a 100% monitor gave DeviceDpi = 96

launching on a 175% monitor gave DeviceDpi = 168

this also worked when the window started on a non-primary monitor

So based on that, this does not look like expected PerMonitorV2 behavior in WinForms. It looks more like either:

the process is not actually running as PerMonitorV2, or

the custom control is not updating DPI-dependent layout/resources correctly

I would verify that the app really enters PerMonitorV2, that the form uses AutoScaleMode.Dpi, and that the custom control handles DPI changes such as WM_DPICHANGED.

Hopefully this helps.
David Lowndes 2,750 Reputation points MVP

2026-05-12T17:00:27.5766667+00:00

With a simple WinForm, .NET 10 application with the form set to AutoScaleMode DPI, the form border style as FixedDialog, and <ApplicationHighDpiMode>PerMonitorV2</ApplicationHighDpiMode>.

The form doesn't resize correctly across displays of different scales and appears with controls in slightly different places when started on a display at 125% and moved to the 100% display.

All I did was create a form with 2 buttons and placed them at the top left and bottom right edges of the form and then ran it and observed the behaviour I noted.

Here's the form on the 125% screen:

And when moved to the 100% screen, notice that the button1 text appears proportionally lower and button3's border gets clipped:

Furthermore, I note that if I start the application with both monitors set to 100%, and then while it's still running, change the main monitor to 125%, then it appears fine when its moved across the displays!
The issue seems to arise when the primary monitor is set to 125% (or presumably just not 100%).

Answer 1

Danny Nguyen (WICLOUD CORPORATION) 7,345 Microsoft External Staff Moderator

Hi @Monika Theerthagiri

Thanks for the clarification. Since your scenario is on WinForms with .NET Framework, this is a known limitation, not a new issue.

This is addressed here:

https://github.com/dotnet/winforms/issues/10711

As mentioned in that issue, WinForms does not fully support PerMonitorV2 in .NET Framework. The team also noted that PerMonitorV2 support was still being worked on in .NET, which is why this works better there than in .NET Framework.

So the behavior you are seeing — scaling based on the primary monitor, incorrect initial DPI on a secondary monitor, and inconsistent updates when moving between monitors — is in line with that limitation.

If possible, the recommended path is to move to modern .NET, where WinForms DPI support is better.

Danny Nguyen (WICLOUD CORPORATION) 7,345 Reputation points Microsoft External Staff Moderator

2026-05-14T10:19:49.66+00:00

Hi, just checking in. Did my answer help with your problem? Feel free to reach out if you need any help.
Danny Nguyen (WICLOUD CORPORATION) 7,345 Reputation points Microsoft External Staff Moderator

2026-05-18T03:09:21.6666667+00:00

As we haven’t heard back from you for a while, we’ll go ahead and close this thread for now.

If you still need assistance later, feel free to reach out.

Thank you for your understanding.

Answer 2

Thank you for your update regarding the behavior in .NET 10.

We would like to clarify that the issue we reported is reproducible specifically in applications targeting the .NET Framework (WinForms) and does not appear in modern .NET (such as .NET 6/7/10), as you mentioned.

In our testing with PerMonitorV2 DPI awareness enabled, the .NET Framework WinForms application exhibits the following behavior:

The application scales based on the primary monitor DPI, even when launched on a secondary monitor with a different DPI setting.
Initial window rendering does not respect the DPI of the monitor where the application is opened.
Moving the window between monitors does not consistently trigger proper DPI recalculation or layout adjustment.
Changing the primary monitor’s DPI affects rendering on other monitors, indicating that system DPI is being prioritized over per-monitor DPI at runtime.

Based on our observations, this appears to be a limitation of WinForms under the .NET Framework, where full PerMonitorV2 DPI behavior is not completely supported especially in scenarios involving custom controls and multi-monitor environments with mixed DPI settings.

Therefore, we consider this behavior to be expected/known limitation in .NET Framework, rather than a regression or new issue.

Please let us know if any additional information or reproducible details are required.

Answer 3

Per‑monitor DPI awareness (including PerMonitorV2) is designed so that:

The application sees the DPI of the display that the window is primarily located on.
Windows does not bitmap‑scale the UI; instead it sends DPI‑change notifications and the app is responsible for laying out and redrawing correctly.

From the documentation:

System‑DPI‑aware apps use the primary monitor’s DPI for their entire lifetime and are bitmap‑scaled when moved to a monitor with a different DPI.
Per‑monitor / Per‑monitor v2 apps are expected to redraw themselves when the DPI changes; Windows sends DPI notifications to the top‑level window (PMv1) and to both top‑level and child windows (PMv2) and never bitmap‑scales the app.

Given that behavior:

The window using the primary monitor’s DPI regardless of where it is launched, and not updating when moved between monitors, is not expected behavior for a correctly implemented PerMonitorV2 WinForms app. It matches the behavior of a System‑DPI‑aware or DPI‑unaware app.
The platform does not state a limitation that PerMonitorV2 must follow the primary monitor’s DPI or ignore DPI changes. Instead, it states that in PMv2 the app sees the DPI of the display it is on and receives DPI‑change notifications for both top‑level and child HWNDs. WinForms and custom controls must handle those notifications and rescale appropriately; if they do not, the UI will appear too small or too large when moved between monitors.
If the app is correctly registered as PerMonitorV2 but still behaves as described, this indicates a potential issue in how DPI awareness is configured or how the control/form responds to DPI‑change notifications, rather than an intentional limitation of PerMonitorV2.

References: