Flurry analytics crashing with Windows Phone 7

Question

I've integrated Flurry (http://www.flurry.com/) into my phone 7 app. The only code needed is this line in application launching

FlurryWP7SDK.Api.StartSession(ApiKeyValue);

However, as soon as that line is hit the application crashes with a KeyNotFoundException. The stack trace is included below. It appears to be querying isolated storage settings and failing when the key doesn't exist.

Does anyone have any experience with this error or even successfully integrating flurry into a Phone 7 app?

at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(String key)
at System.IO.IsolatedStorage.IsolatedStorageSettings.get_Item(String key)
at A.ca98fb38190f0d5cad84c67a779d17229.c204dba68825403c905efd7bfd067b17b(String ce0360de492f1f363775feaf6d6a8ced5, Object c8d4be677f7ee63f6756e13f285072523)
at A.c3f1105d518a239d73e2236200494de25.set_cfca54db015a16ab23de44b4d5c65e9a3(String c8d4be677f7ee63f6756e13f285072523)
at FlurryWP7SDK.Api.StartSession(String apiKey)
at AppName.App.Application_Launching(Object sender, LaunchingEventArgs e)
at Microsoft.Phone.Shell.PhoneApplicationService.FireLaunching()
at Microsoft.Phone.Execution.NativeEmInterop.FireOnLaunching()

---

Edit

After discussions with Flurry support it appears that the KeyNotFoundException is caught by Flurry code. However if your debugger settings are to break when the exception is thrown you will break into the debugger regardless. Continuing execution will then work because the exception is caught and handled by Flurry.

I can't verify that this is the solution because I no longer have access to the dev environment that was indicating the error, but it appears to be a likely solution.

Answer 1

I work for Flurry. We have many successful deployments on the Windows 7 platform. You and Buju may be experiencing an emerging issue that has not come to our attention previously. Please email [email protected] as the diagnosis may involve discussing account specific details. Once we determine the underlying cause we can post back to this thread so the community has the benefit of our investigation. Thanks for working with Flurry.

Edit

I just wanted to follow up on Mac's comment as the KeyNotFoundException may manifest in two ways during debugging. As Mac noted we do caputure the KeyNotFoundException, however, the debugger sees the exception first before we can handle it within our library. The debugger's behavior is dictated by the setting in Debug > Exceptions.

If the checkboxes under Thrown are selected the program will be stopped and the stack trace above will be output. If the checkboxes under Thrown are not selected the output will generate an error like the following:

A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll (this is the message Buju received)

The program will continue following this message as it just serves as a notice that an exception occurred somewhere within the program. More information on first chance exceptions can be found in the following articles:

What is a first chance exception - http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx

How to handle (disable) first chance reporting - http://www.helixoft.com/blog/archives/24