Author Posts

December 31, 2016 at 1:38 pm

Hello 🙂

I use a little script to get the screen resolution.

[void][Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$HauptbildschirmgrĂ¶ĂŸe = [System.Windows.Forms.SystemInformation]::PrimaryMonitorSize
$Breite = $HauptbildschirmgrĂ¶ĂŸe.Width
$Höhe = $HauptbildschirmgrĂ¶ĂŸe.Height
[System.Windows.Forms.MessageBox]::Show(„$Breite und $Höhe",“SystemInformation“,0)

Unfortunately it doesn't work when a display scaling factor is set. When I run it on a computer with a 3840 x 2160 display with a 225 % scaling factor (on Server 2012 R2 or Win 10) I get those results, no matter if it's a remote desktop session or on the local machine:

run with PowerShell.exe: 1707 x 960
run with PowerShell_ISE.exe: 3840 x 2160
or at 150 %:
run with PowerShell.exe: 2560 x 1440
run with PowerShell_ISE.exe: 3840 x 2160

Then I got a tip and tried:

Get-CimInstance -ClassName CIM_VideoController

This returns the correct resolution 3840 x 2160 no matter what scaling factor is set, but it doesn't work in a remote desktop session. In a remote desktop session all those classes return 1024 x 768.

I also tried out:

Get-WmiObject Win32_DesktopMonitor
Get-CimInstance -ClassName Win32_VideoConfiguration
Get-CimInstance -ClassName Win32_DisplayControllerConfiguration
Get-CimInstance -ClassName CIM_VideoControllerResolution
Get-CimInstance -ClassName CIM_MonitorResolution
Get-CimInstance -ClassName CIM_FlatPanel
Get-CimInstance -ClassName Win32_VideoController
Get-CimInstance -ClassName CIM_PCVideoController

Without success in a remote desktop session. Thanks for any hint.

January 2, 2017 at 4:38 pm

I did some testing and actually couldn't reproduce it at first. For me

 [System.Windows.Forms.SystemInformation]::PrimaryMonitorSize 

always gave back the proper resolution. Whether I used DPI scaling settings or if I used remote desktop (or a combination of both).

Then I changed the DPI again and did some more testing without logging off. Then I could reproduce your issue. So, have you logged off and logged back in after changing DPI?

Edit: if you keep running into this you should be able to calculate the actual resolution though using this script.

$DPISetting = (Get-ItemProperty 'HKCU:\Control Panel\Desktop\WindowMetrics' -Name AppliedDPI).AppliedDPI
switch ($DPISetting)
{
    96 {$ActualDPI = 100}
    120 {$ActualDPI = 125}
    144 {$ActualDPI = 150}
    192 {$ActualDPI = 200}
}
$Size = [System.Windows.Forms.SystemInformation]::PrimaryMonitorSize
$width = ($($Size.Width) / 100) * $ActualDPI
$height = ($($Size.Height) / 100) * $ActualDPI

It will retrieve DPI setting from registry (which isn't the actual percentage). Then I'll get the actual DPI in percentages. I figured out the numbers trying the various DPI settings. Then you can just do some simple math to calculate the actual resolution.

January 3, 2017 at 7:29 pm

Thanks a lot, this a great workaround. It solved my problem. I only added an exception for Windows 7 because it always reports the correct resolution and multiplying it with the scaling factor would falsify the resolution.

Yes, the computers I used for testing have been restarted multiple times, the change of dpi was applied correctly.
I can easily reproduce this behaviour. I just save

[void][Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$Size = [System.Windows.Forms.SystemInformation]::PrimaryMonitorSize
$Size.Width
$Size.Height
Read-Host -Prompt "Press Enter to exit" 

into a file like test.ps1, right click on it, run with PowerShell => wrong resolution on Windows 10 and Server 2012 R2, correct resolution on Windows 7.
When execute this code inside the PowerShell ISE it works under all circumstances. Did you try both, PowerShell.exe and PowerShell_ISE.exe?

January 4, 2017 at 12:43 pm

Oh you're right, totally forgot about that. Always tend to write and test my code in ISE only. Good to hear it solved the issue.