Cómo garantizar el ahorro del estado de aplicación en el bloqueo C#

Question

Soy muy nuevo en la programación de C#, así que eso en mente:

Tengo un objeto de datos en memoria con datos, necesito guardar la información cuando (si) mi aplicación debía bloquearse o cerrarse. ¿Hay alguna manera de hacer esto de manera determinista o confiable?

He estado mirando los destructores

~MyObjectName(){}

finalizadores y desechar (),

¿Pero por lo que entiendo, ninguno de estos hará de manera confiable lo que quiero?

Actualmente estoy usando el Destructor, y funciona cuando estoy cerrando el programa, pero esto no significa que funcione en bloquear o siempre.

¿Debería estar mirando los eventos también?

Answer 1

Hay no Mecanismo 100% confiable que puede usar para guardar datos (o hacer cualquier otra cosa para el caso) cuando un proceso (cualquier proceso, no solo un proceso de .NET) termina: la mayoría de los procesos se pueden terminar en cualquier punto utilizando el "proceso final" Opción En el administrador de tareas, cuando esto sucede, el proceso se mata inmediatamente. Como un ejemplo más extremo, el cable de alimentación podría extraerse por la parte posterior de la máquina.

Si no es 100% necesario que este objeto de datos esté actualizado y guardado una vez que se mata el proceso, entonces el Appdomain.unhandledException Event puede ser suficiente.

Si es absolutamente 100% necesario que este sea el caso, entonces debe guardar continuamente esta información, ya que el proceso se está ejecutando: no hay absolutamente ningún guarENTE de que tenga la oportunidad de hacerlo en una fecha posterior. Así es como funcionan las bases de datos, no se devuelve la transacción hasta que se haya registrado algún registro del cambio en el disco en algún formato (por ejemplo, un registro de transacciones). Esto es lo que representa la D en ÁCIDO.

Answer 2

¿Creo que estás buscando capturar excepciones no controladas? algo como esto:

static void Main()
{
  Application.EnableVisualStyles();
  Application.SetCompatibleTextRenderingDefault(false);

  Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
  AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

  Application.Run(new Form1());
}

static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
{
  MessageBox.Show(e.Exception.Message, "Unhandled Thread Exception");
  // here you can log the exception ...
}

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
  MessageBox.Show((e.ExceptionObject as Exception).Message, "Unhandled UI Exception");
  // here you can log the exception ...
}

Este ejemplo muestra cómo administrar todas las excepciones que no han sido atrapadas en las secciones de captura de try (en la aplicación de formularios de Windows).

El evento de no handledException maneja las excepciones no capturas lanzadas desde el hilo de la interfaz de usuario principal. El evento ThreadException maneja las excepciones no capturas lanzadas de hilos que no son UI.

Answer 3

Puedes lograr esto con WindBG.

1. Mantener una punto de ruptura En el método ZWMinateProcess en WindBG. Este método se llamará cuando salga su aplicación.
2. Cuando se alcanza el punto de interrupción, use! MyObjectName de tipo Dumheap para obtener la dirección de su objeto
3. Use! DumpObject "Dirección de MyObjectName" para conocer los valores dentro del objeto