locked
Random crash, exception code 0xc000027b in Windows.UI.Xaml.dll RRS feed

  • Question

  • Hi everyone,

    So we're developing a metro style app, and at random moments, at some machines, when running the app outside of Visual Studio, we're experiencing crashes. The only thing that is left is an entry in the system's event log like this:

    Faulting application name: SSW8.exe, version: 1.0.0.1, time stamp: 0x51052184
    Faulting module name: Windows.UI.Xaml.dll, version: 6.2.9200.16420, time stamp: 0x505a9ac7
    Exception code: 0xc000027b
    Fault offset: 0x00566c57
    Faulting process id: 0x1b8
    Faulting application start time: 0x01cdfca483a38f92
    Faulting application path: C:\Program Files\WindowsApps\5848609F-881D-402D-8A4D-666026351761_0.0.0.7_neutral__x08hm7yed73n0\SSW8.exe
    Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
    Report Id: d7f56dc7-6897-11e2-afb6-b684e9dbbd10
    Faulting package full name: 5848609F-881D-402D-8A4D-666026351761_0.0.0.7_neutral__x08hm7yed73n0
    Faulting package-relative application ID: App

    At first, this was happening all the time on all our machines, but only outside of Visual Studio. This crash never happened when running the app in Visual Studio. Our app consists of several pages, but most of them are like 'config' pages, which the user goes through in order to set up the real deal. After going through such "wizzard", the user gets to the actual page, on which he spends most of the time (usually around 1-2 hours, interacting every 5-20 seconds). After he finishes his stuff on that page, he gets navigated to the initial page and can start the "setup" again.

    At first we've used 2 machines for development and testing. An i7 Macbook + Windows 8 on Parallels Desktop virtual machine and an i5 Toshiba with Windows 8. We've managed to get rid most of the crashes by properly disposing the viewmodels on our pages, e.g. disconnecting viewmodel methods from model's events when navigating out of a page etc. However, this did not solve the problem completely. We got our hands on two other devices - a Dell Lattitude 10 tablet and an Asus i3 computer, both running Windows 8 Pro. Both of them were still experiencing the mentioned crashes, also only when run outside of visual studio. In VS no crash at all.

    Since we've suspected property change events to be causing the problems, we've added a flag to all viewmodels, that tells it whether it's been disposed or not (we call Dispose for each viewmodel explicitly), and if it was, the OnPropertyChanged isn't called anymore. This seemed to help - both Dell and Asus stopped experiencing the mentioned crashes... most of the times. We still saw the crash once or twice on each of the machines, but it's so rare, that it's impossible to repeat it. The MacBook and Toshiba haven't crashed even once since that.

    However... we got a new device - a 1,5GHz Atom tablet, which got Windows 8 Pro installed on it. This machine is experiencing the same crash all the time. We haven't installed Visual Studio there yet - we only got the developer license and deployed a debug version of our app. This is becoming very annoying, as we have no way of predicting if the app will work on a particular device or not. We have no clue what does this depend on, and we're running out of ideas how to identify the cause of the crash.

    What is the mentioned exception code anyway? I've seen a lot of people having it, and all the solved cases had a different cause, none of which apply to our app. Is there any way we can get more details? It's a bit hard, because as long as we run it under VS we can't really get any crash. Previously, the app was crashing when run outside of VS, and then had a debugger connected to it (attach to process). I could try this on the new tablet and hopefully get a stack trace. Any other suggestions? Can this be a hardware-related issue? The "weaker" the machine is, the more often the error seems to be...

    Please help! If you need any more details regarding the app, the hardware or anything at all, please tell me and I'll get it for you. One of our apps requirements is NOT to crash during operation... it's essential.

    Thanks!
    Marcin

    Sunday, January 27, 2013 7:54 PM

Answers

  • What I am thinking is that one of your IValueConverters is returning an invalid value causing the crash.  I am thinking since the error is happening in the xaml dll it is a converter that has something to do with something visual.  Maybe a converter for a background is returning a color instead of a solidcolorbrush.  I would start removing some of the value converters until you figure out which one is causing the crash.
    • Marked as answer by maggik Monday, January 28, 2013 12:34 PM
    Monday, January 28, 2013 12:15 PM

All replies

  • this just a shot in the dark but are you using any ivalueconverters to format any data bound values? 
    Sunday, January 27, 2013 11:58 PM
  • Hi Ken, indeed, LOTS of ivalueconverters actually..
    Monday, January 28, 2013 8:48 AM
  • What I am thinking is that one of your IValueConverters is returning an invalid value causing the crash.  I am thinking since the error is happening in the xaml dll it is a converter that has something to do with something visual.  Maybe a converter for a background is returning a color instead of a solidcolorbrush.  I would start removing some of the value converters until you figure out which one is causing the crash.
    • Marked as answer by maggik Monday, January 28, 2013 12:34 PM
    Monday, January 28, 2013 12:15 PM
  • Thanks Ken,

    When you wrote about valueconverters I went through them without waiting for your reply, and indeed - sometimes the valueconverters were returning e.g. null instead of String.Empty (not sure if that should cause problems) or throwing exceptions, but that was only happening when incorrect values were being converted or in ConvertBack methods, which should never be used for some converters.

    I went through all valueconverters that we have there and made sure that a correct type is always being returned. Also, I changed all ConvertBack methods to return Windows.UI.Xaml.DependencyProperty.UnsetValue;... and the problem seems to have stopped! Not sure which of those exactly have been causing our problems, but so far so good :)

    By the way - why did it work when run under Visual Studio? I was hoping for it to crash in such cases, and it was pretending to simply work... that's probably why we didn't care about the valueconverters.

    Marcin

    Monday, January 28, 2013 12:34 PM
  • Sometimes visual studio catches error like this for you.  You will see in the output windows something about a first chance exception
    Monday, January 28, 2013 12:40 PM
  • I just had to deal with an identical random crash, don't know if our cause was the same but just in case, here's how I fixed it:

    It turns out to have been related to simply changing the visibility of a particular button in an appbar, along with a lot of other changes being done to the VM at the same time. The changes were being done after a series of complex async/await operations. Removing the async operations before the visibility change fixed the crash, but removing those operations wasn't an option.

    The crash would also happen whether or not visibility was changed through a binding, or directly on the button.

    In the end, inserting a simple "await Task.delay(200);" before the visibility change fixed the problem. I have no idea why, hope this might help someone.

    Saturday, March 2, 2013 10:33 PM