We also have crashes that seem to be unrelated to our code. I feel that the reason for those reported crashes is that Game.Exit() uses the terminate function, which might end up killing the game.
sorry for reviving the thread, I’m getting swamped by those crashes and some extra more . I’m afraid they may impact negatively store positions as crashes are told to be a metric in the store rankings.
Do you think there’s an alternative to Terminate? In example, forcing a “back press” on the GamePage.xaml or App.xaml which would make the game terminate in a natural WP way?
I don’t know about any other way you could handle it. It works in the following way currently:
We receive a back button pressed event from GamePage. In its event args there is a bool we have to set when we don’t want the UI to do the back action (navigate to previous page or exit the application). This “handled” bool is always set to true when we receive an event. The event is forwarded to GamePad so that we set a flag inside it to signal that the back button should be displayed as pressed the next time the user queries its status.
Due to this difference (XAML is push, XNA is pull) it is very complicated to make the two things work together, especially if we want to keep the XNA signature.
I’ll make a little experiment with one of my simple games. I’ll disable the back button event handling from MonoGame, so pressing “back” will quit GamePage (and the game). Then I’ll observe if those crashes are still present or they just disappear. This may give us a clue if this is the real problem.
I submitted my app without calling to Exit nor doing custom exception caching.
I was expecting to either having those weird crashes disappear, or crashes remaining constant in number and receive lots of other crashes from my game, which I trap before crashing and report to my server.
However, the “weird crashes” increased significatively, it seems like every crash that is happening inside my game translates into that “weird c++ crash”
My conclusion is that
calling Exit does not affect to this crash.
WP8 reporting doesn’t work at all for c#
2 is obviously very hard to accept because I suppose lots of people are using C# with WP8, and there are no crash reports of this type outside the MonoGame comunity.
I’m normally using a try/catch on draw and update loops to report my exceptions. I’ve moved my exception notifier to Application_UnhandledException too, in order to check if the crash is in monogame, or it happens outside of it.
Some more days again to wait to the WP crash reports to be filled
Once again, I get weird results with the stack traces:
I used the Application_UnhandledException as Nezz said. Once the message is received, I log that to my server and use the Exit function.
I was using “System.Windows.Application.Current.UnhandledException += myHandled” but for some reason, this seems not to work the same as Nezz’s suggestions.
Right now the weird crash reports have stopped for 8.0. The exception is trapped correctly, reported to my server (mainly Smaato and Admob control crashes) and gracefully exited. I think this proves that WinPhone’s crash reports are not working correctly, at least for C# (maybe for crashes not in the main thread)
However, the weird C++ crash reports continue in WP 8.1: approximately the same amount (it’s hard to say because the crash reports are also hard to interpret, giving you just a number of crashes of the last 30 days instead of a graph)
On the other side, the 8.1 crashes are probably Smaato’s and Admob’s fault too. Unfortunately talking with them about their controls is like talking to a 1000ft stone wall. Tough luck
I live in a permanent chaos when coming to ad-related questions
In some point in the past I used to check each day the eCPMs for all (5 at the time) controls and move them around. When the number of games grew I realised I prefered to make games rather than spending the day adjusting parameters (mix 20 important countries with 5 controls and 7~8 games )
With smaato I have around 61% fillrate ATM and the eCPM is about 1/2 of Admob. However it depends on every project and country, and even the moment. For me, it’s probably “the best of the rest” (being AdMob the best in WP8. The eCPM is good, but the fill rate is almost 100% on most countries. That beats all the other controls)
AdMob is usually better at detecting “error clicks” (about half adverts bring a method which you must click twice to open the ad) so games with “dubiously positioned ads” usually get a better eCPM on Smaato.
On the other side, Smaato crashes a lot, but AdMob crashes too, leaks and banners degrades performance making a flawless 60fps game into a mess and you can’t even prevent it to run in the background when you decide to remove it.
So in the end, by default I use Admob in WP8, unless the game requires smooth gameplay. If required , then I usually put pubcenter, smaato and others, and only use Admob in countries I have no other good control (usually Russia)
(I usually have USA served only by pubcenter. They have a good fillrate for USA and good revenue too and the control does not crash nor degrade performance. Then, fall back to smaato and other controls)
just for the record, I don’t know what leaded me to tell that the error disappeared on WP8.0 (maybe there was a delay in the crash reports which didn’t show any WP8.0 data) . Today I checked the crashes and there are still crashes for WP8.0 too, so my previous conclusions may be completely wrong.
. I’m afraid they may impact negatively store positions as crashes are told to be a metric in the store rankings.