Ad Rotator and MonoGame issues

Sep 18, 2013 at 8:30 AM
Edited Sep 18, 2013 at 8:48 AM

I'm building a game for Windows Phone 8 using MonoGame. A free version of it will have ads at the top. For displaying ads I'm using AdRotator. The game has option to post results to the Facebook as an image. Recently, while testing I've find out that game completely freezes while posting image to Facebook. During debugging I was able to detect code that causes that freeze. This code is a part of MonoGame:
var waitEvent = new ManualResetEventSlim(false);
Deployment.Current.Dispatcher.BeginInvoke(() =>
    var bitmap = new WriteableBitmap(width, height);
    System.Buffer.BlockCopy(pixelData, 0, bitmap.Pixels, 0, pixelData.Length);
    bitmap.SaveJpeg(stream, width, height, 0, 100);

So, MonoGame thread is waiting for waitEvent to be set, but action isn't called by BeginInvoke. When there is no AdControl everything is fine, so for me it looks like AdRotator and MonoGame are conflicting somehow, but I don't really understand why this could happen.

P.S.: I must say that I'm using Windows Phone 8 version of Ad Rotator (not XNA or MonoGame implementation).
Sep 18, 2013 at 12:09 PM
If you are using the Windows Phone 8 version, then that is XAML based and should not interfere with MonoGame in anyway. MonoGame writes to the DrawingGridBackgroundSurface whereas AdRotator would be rendered afterwards.

Try putting the AdRotator control in a separate user control and add that to your page then test enabling or disabling adrotator to see if it is a generic XAML rendering issue in Monogame or not.

That bit of code is used for Texture Generation in MonoGame so shouldn't have any interaction with AdRotator.
Sep 18, 2013 at 12:16 PM
What do you mean by "enabling/disabling" - show/hide or not adding AdRotatorControl to the page at all? I've already tried to put just Border instead of AdRotatorControl and everything was working fine.
Sep 18, 2013 at 2:03 PM
OK, what about if you put adRotator on the page but do not call invalidate? This ensures that adrotator isn't running when you return to the page but the control is in the hierarchy.
Tricky to diagnose because I have several Monogame projects (both WP8 and Win 8) using AdRotator without issue.
Sep 18, 2013 at 2:44 PM
Darkside wrote:
OK, what about if you put adRotator on the page but do not call invalidate? This ensures that adrotator isn't running when you return to the page but the control is in the hierarchy.
It works OK in this scenario.

Darkside wrote:
Tricky to diagnose because I have several Monogame projects (both WP8 and Win 8) using AdRotator without issue.
I totally agree that it is very trick. Btw, I also can reproduce this freeze in my custom code:
  1. AdRotator is up and running
  2. Have some "button" or whatever in the game that will start code execution
  3. Code itself (in a button tapped handler for example):
var waitEvent = new ManualResetEventSlim(false);

Deployment.Current.Dispatcher.BeginInvoke(() =>
I will create sample project (not sure if today, but definitely tomorrow) to reproduce this bug.
Sep 19, 2013 at 8:25 AM
So, I've created really simple project that demonstrates this issue. By default AdControl.Invalidate() method isn't called at startup and if you tap the screen you should see green text "Passed". If you uncomment AdControl.Invalidate() (it's in the GamePage code-behind) and try to tap - game will freeze.

Here is a link to the project:

P.S.: to be honest I saw green text once while AdRotator was working, but most of the time there is a freeze.
Sep 25, 2013 at 12:40 PM
Darkside, did you have a chance to take a look at sample project?
Sep 25, 2013 at 5:47 PM
Apologies, only just round to doing some AdRotator work today, will include it in the testing for the upcoming release
Sep 25, 2013 at 8:45 PM
Right, in the dev version I'm working on now the issue does not occur. Cannot say for sure why it is doing it in the current version unless it's something in the guts of WP.

I've known instances in the past where the dispatcher get confused when multiple events are firing but in timing, if you put a break point on the "waitEvent.Wait();" it took a couple of seconds to get there from tapping (with AdRotator enabled).

Probably will never get to the end of it but I have it working now.

Should have the new and improved (final) V1 NuGet out soon.
Sep 26, 2013 at 7:31 AM
Good news! Thanks. Looking forward to check that new version.
Sep 27, 2013 at 6:58 PM
The new NuGet package is now on dropbox if you want to test it

There seems to be an issue with uploading packages to NuGet at the mo, once that resolved I'll get them up

For now you can use them locally. If you check the instructions in that folder there is a section for how to do that if you are not familiar with it.
Oct 2, 2013 at 10:32 AM
Thanks a lot. I'll try it as soon as possible.
Oct 2, 2013 at 12:24 PM
So, I installed beta version of AdRotator, but I have a problem with Pub Center assemblies. It looks like AdRotator requires version 6.2.960.0 of Microsoft.Advertising.Mobile.UI. But after I installed latest Microsoft SDK I have only version 6.1.524.0. Any ideas where I can get assemblies with a correct versions?
Oct 2, 2013 at 1:45 PM
Edited Oct 2, 2013 at 1:46 PM
it should work with any version of the Ad SDK but the latest Microsoft Advertising SDK's can be found here:

Hope this helps

As a side note, we always recommend using the latest versions for any of the providers which are usually included in the NuGet for Windows Phone (although it's always worth checking as we only update in stages and now with every release from the providers)
Oct 2, 2013 at 1:49 PM
Okay, I managed to find those new assemblies - I didn't realize that they could put them to the different location.

But, it still doesn't work. I'm using same config file as I used in the previous version and after I call Invalidate() I've got this sequence of log messages:

Ads are enabled for display
Ads being requested for: None
No ads available, nothing to show
Ad control disabled

I see that you've changed type of DefaultSettingsFileUri property from Uri to string, so I'm not sure if I pass correct value there - "/assembly_name;component/defaultAdSettings.xml" (this is just the string I used to create Uri).
Oct 2, 2013 at 2:09 PM
Even if I set providers setting via AdControl properties I still get that message sequence. Interesting...
Oct 2, 2013 at 2:26 PM
It sounds like the AdControl is unable to start, usually this is caused by app permissions (or me :D)

The new default config file path hasn't changed of late but if you check the Readme-XAML.txt it has examples in there.
The path that did change was for local house ads, so you can map it in XAML using the notation "namespace.class name"

Also check the "build type" of the local config file, we have had some reports that the script alters it in some cases, ensure it is still set to "resource"
Oct 2, 2013 at 2:37 PM
Another thing to check is the new Microsoft control it'self

Add the control manually with your settings and see if you get an Ad, more often than not you don't get anything these days ;-(
Oct 2, 2013 at 2:47 PM
The problem was with Build action. As you said it looks like it was changed by the script. Thanks :)
Oct 3, 2013 at 9:02 AM
Unfortunately it's even worst with a preview version. For some reason while ads are switching touch becomes unresponsive (buttons that are drawn on the screen don't react on touch, but "hardware" back button works ok). After I reverted back to the current stable version of AdRotator everything is fine. Anyway, I have a workaround for the original issue, so for now it's more or less ok.
Oct 3, 2013 at 10:23 AM
That is interesting, certainly shouldn't be worse.
If you have reverted to the previous version be sure to update your Ad Provider DLL's as well to the current as the old package had very old DLL's released with it now.

Could you put together a simple test project to demo the effect?

With the two demo games we have published to the store, I didn't see any noticeable lag from the ads rotating so keen to figure this one out.
Oct 3, 2013 at 11:31 AM
I'll try to create a sample project as soon as possible.
Nov 20, 2013 at 7:12 AM

Start at the top of this thread, the deadlock you saw is caused by the BeginInvoke being invoked on the UI thread. when you do this in WP8 you get unpredictable results. You need to do dispatcher.CheckAccess() and if you need to do the invoke, do it, otherwise, just pass through to your action code. We found this when resuming on WP8 and trying to load a texture from a stream.
Nov 20, 2013 at 7:42 AM
Thanks Jake
We use check invoke already in AdRotator now but we have found it is not always reliable :D, so we now only use it on instantiation (first run) as in some test cases when an ad was refreshed the checkaccess came back with the incorrect response.
Nov 20, 2013 at 2:41 PM
Mr. Darkside, so how do you know CheckAccess is returning the wrong response?

I've found that WP8 tends to behave in a way that confounds my expectations. Sometimes it runs my game on a UI thread, and sometimes not. What I do know is that it looks like it is using a task pool, and when the pool is consumed entirely, it appears to use the UI thread for tasking.
Nov 20, 2013 at 2:56 PM
Was simply down to the fact that when we tried to interact with the visual tree after using check access, it would work the first time but subsequent times would just fail

Traced this down to the checkaccess function. It reported that code was on the UIThread when in fact it wasn't and caused the app to crash.
Very odd.
Nov 21, 2013 at 5:50 AM
Some components need to have tasks dispatched on their own dispatchers, and some on the default deployment dispatcher. Not all tasks can reliably run on the default dispatcher. We found this to be true in monoGame and cocos2d-xna. I wonder if you were experiencing a similar problem.