Vamos a iniciar una serie de artículos sobre desarrollo, aquí en WinTablet. De momento voy a escribirlos yo solo, así que tendrán bastante sesgo hacia Windows Phone, aunque intentaré también que sean válidos para Windows 8.

Siento que van a ser un poco hardcore o lo siguiente, pero lo que tengo claro es que no va a ser el típico artículo que te parafrasea la documentación.

Y para muestra un botón.

Estás tu tan rico resolviendo tus bugs, o picando código como un loco, o soltando unos cuantos WTF mirando tu propio código de la semana pasada y, de repente, te salta un

ExecutionEngineException

Y de ahí no pasas. Tu sesión de depuración se ha ido al garete, la aplicación deja de funcionar y se cierra. Si intentas capturar esa excepción, el sistema pasa olímpicamente de ti, incluso no pasa por el manejador unhandled.

Generalmente viene por rachas. Si tienes suerte no te llega a pasar nunca, pero otras veces está ahí sesión tras sesión y reinicio tras reinicio.

Tampoco es que puedas hacer mucho. Simplemente pasa sin ningún tipo de lógica pero, si estás de suerte, se suele disparar siempre en la misma línea de código… pero no son las más de las veces.

Y no, no es una ñapa de Microsft (bueno, sí, pero no porque no se pueda capturar ni nada de eso, es que no se puede hacer otra cosa). Esa excepción ocurre cuando la máquina virtual .NET que está ejecutando tu programa se ha ido al garete sin posibilidad de remisión. Y en los teléfonos a veces también se va el propio núcleo del teléfono, con lo que lo más idóneo después de una excepción de ese tipo es que lo reinicies. Y de paso Visual Studio, por si acaso. Y haz una build nueva.

Normalmente esa excepción se lanza debido a un bug interno de Microsoft, y la única salida honrosa es cerrarlo todo y salir. Con suerte el teléfono no se caerá. No me extrañaría que los cuelgues que había en Windows Phone 7.x y en las primeras versiones de Windows Phone 8 fueran por ese motivo. Porque supongo que recordaréis que a veces el terminal se quedaba pillado y la única solución era darle al botón de apagar hasta que se apagaba por las bravas. Cuando no se reiniciaba.

SI habéis tocado alguna vez C++, quizás hayáis experimentado un ICE (Internal Compiler Error). Tu estabas compilando y de repente el proceso se detenía por un error de este tipo. Lo que pasa aquí es parecido, salvando las distancias.

¿Cuándo me ha pasado a mi? Pues en situaciones de todo tipo. Desde un código en XAML representando una pantalla con una imagen de fondo y nada más, hasta dentro de un método lambda anónimo sincronizado con un TaskCompletionSource llamado desde otro lambda sincronizado con un monitor y accediendo de forma concurrente a una tabla, pasando por un simple Converter retornando un objeto de una colección…

En el primer caso tienes claro que no es culpa tuya con pocas comprobaciones, pero en el segundo no queda tan nítido ni de lejos y quizás, tras muchas horas de desesperación, descubras que la final no eras tu, sino el sistema.

Sí, ya sé, soluciones.

—

Pues depende de lo que estuvierais haciendo, pero vamos de más fácil a más difícil de solucionar.

1. Puntos de interrupción condicionales.
2. Demasiados puntos de interrupción.
3. Demasiado texto enviando a Debug.
4. Poca memoria libre para el depurador.
5. Demasiados hilos para el depurador.
6. Código demasiado complejo para el depurador.
7. Tu código no le gusta al motor de ejecución aunque sea correcto.

SI os fijáis, la mayoría de veces el problema está en la conjunción del depurador con tu código. Es mucho más probable que te pase con un Nokia 520 que con un 1520 porque el primero tiene mucha menos memoria y ancho de banda en el procesador, pero todavía es más probable que te pase en un HTC 8S es bastante más mierdoso que un 520. De hecho que no te extrañe que el 8S haga cosas muy raras. El terminal es malo tirando a peor para usarlo para desarrollo. La ventaja es que si algo funciona en él, funcionará en cualquier otro.

Por lo tanto, reduce el número de puntos de interrupción, si tienes condicionales quítalos, reduce el consumo de memoria de tu aplicación si puedes, y si no depúrala en un emulador y luego la ejecutas en el teléfono real sin él.

Los puntos 5 y 6 son relativos, ya que en general es difícil que le encuentres el fondo a Visual Studio, pero tenlos en cuenta para depurar esas partes por separado o sin el depurador.

Todos estos problemas vienen causados, o más bien supongo yo que vienen causados porque llega un punto en el que la comunicación entre el teléfono y Visual Studio se satura. O bien algo se ha roto dentro del IDE y deja de hacer las cosas bien, o bien la imagen que el entorno ha metido en tu teléfono está mal, o simplemente ha sufrido un empacho de información.

Sí, ya mayoría de problemas tienen una solución tan sencilla.

Nos queda el punto 7. En Windows Phone 8 y 8.1 no me ha pasado nunca, pero sí en 7.5 y su fantasticular Silverligh alias Flash Killer. La única solución a eso es la misma que ante un ICE: escribe tu código de otra manera.

Y con esto y un bizcocho, seguro que he hecho que te ahorres las horas un tocho.