excepciones extrañas en código marco .Net CF bajo mueca de dolor 6.0 R3

Question

En nuestra aplicación .Net CF que se producen errores extraños de las partes del código que no debe ser teniendo problemas. Por ejemplo, el código siguiente:

public void AddParm(string str)
{
    string[]        pair = str.Split('=');
    string          key = pair[0].Trim();
    string          value = pair.Length > 1 ? pair[1] : "";
    if (key.Length > 0)
    {
        if (_parmTable.ContainsKey(key))
            _parmTable[key] = value;
        else
            _parmTable.Add(key, value);
    }
}

La rutina que llama AddParm () envuelve la llamada en un bloque Try ... Catch, la captura de todo tipo de excepción.

public void Unpack(string txn)
{
    try
    {
        // split out strings like: "EVENTLABEL:x=1,y=2,z=3"
        char chEvent = ':';
        char chSeparator = ',';

        _parmTable = new Hashtable();

        int iEvent = txn.IndexOf(chEvent);

        if (iEvent == -1)
            _eventLabel = txn;
        else
        {
            _eventLabel = txn.Substring(0, iEvent);

            string parms = txn.Substring(iEvent + 1).TrimEnd('\n');
            string[] items = parms.Split(chSeparator);

            if (items.Length <= 0)
                AddParm(parms);
            else
                foreach (string item in items)
                    AddParm(item);
        }
    }
    catch (Exception ex)
    {
        AppLog.logException(string.Format("UnpackedTask.Unpack: Error parsing '{0}'", txn), ex);
    }
}

acabo de recibir una excepción no controlada núcleo lista del módulo de fallas como mscoree3_5.dll. El seguimiento de la pila muestra:

at ArrayList.InternalSetCapacity(Int32 value, Boolean updateVersion)
at ArrayList.EnsureCapacity(Int32 min)
at ArrayList.Add(Object value)
at String.Split(Char[] separator)
at AddParm(String str)

Esto está sucediendo en un subproceso de trabajo.

Yo registrar un controlador con AppDomain.CurrentDomain.UnhandledException en principal pero no captura la excepción tampoco.

Por desgracia, la mueca de dolor de diálogo de error que aparece no indica el tipo de error o un mensaje de error, al igual que lo fue en mscoree3_5.dll y el seguimiento de la pila.

Creamos los valores que consiguen procesan mediante AddParm y creo que es lo suficientemente AddParm que sería detectar problemas potenciales antes de la llamada de Split defensiva. Debido a la forma AddParm se llama no volvería a ser llamada con una cadena nula. A pesar de que no creo AddParm jamás podría ser llamada con algo que no es válido, el Try ... Catch envolver la llamada siempre debe detectar la excepción pero no lo hace.

Del mismo modo, también hemos visto errores no capturados de esta manera:

A native exception has occurred on BbCore.exe

At RuntimeType.InternalGetField(rt…)
At RuntimeType.InternalGetField(rt…)
At SRSupport.GetString()
At SRSupport.GetString()
At IPAddress.Parse(String ipString)

Aquí hay una traza completa de uno de esta mañana:

At CurrentSystemTimeZone.GetDaylightChanges(Int32 year)
At CurrentSystemTimeZone.GetUtcOffsetFromUniversalTime(DateTime time, Boolean& isAmbiguousLocalDst)
At CurrentSystemTimeZone.ToLocalTime(DateTime time)
At DateTime.ToLocalTime()
At DateTime.get_Now()
At MainLoop.timer1_Tick(Object sender, EventArgs e)
At Timer._WnProc(WM wm, Int32 wParam, Int32 lParam)
At ApplicationThreadContext._InternalContextMessages(WM wm, Int32 wParam, Int32 lParam)
At NativeMethods.GetMessage(MSG& lpMsg, IntPtr hWnd, UInt32 wMsgFilterMin, UInt32 wMsgFilterMax)
At Application2.Pump()
At Application2.RunMessageLoop(Boolean showForm)
At Application2.Run(Form mainForm, Boolean runAsSingletonApp, Boolean displayMainForm)
At Startup.Main()

Las referencias Application2 se deben al uso de OpenNetCF.Windows.Forms.dll. Nunca he visto un accidente en esa parte del código, que es básicamente aleatoria.

Este es otro caso en el que IPAddress.Parse se llama desde dentro de un try ... catch que atrapa todo tipo de excepción. En ese caso, creo que era posible para Analizar para ser llamado con una cadena vacía, pero no entiendo por qué se presentó como una excepción no controlada y ni siquiera quedar atrapados por nuestro manejador de excepción no controlada, pero en lugar quedó atrapado por el WindowsCE gestor de excepciones e hizo que toda la aplicación se bloquee.

Parece que estos son más comunes desde que actualizamos a la mueca de dolor 6 R3 constructor plataforma desde la R2. No estoy seguro de si alguna vez sucedió bajo R2 pero ciertamente fueron menos frecuentes. Incluso ahora que no siempre suceden -. No puedo reproducir de forma fiable ellos

¿Alguna idea? ¿Por qué las partes centrales del marco tirar errores que no queden atrapados por try..catch?

Información adicional: Parece que me fui a cabo una pieza crítica de información. El ExceptionCode aparece como 0x80000002 que parece ser un nativo de excepción de memoria. De acuerdo con el recolector de basura nuestra aplicación rara vez se utiliza más de 1 MB de memoria. De acuerdo con GlobalMemoryStatus de coredll.dll la carga de memoria típica del sistema es de aproximadamente 29% (41MB libres de 57MB). ¿Hay buenas utilidades por ahí que podría ser capaz de controlar y registrar el uso total de memoria del sistema con el tiempo? Estoy empezando a preguntarse si las técnicas que estoy usando para medir el uso de memoria no son tan precisos como pensaba. Usando OpenNetCF.ToolHelp.ProcessEntry.GetProcesses () muestra nuestro proceso utilizando aproximadamente 3,6 MB y Nk.exe utilizando aproximadamente 2,5 MB.

Answer 1

Resultó que era un error de desbordamiento del búfer en el código nativo. el # código C estaba llamando a un método y pasando una matriz de bytes con 8 elementos. El código C ++ fue llenado 6 bytes entonces sobreescritura otro 6 con ceros. Este método fue llamado mucho y cada vez que se sobrescribe 4 bytes de la memoria con ceros. Doh!

Eso explica los errores completamente extrañas, probablemente fue sobrescribir los bits de .NET Framework en la memoria.

Tengo que mirar hacia fuera para esas interacciones entre el código administrado y no administrado. Afortunadamente para mí, el código en cuestión no era la mía.

(No estoy seguro si debo aceptar mi propia respuesta como la respuesta ya que nadie podría haber respondido a esta sin mirar a nuestra base de código. Del mismo modo que no debería marcar la respuesta de JaredPar como "la respuesta" ya que el problema era de corrupción de memoria, . no es realmente una excepción nativa creo que voy a publicar esto de todos modos ya que tal vez alguien más tendrá una situación similar y tal vez van a estudiar las interacciones con código nativo Administradores:. dude en suprimir este hilo si usted piensa que es lo mejor).

Answer 2

Creo que el mensaje en su segundo trazo es el más instructivo

  

A excepción nativa se ha producido en BbCore.exe

Parece que no es una excepción nativa una excepción conseguido que se está llevando abajo de su producto. excepciones nativas son, por regla general, no capturable por el código administrado. Es posible en algunos casos, pero en términos generales excepciones nativas son fatales.

Se puede tratar de utilizar el bloque de captura de excepciones SEH y ver si funciona.

try { 
  ...
} catch { 

}

Pero, en general, si el código nativo está lanzando su aplicación es inestable y debe bloquearse.

Answer 3

Yo sólo se encuentra con este error en una nueva versión de mi aplicación. Intentado varias cosas, en el pasado, me quitaron los 256x256 y 64x64 imágenes en el icono de forma que se sustituyen en esta versión, y funcionó.