DynamoDS/Dynamo — pull request #2534 by Benglin (2014-09-26 05:50:10+00:00)
Title: Fixed: Dynamo crash scenarios not being tracked

Problem
-----

Hi @lukechurch, you asked me (in [another pull request](https://github.com/DynamoDS/Dynamo/pull/2477)) to ensure that ```StabilityTracking``` properly logs all unhandled exceptions in Dynamo, and then I noticed this issue -- crashes on the UI closes down Dynamo without a crash dialog, and all without ```StabilityCookie.WriteCrashingShutdown``` method being called at all. This means unhandled crashes are not even being tracked, resulting in them being logged as ```assumed crashing``` scenario without a proper exception name.

```StabilityCookie.WriteCrashingShutdown``` method will be called when ```DynamoModel.IsCrashing``` is being set to ```true```, but in this scenario, ```DynamoModel.IsCrashing = true``` cannot be reached:

```cs
class Program
{
public static void Main(string[] args)
{
try
{
// Crash occurs in this method without returning...
viewModel = MakeStandaloneAndRun(commandFilePath);
}
catch (Exception exception)
{
try
{
// 'viewModel == null', where 'NullReferenceException' occurs.
viewModel.SaveRecordedCommand.Execute(null);

// This is where we set the flag to true (never executed).
DynamoModel.IsCrashing = true;
}
catch
{
}
}
}
}
```

Solution
-----

The fix is obviously to allow ```viewModel``` to be set before ```MakeStandaloneAndRun``` returning. This is desirable even not for the case of crashing, simply because ```app.Run(view);``` call in ```MakeStandaloneAndRun``` will not return until user closes Dynamo, having the method return ```DynamoViewModel``` looks more like a design problem.

This seems to be the case for a long while now, unfortunately until this is deployed, we will be getting ```ASSUMING_CRASHING_SHUTDOWN_VALUE```.