locked
"An Unhandled Win32 exception occurred" RRS feed

  • General discussion

  • My team is developing a very complex application in C#/XAML against the Windows Store Application 8.1 API.  In one section of our app, we get the "unhandled win32" exception and can do nothing about it.  I have checked every inch of our code and see nothing that goes wrong.  It does not happen every time but pretty consistently crashes when bouncing between a few different pages within the frame.

    I have removed the only AppBar in the app (seeing that this was the culprit in  many other posts), but it has done nothing to fix the bug.  What tools/methods are available to track this down?  Just catching the exception inside the dev environment would be amazingly helpful!

    Any help is greatly appreciated!

    Thanks,

    Sean

    Tuesday, November 5, 2013 4:27 PM

All replies

  • You should be able to break when the application is thrown in the debugger.

    Since it is a native exception (the Windows Runtime is all native code) you'll need to enable native or mixed mode debugging in the Project properties' debug tab.

    --Rob

    Tuesday, November 5, 2013 5:08 PM
    Moderator
  • Rob, Thank you for your reply. I have done that before and just gave it another shot.

    I get a page stating "Source not available", Source information is missing from the debug information for this module.  You can view disassembly in the Disassembly window....

    When I do that, I do, in fact, get disassembly information which might as well be in Chinese!

    Tuesday, November 5, 2013 6:46 PM
  • You won't be able to do source level debugging in the Windows Runtime, but you should be able to get symbols and infer some information from the state of the stack when the exception occurs.

    --Rob

    Thursday, November 7, 2013 12:46 AM
    Moderator
  • Rob, Thank you for your reply. I have done that before and just gave it another shot.

    I get a page stating "Source not available", Source information is missing from the debug information for this module.  You can view disassembly in the Disassembly window....

    When I do that, I do, in fact, get disassembly information which might as well be in Chinese!

    Hi, getting the debugger to break in the native code is over half of the battle, even without the source.

    Take a look at the stack for thread on which the exception is thrown, that may indicate at least the system DLL within which the exception arose.

    Can you post a screenshot of what you see in the Visual Studio IDE when it breaks?

    Cap'n

    Thursday, November 7, 2013 4:37 AM
  • I believe I found the issue through trial and error.  Time between failures was typically a few minutes but it sometimes took a hundred navigations to the page before the bug exposed itself.

    The problem came down to cyclical references to merged resource dictionaries.

    • BaseResourceDictionary was referenced by the App.xaml
    • TemplateDictionary1 contained a merged dictionary reference to BaseResourceDictionary
    • TemplateDictionary2 contained a merged dictionary reference to BaseResourceDictionary
    • My page contained a merged dictionary reference to both TemplateDictionary1 and TemplateDictionary2, and the page indirectly referenced BaseResourceDictionary through App.xaml.

    After removing the merge dictionaries from TemplateDictionary 1 and 2, the problem hasn't come back.

    Hope this helps someone!

    Thursday, November 7, 2013 1:53 PM