Help With Odd Windows Crash

  1. last year

    Graham B

    5 Apr 2019 Testers, Xojo Pro The Canada's

    Hi, I have a crash on Windows 10 in a very specific situation. The Event Viewer report only tells me the crash is inside XojoGUIFramework dll which does not really help. The set up is this.

    Windows 10 running a hidpi enabled app on a 4K screen with scaling set to 225%, any other combination and the crash does not happen. Testing on VMWare and changing the res 1 pixel larger fixes it!

    Compiling on macOS on 2019r1rc1 as well as 2018r4 and 2017r2.1 all have the problem.

    The problem is related to the list box header, if I turn off hasHeading then the crash does not occur.
    I have also been able to narrow it down to the crash occurring when the first and only column with * set in the column widths is shown.
    I cannot replicate in a test app so I edited my large app to enable resizing and the crash does not occur when the heading is shown and the * column is not visible (listbox to small etc).
    Resizing the window works fine until the list box header is going to show that column for the first time and then crash, this is not how the window is designed just for testing.

    Changing the caption for that column header does nothing, changing font sizes does nothing, removing and readding the listbox does nothing. Removing all events handlers from the listbox does nothing (listbox has not been subclassed)

    My only solution I can think of right now is detecting 4K screen with 225% scaling and show a warning about not being a compatible setup, only issue is this might not be the only combination it occurs on.

    Does anyone have any helpful ideas on how to fix this?

    @Graham B The problem is related to the list box header, if I turn off hasHeading then the crash does not occur.
    I have also been able to narrow it down to the crash occurring when the first and only column with * set in the column widths is shown.

    This looks a bit like this: Feedback Case #55165

    Setting fixed ListBox ColumnWidths no longer raises floating point exceptions which could potentially crash the app depending on the system's FPU settings.

    If it is... then you're going to look forward to 2019r1.

    @Graham B Compiling on macOS on 2019r1rc1

    Oh... if not...

    @Graham B Does anyone have any helpful ideas on how to fix this?

    If it has to do with the Column Widths... don't use *. Manually set a width (respecting ScaleFactor, also manually set when resizing) that will be a "full pixel" for each column?

  2. Jürg O

    5 Apr 2019 Testers, Xojo Pro Answer
    Edited last year

    @Graham B The problem is related to the list box header, if I turn off hasHeading then the crash does not occur.
    I have also been able to narrow it down to the crash occurring when the first and only column with * set in the column widths is shown.

    This looks a bit like this: Feedback Case #55165

    Setting fixed ListBox ColumnWidths no longer raises floating point exceptions which could potentially crash the app depending on the system's FPU settings.

    If it is... then you're going to look forward to 2019r1.

    @Graham B Compiling on macOS on 2019r1rc1

    Oh... if not...

    @Graham B Does anyone have any helpful ideas on how to fix this?

    If it has to do with the Column Widths... don't use *. Manually set a width (respecting ScaleFactor, also manually set when resizing) that will be a "full pixel" for each column?

  3. Graham B

    5 Apr 2019 Testers, Xojo Pro The Canada's

    @Jürg O If it has to do with the Column Widths... don't use *. Manually set a width (respecting ScaleFactor, also manually set when resizing) that will be a "full pixel" for each column?

    Brilliant, not sure why I didn't think of that, the window is fixed width but variable height so this would work .... in theory

  4. Jürg O

    5 Apr 2019 Testers, Xojo Pro

    I hope so... but still: Please file a Feedback!
    If you can't create a simple reproducible example, then describe as above and attach the CrashDump.
    I think you should find it here: C:\Users\your-windows-user-home\AppData\Local\CrashDumps
    This should allow @William Y to exactly pinpoint the cause of the crash in the .dll

    Just recently a user has also only be able to provide a CrashReport with yet another "odd Windows crash": Feedback Case #55322 Funny that Listbox also seems to be involved there...

    I have been hoping that 2019r1 will finally fix these rare/odd crashes on Windows (quite some are according to what one can currently see in Feedback) - but it seems you've found another piece of the puzzle. So thanks for your Feedback report on this one :)

or Sign Up to reply!