Player display resolution changes to the native resolution of the monitor when Player becomes unresponsive

Thank you for reporting a bug to Unity. After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling. Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT). As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because: - The Windows message sequences for freeze recovery and monitor switching are effectively the same - Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds - There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently. Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.

Thank you for reporting a bug to Unity. After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling. Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT). As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because: - The Windows message sequences for freeze recovery and monitor switching are effectively the same - Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds - There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently. Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.

Unity 6000.2 has reached its end of life and will not receive further updates. If you need additional fixes, please upgrade to a newer Unity version.

Thank you for reporting a bug to Unity. After investigation, this behaviour is driven by Windows/DWM window management rather than an error in Unity’s resolution handling. Spy++ analysis shows that when the Player becomes unresponsive and recovers, Windows sends WM_SIZE (SIZE_RESTORED) messages that reapplies the monitor’s native window size. These messages cannot be distinguished from the WM_SIZE messages in scenarios such as moving the window between monitors (e.g. CTRL+WIN+LEFT/RIGHT). As a result of this, the current behaviour is considered an OS-level constraint of fullscreen on Windows, and this issue will be closed as Won’t Fix, because: - The Windows message sequences for freeze recovery and monitor switching are effectively the same - Unity cannot reliably differentiate a “freeze recovery resize” from a valid OS-driven resize without using fragile workarounds - There is no platform-safe way for Unity to preserve a previously requested non-native resolution across a freeze without introducing regressions If you can identify the cause of the player becoming unresponsive, please report it as a separate bug so it can be investigated independently. Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.