locked
One particular page crashing on some PCs in 8.1

    Question

  • I'm having a really annoying problem and I'm out of things to try.  I've read a handful of posts, but nothing fits.

    I have 4 apps all built on the same framework (1 core dll).  After upgrading to Windows 8.1, there are reports of one particular page crashing (the rest of the app works fine).  I've had two customers report this and their story was the same:
    1) Using Surface Pro
    2) Install (and purchase full version of) my app on Windows 8
    3) Upgrade to Windows 8.1
    4) The app crashes on that one page, every time

    I updated the app to be 8.1-compliant, but the new version is still crashing for them.  In fact, when I submitted the 4 apps for certification, 1 passed fine, the other 3 crashed on that page.  For 1 of the failed apps, I simply rebuilt with the same code base, resubmitted, and it worked fine.
    It never fails on any of my machines.  I've tested on 4 machines doing the same 8->8.1 upgrade.

    One customer reported this event log:
    Faulting module name: Windows.UI.Xaml.dll, version: 6.3.9600.16408, time stamp: 0x523d44f3
    Exception code: 0xc000027b
    Fault offset: 0x00850fce
    Faulting process id: 0x1548
    Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
    Report Id: 3cb68b0d-3f69-11e3-be8e-6045bde95ed7
    Faulting package-relative application ID: App

    I received a report back from the failed certifications, but it seems to contain a bunch of useless information.

    Any suggestions would be greatly appreciate it.  I need to get this fixed before my reviews start to plummet.
    Thanks!



    • Edited by LordSupafly Wednesday, October 30, 2013 6:58 PM
    Wednesday, October 30, 2013 6:57 PM

Answers

  • Well, I got it ironed out.  It was basically an endless loop from a SizeChanged event.  The fix was simple:

            private void ProgressBar_SizeChanged(object sender, SizeChangedEventArgs e)
            {
                int newWidth = Convert.ToInt32(this.ActualWidth);
                if (this._UsableWidth == newWidth)
                    return;
     
                this._UsableWidth = newWidth;
                // Do stuff with the control
            }
    

    It was just a futility check to see if the width was different from the last time the event hit.  The hard part was just finding it.  I’m kind of disappointed in the error reporting system, I guess.  Endless loops are usually easier to find (Repeating stack track, Memory overflow, etc).  It’s a shame it just mysteriously crashed with no indication of the true stack trace.

    Anyway, the customer was great.  Jeff, you were right.  I had to deploy 6 or 7 different debugging versions and that finally narrowed it down.

     I'll never understand why it ONLY affected SurfacePro customers running Windows 8.1, but at least it's fixed now.

    Hopefully this can help someone.


    • Edited by LordSupafly Tuesday, November 19, 2013 5:36 AM
    • Marked as answer by LordSupafly Tuesday, November 19, 2013 5:37 AM
    Tuesday, November 19, 2013 5:31 AM

All replies

  • Are you in contact with one of your customers with the problem?  You could debug it on their machine with a debug build perhaps!


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Thursday, October 31, 2013 12:32 PM
  • I assume you're talking about side-loading a test version.  Unfortunately, I'm not sure where to start.
    I finally opened a support incident, so the tech is getting back to me.  I'll post here if I find an answer.

    Thanks

    Tuesday, November 05, 2013 3:24 AM
  • Yes, Sideload to a willing customer.  Basically find someone with the problem and SideLoad the app.  Insert some debugging statements to track what is going on in your code to determine where the failure lies.  The community would definitely appreciate you posting the solution here once you discover it with the help of support!

    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, November 05, 2013 1:12 PM
  • Well, I got it ironed out.  It was basically an endless loop from a SizeChanged event.  The fix was simple:

            private void ProgressBar_SizeChanged(object sender, SizeChangedEventArgs e)
            {
                int newWidth = Convert.ToInt32(this.ActualWidth);
                if (this._UsableWidth == newWidth)
                    return;
     
                this._UsableWidth = newWidth;
                // Do stuff with the control
            }
    

    It was just a futility check to see if the width was different from the last time the event hit.  The hard part was just finding it.  I’m kind of disappointed in the error reporting system, I guess.  Endless loops are usually easier to find (Repeating stack track, Memory overflow, etc).  It’s a shame it just mysteriously crashed with no indication of the true stack trace.

    Anyway, the customer was great.  Jeff, you were right.  I had to deploy 6 or 7 different debugging versions and that finally narrowed it down.

     I'll never understand why it ONLY affected SurfacePro customers running Windows 8.1, but at least it's fixed now.

    Hopefully this can help someone.


    • Edited by LordSupafly Tuesday, November 19, 2013 5:36 AM
    • Marked as answer by LordSupafly Tuesday, November 19, 2013 5:37 AM
    Tuesday, November 19, 2013 5:31 AM
  • Thanks for sharing with the community.  I am glad you nailed this one!

    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, November 19, 2013 1:05 PM