Desktop crash troubleshooting

io.Connect Desktop
1

Recently, an interesting issue caught my eye. A user reported that:

  • The desktop container launches.
  • The login screen appears, the user logs in, and sees “login successful”.
  • Right after that, the app crashed.

What the logs showed

After looking in the logs, it turned out the platform was trying to restore a window/layout with huge bounds (with width of almost 20000, height almost 10000). In this case, the revealing line was:

[YYYY-MM-DD HH:MM:SS] [INFO] … Initial GetWindowPlacement with physical bounds: {Width=<very large>, Height=<very large>}
[YYYY-MM-DD HH:MM:SS] [INFO] … Final logical bounds: {Width=<very large>, Height=<very large>}

This can happen when the window layout state saved by the desktop client describes a very large virtual desktop area, for example because the user had multiple monitors arranged in an extended display configuration or unusual monitor positioning.

Changes in monitor configuration, such as disconnecting or rearranging displays, switching between multi-monitor and single-monitor setups, or restoring a layout saved on a different set of screens can trigger this by leaving saved bounds that no longer make sense for the current display arrangement.

Resolution

io.Connect Desktop 9.9.4, introduces Size Constraints for Restoring Layout Components to avoid such weird scenarios and improves restoring large layout components on low-resolution monitors.
You can add a safety cap in system.json to clamp oversized layout components during restore:

{
  "layouts": {
    "components": {
      "maxSize": 4000
    }
  }
}

If a component exceeds the specified size in width or height, the platform adjusts it to fit the current monitor where it is being restored.

Troubleshooting tips

  • Gather all relevant logs for the time period around the crash. See more about them here: Understanding logs in io.Connect
  • Look for patterns and anomalies leading up to the failure. A single log entry may not show the root cause, but a sequence of warnings/errors before a crash often reveals the chain of events that triggered it.
  • Filter logs by time range, severity (Error/Critical), and relevant sources to reduce noise and surface the events most likely tied to the problem.
  • Check for other correlated data (e.g., CPU/Memory use, driver or service failures) around the same timestamp to build a complete picture of what the system state was when the crash happened.
  • Always include timestamps and event identifiers when sharing logs with support - that makes root cause analysis faster and more precise.