none
UI controls that worked fine in 1803 now crash with obscure exceptions when targeting 1809

    Question

  • Hello, our company produces commercial user interface controls for Microsoft UI platforms.  We've been making WinRT/UWP controls for years and have recently found that an app project that targets Windows 10 version 1809 triggers various exceptions in our controls and we have not been able to determine why since there is no meaningful information to go on in the exception.

    We really need assistance ASAP here since this prevents our UWP customers from targeting newer Windows versions.

    First, some notes on the scenarios that trigger the exceptions:

    • The same UI controls SDK of ours works and has always worked fine if you target Windows 10 version 1803 or earlier.  
    • When setting the app project to target version 1809 AND if you set the project min version to November update (build 10586) or earlier, it works fine.
    • When setting the app project to target version 1809 AND if you set the project min version to Anniversary update (build 14393) or later, the problems start to occur.
    • The same issues occur in both latest builds of VS 2019 and VS 2017.

    To reproduce one issue easily, download and install our UWP Controls from here:

    You can update our large samples app project that gets installed to target version 1809 and set the min version to Anniversary update or later.  Then run it and go to the Docking/MDI samples area and run the "Simple IDE" sample.  It will immediately throw an exception.  This doesn't occur in other "working" scenarios described above (e.g. targeting 1803).

    If you don't wish to run the large sample project, make a new UWP app project, target version 1809 and set the min version to Anniversary update or later.  Then put this XAML in the main page:

    <Page x:Class="App1.MainPage"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:docking="using:ActiproSoftware.UI.Xaml.Controls.Docking"
        Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    
    	<docking:AdvancedTabControl>
    		<docking:AdvancedTabItem Header="One">
    			<TextBox AcceptsReturn="True" />
    		</docking:AdvancedTabItem>
    	</docking:AdvancedTabControl>
    </Page>
    It will blow up with this exception with the platform target criteria described above:
    System.ArgumentException: Value does not fall within the expected range.
       at Windows.UI.Xaml.UIElement.Measure(Size availableSize)
       at ActiproSoftware.UI.Xaml.Controls.Docking.Primitives.AdvancedTabPanel.MeasureOverride(Size availableSize)
       at Windows.UI.Xaml.FrameworkElement.MeasureOverride(Size availableSize)

    We have verified that a positive size is being passed into the Measure call, so that's not the problem.

    Again, we would appreciate some assistance in working out what has changed on Microsoft's end and how we compensate to prevent exceptions in our controls.  We are happy to work privately with someone if appropriate.  Thank you in advance for the assistance.

    UPDATE: At least in the small simple sample project, we noticed that no exception happens in Release mode.  It only happens in Debug mode there.


    actiprosoftware.com - Professional WPF, UWP, and WinForms UI controls and components


    Tuesday, June 11, 2019 3:03 PM

All replies

  • Hi,

    After debugging, the last line of code I could track is in the ProductItemInfo.CS

    if (controlType != null)
       element = Activator.CreateInstance(controlType) as FrameworkElement;

    I get the same exception ArgumentException at this line of code. It seems the problem happens when the creating the FrameworkElement. I'd suggest that you could try to run the code in a new project targeting version build 14393 and in a device which is build 14393. To seem if there are some changes begin from build 14393.

    Best regards,

    Roy


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, June 12, 2019 7:46 AM
    Moderator
  • Hi Roy,

    Thank you for the reply but that ProductItemInfo.CreateElement call is simply a wrapper around creating each sample in this "sample browser" application.  There is a try...catch around the call to that method.  The real exceptions happen inside of that if you have the exception settings set to break on all CLR exceptions.

    I would recommend starting with the new simple sample project I mentioned instead of using our full sample browser project anyhow.  That way we can start looking at the same issue and it's very clear to see the ArgumentException I mentioned in that scenario.

    Wednesday, June 12, 2019 1:27 PM
  • Hi,

    I had asked the team to take a look at this problem. There might be some time delay. Thank you for your patience.

    Best regards,

    Roy


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, June 14, 2019 6:59 AM
    Moderator
  • Hi ,

    This problem is strange and it is not suitable to discuss via the forum. The team wants to talk to you directly. I suggest that you might need to open a support ticket for this. Please contact our paid phone support at MS Support. You will get 1:1 support on that. Please kindly note that your support ticket will be free if it is Microsoft's issue.

    Best regards,

    Roy


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, June 20, 2019 8:44 AM
    Moderator