Flurry analytics crashing with Windows Phone 7 - windows-phone-7

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.

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 winmosupport#flurry.com 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

Related

Can I disable the unhandled exception handler for a process?

I am performing system tests on a SAP system. From time to time, SAP crashes and I'd like to recover from those crashes by resetting the virtual machine to a previously saved state.
My problem is that I cannot detect such crashes reliably. I have created WER LocalDumps registry entries, but I don't get dumps.
It seems SAP has registered an unhandled exception handler and performs different tasks on different types of exceptions. Sometimes it shows a message box and terminates the application (e.g. in case of compression errors), sometimes it goes with a so-called Short Dump.
I am neither interested in the message box, nor in the short dump, so I am looking for a way to disable the unhandled exception handler of SAP. This should bring up WER, which writes the dump file and I can take actions to restart my system tests.
For performance reasons, I'd not like to restart the VM on every test.
I have tried:
I am basically familiar with unhandled exception handlers. I have applied them to my own .NET code successfully.
I looked at SetUnhandledExceptionFilter (MSDN) and similar but it applies to the calling process only and I cannot modify the code of SAP.
I read about DisableUserModeCallbackFilter but I don't think it is helpful for my case
I wonder whether there is a Registry Setting (e.g. in ImageFileExecutionOptions) or a Shim that I could activate.
According to Hans Passant's comment (which I take as an authorative answer),
There is no boss override switch built into the operating system to stop it from doing this.
I finally attached the debugger to SAP GUI at a time where the process was alive. Starting with all exceptions enabled, I narrowed down the conditions so that WinDbg would break when SAP GUI crashed (first chance, then second chance).

SEHException in VS2010 (and above) but only on .NET4 or higher on Windows 7

My company finally upgraded our development team from Windows XP to Windows 7 64-bit computers and I just discovered an odd error with existing code in the new environment. The project in question references a COM library that's used to interact with our document image management system. Any attempt to initialize an instance of this API's Library class is now throwing an SEHException. The error code returned has not been informative. Here is the full Exception from a stripped-down sample project I wrote to test this problem:
System.Runtime.InteropServices.SEHException was caught
ErrorCode=-2147467259
HResult=-2147467259
Message=External component has thrown an exception.
Source=FileNetTestLib
StackTrace:
at FileNetTestLib.Library.Logon() in C:\Projects\Tests\SEHException\FileNetTestLib\Library.vb:line 4
at SEHException.Form1.btnLogIn_Click(Object sender, EventArgs e) in C:\Projects\Tests\SEHException\SEHException\Form1.vb:line 7
InnerException:
While working with my sample project I was able to confirm the following:
The Exception only occurs when debugging; running without debugging does not throw any exception
The Exception DOES NOT occur when debugging on Windows XP (tried on two Win7 and two XP computers)
The Exception DOES NOT occur when we change the target framework to anything lower than .NET 4. It only occurs on .NET4 or higher.
So to summarize, the error occurs if we are debugging on Windows 7 targeting .NET4 or higher. It does not occur if we change any one of these factors.
In researching this I discovered that .NET4 changed its security model for how it handles exceptions thrown from non-managed code. It looked at first like this might relate to the issue, but from what I've managed to learn so far, the changes affect only a subset of SEHExceptions and apparently not the one I am getting because (1) I am able to catch the SEHException in a try...catch block where the change in .NET causes the affected exceptions (corrupted state exceptions) to not be caught by .NET at all unless you make certain changes to your code or config file (which I have not made and have confirmed are not present in my project) and (2) the problem is only occurring for me under Windows 7 and I haven't found anything to indicate that these changes in .NET4 were Win7-specific.
FYI, I don't have a 32-bit version of Win7 so I can't confirm if the issue is specific to Win7 64-bit or Win7 in general. I AM compiling the project as x86 since I cannot compile it as x64 due to the COM component. I have also tried this on VS 2013 as well as VS 2010 and get the same results on both.
Since the problem only occurs while debugging I checked which Exceptions I am allowing the debugger to break on (hoping it was selected and I could just uncheck it to get the debugger to ignore it) and SEHExeption is unchecked (under Debug|Exceptions). I also checked the Debugging options in VS and "Break when exceptions cross AppDomain or managed/native boundaries" is unchecked. Changing either of these has not made a difference.
I also tried initializing a completely different COM component (ImageMagick, in this case), to make sure the error wasn't occurring for ANY COM component but I did not encounter any problems with that. I am about to contact the vendor of the COM component that is causing an issue for me, but I was wondering if anyone else has encountered any similar problem with other COM components and if so if there's a way to prevent or ignore these types of errors when debugging since the error only appears to be generated as a result of running in the debugger.

Why would an application popup an error, "Control doesn't have parent window," after running for 3 weeks?

I have been running an application developed under Windows 7 in Delphi XE on Windows 7 machine for about 3 weeks non-stop, but it stopped working after that and popped up a message box with "Control doesn't have parent window." After that nothing seem to work right in the software, unless it is shutdown and restarted.
I have an idea of what that error means, but I am trying to figure out. Why?
Any hints or suggestions will be greatly appreciated. Thank you.
Sign of a resource leak, window handles most likely. Diagnose with TaskMgr.exe, Processes tab. View + Select Columns and tick Handles, USER Objects and GDI Objects. Keep on eye on the values for your program while you are using it. A steady increase spells trouble, Windows stops giving more after 10,000.
If that doesn't help then improve your exception handling so you can get a better diagnostic, a stack trace is important to diagnose trouble like this.
You should install a copy of MadExcept, JclExcept, or other exception handling library that supports displaying/logging the call stack when an uncaught exception is raised (if you cannt reproduce the exception while running inside the IDE debugger, that is). Then you can figure out what your app was trying to do at the time of the exception, and hopefully narrow it down to the spot in your code that is accessing the specific UI control that is missing its Parent window.

Detect/Redirect core dumps (when a software crashes) on Windows

For my work, I need to create a service that will detect an abnormal program termination and, instead of displaying a message to the user (default behavior), send the generated core dump to a remote server.
I'm pretty sure this can be done, but I have absolutely no clue on where to start. Is there any API/registry settings for this ?
Thank you.
One method is to install an Unhandled Exception Filter and then write a minidump from it which you can then upload to some place of your choosing. I wouldn't totally disregard Windows Error Reporting -- that's an addition to any crash reporting of your own. If your application is for public release then registering for Windows Error Reporting is well worthwhile as you get information about which crashes users are encountering in the wild and when crashes have been fixed you can add a response code to point them to a new version or other relevant information.
Another tool that may be useful depending on how your application is deployed in your organisation is to run Adplus on a user's machine which will collect together crash dumps. This is more useful for one-off crashes that seem to affect an individual user but aren't reproducible in a development environment.
Some other useful links:
http://www.debuginfo.com/articles/effminidumps.html - some useful sample code
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
It seems my question was either obvious or stupid (both ?) but anyway, i found some interesting pages after some researches.
Here are the links I found useful:
Track application crashes and disable Windows Error Reporting at the same time!
Disable error reporting

Disabling Windows error reporting (Dr. Watson) for my process

I have an application that is hosting some unstable third-party code which I can't control in an external process to protect my main application from nasty errors it exhibits. My parent process is monitoring the other process and doing "the right thing (tm)" when it fails.
The problem that I have is that Dr. Watson is still detecting crashes in the isolated process and attaching to the processes on the way down to take a crash dump. This has the two problems of:
1. Dramatically slowing down the time that it takes for me to detect a failure because the process stays alive while the crash dump is being taken.
2. Showing annoying popups to the user asking if they want to submit the error reports to Microsoft.
Clearly I would prefer to fix the bugs in the child process, but given that it isn't an option, I would like to be able to selectively disable Dr. Watson (and Windows Error Reporting in Vista+) for that process.
I am running some of my own code in the process before handing off to the untrusted bit, so if there is an API that I can call that affects the current process that would be fine.
I am aware of: http://support.microsoft.com/default.aspx/kb/188296 which would disable Dr. Watson for the entire machine. I don't want to do that because it would make me a bad citizen to trash a machine-wide setting.
I am also aware of the WerSetFlags option in Vista+ that would seem to disable windows error reporting for the current process, but I need something that will disable Dr.Watson on earlier OS versions.
The good doctor is invoked when a process does not handle a certain exception. Therefore, the common way to go would be to handle all exceptions yourself. In your case, it is much harder since you don't own the crashing process code. What you can do then, is to inject your code into the other process at runtime, and install an exception handler that will swallow the exception causing the crash. When caught, gracefully shut down the process.
There are quite a few questions here talking about injecting code into another process. As for the crash handler, you can either set an unhandled exception filter, or add a vectored exception handler. Note that for the latter, you'll have to be careful not to swallow legit exceptions that are in fact handled inside the other process, namely find a way to recognize the crashing exception and make sure it is the only one you handle.
You want to disable the GPF popup: http://blogs.msdn.com/oldnewthing/archive/2004/07/27/198410.aspx

Resources