The default bug view has changed. See this FAQ.

Current metro builds crash on suspend

RESOLVED FIXED in mozilla16

Status

()

Core
Widget: Win32
--
critical
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: jimm, Assigned: bbondy)

Tracking

({crash})

Trunk
mozilla16
x86_64
Windows 8.1
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
This is still present. Was hoping some of the event work we did a week ago would fix this but it didn't.

STR:

1) launch metro fx
2) switch to another ap

fx crashes before receiving the suspend event.

Updated

5 years ago
Severity: normal → critical
Keywords: crash
(Assignee)

Updated

5 years ago
Assignee: nobody → netzen
(Assignee)

Comment 1

5 years ago
I'm working on this, what a strange crash :(
(Assignee)

Comment 2

5 years ago
Created attachment 623247 [details]
Callstack when there is a crash
(Assignee)

Comment 3

5 years ago
Created attachment 623248 [details]
Call stack from within the suspend callback when there is no crash
(Reporter)

Comment 4

5 years ago
Benjamin, Brian's planning to write something up for the report. We'll plan on filing beginning of next week assuming we don't have a break through between now and then.

support entry page is here - 

http://support.microsoft.com/select/?target=assistance

There's no windows 8, so I just selected win7. They route us to the right place. 

for secondary options:

1) I use it as an IT Professional, developer or Microsoft partner
2) Internal windows based applications and components (drop down)
3) Base windows services

after that they need the msdn support account info.
(Assignee)

Comment 5

5 years ago
We're working on a metro style enabled desktop browser which makes use of XAML interop via a SwapChainBackgroundPanel.
Since we started using XAML interop, we started getting crashes on suspend.
We think that it is related to a bug outside of our code.

The crash does not always happen, but it usually does.
You can reproduce by opening our app, switching to classic Desktop, and then waiting 10 seconds.

When the crashes happen our Suspending event callback is not hit.
Here is the callstack when it crashes:
https://bugzilla.mozilla.org/attachment.cgi?id=623247

When the crash does not happen, our Suspending event callback is hit.
Here is the callstack when it does not crash:
https://bugzilla.mozilla.org/attachment.cgi?id=623248

The relevant code can be found here:
http://hg.mozilla.org/projects/elm

And in particular see /widget/windows/winrt/MetroApp.cpp
(Assignee)

Comment 6

5 years ago
http://mxr.mozilla.org/projects-central/source/elm/widget/windows/winrt/MetroApp.cpp
(Assignee)

Comment 7

5 years ago
Should also mention that this is what comes up in the debug/output window:

First-chance exception at 0x772C33A5 (ntdll.dll) in fennec.exe: 0xC0000005: Access violation reading location 0x00000000.
Unhandled exception at 0x772C33A5 (ntdll.dll) in fennec.exe: 0xC0000005: Access violation reading location 0x00000000.
(Reporter)

Comment 8

5 years ago
I'm working on a fresh test build with all the latest code changes and the xaml interop, should have an install up on the wiki by Monday.

Updated

5 years ago
Crash Signature: [@ NtRaiseException]
(Assignee)

Comment 9

5 years ago
To test this out you can see this build: 5-14 build
https://wiki.mozilla.org/Firefox/Windows_8_Integration#Metro_Test_Install
(Assignee)

Comment 10

5 years ago
MS has reproduced this issue and expects a fix for the release preview.
(Assignee)

Comment 11

5 years ago
MS said that they are no longer supporting XAML interop and I verified this is fixed after reverting XAML interop.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Target Milestone: --- → mozilla16
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.