WPF Errori applicazione e .NET Framework Riparazioni

Question

Sfondo: ho un Net 3.5 WPF "Prism" applicazione basata su esecuzione su Windows XP e Windows POSReady 2009 PC. L'app viene eseguita su PC che vengono spenti ogni notte (tramite una chiamata C# a "shutdown.exe") e avviati di nuovo al mattino (tramite Wake-on-LAN). L'applicazione è basata su touch (tramite touch screen ELO), non sono collegati mouse o tastiere e gli utenti non hanno accesso a Windows.

Problema: Abbiamo sporadicamente vediamo problemi in cui una delle due cose accade; l'applicazione non sembra caricarsi correttamente e vediamo un modulo bianco vuoto che mostra o smette di rispondere al tocco. Dalla ricerca nei nostri log (log4net) possiamo vedere che stiamo ancora gestendo gli eventi touch e li abbiamo registrati in entrambi i casi. Spesso questo sembra accadere quando si cambiano le viste e vediamo anche nei registri in cui il Prisma RegionManager sta rimuovendo e aggiungendo le viste in modo appropriato.

Risoluzione dei problemi: L'applicazione è in esecuzione su circa ~ 100 PC che utilizzano le immagini applicate con Clonezilla e questo si verifica solo sporadicamente. Dal momento che non sta accadendo su tutti i PC e non ci sono eccezioni registrate o qualcosa di indicativo di un problema nel Visualizzatore eventi, abbiamo fatto ricorso a più correzioni a livello di PC e OS. Nello specifico, abbiamo provato a riavviare l'applicazione e il PC con un successo occasionale a breve termine, il che significa che a volte l'applicazione funzionerà correttamente dopo questi riavvii, ma solo per una questione di ore al massimo. Abbiamo anche lavorato partendo dal presupposto che l'applicazione è stata in qualche modo danneggiata e che abbiamo rimosso e reinstallato, senza successo.

L'unica cosa che sembra risolvere il problema è una riparazione del framework .Net utilizzando il pacchetto .Net 3.5 SP1 Installer fornito.

Conclusione: Dal momento che questo sembra risolvere il problema quando niente altro lo fa, sembra che stiamo in qualche modo corrompere una dll quadro GAC'd - sia attraverso il codice o le procedure di avvio/arresto sul PC.

Domande: Questo porta ad una serie di domande:

• qualche idea su come possiamo identificare ulteriormente la fonte del problema?
• Qualche idea su cosa possiamo fare per prevenire questo problema?
• Qualche idea su quale potrebbe essere il problema di fondo?

Grazie per qualsiasi aiuto.

Answer 1

Siamo finalmente riusciti a ottenere una sospensione di una macchina di produzione che mostra questo comportamento e attraverso una serie di passaggi di risoluzione dei problemi, tra cui l'invio di file di dump a Microsoft, il problema è stato individuato.

Il servizio Windows Caching del tipo di carattere WPF si trovava talvolta in uno stato danneggiato, causando un blocco della richiesta di cache per un tempo indefinito. Questo blocco ha causato tutti i comportamenti descritti sopra nella nostra applicazione WPF.

Soluzione semplice: arrestare e disattivare il servizio. Dopo aver disabilitato il servizio e riavviato il PC, il servizio non è più in uso e non vediamo nessuno di questi problemi. In teoria questo porta a tempi di caricamento delle applicazioni più lunghi, ma abbiamo visto un impatto negativo zero.

Nota che ci sono due versioni del servizio: 3.0.0.0 e 4.0.0.0. Se la tua applicazione ha come target .Net 3.0 o 3.5, devi disabilitare il servizio 3 e, se scegli il targeting 4.0+, devi disabilitare il servizio 4.

Grazie a tutti per i vostri commenti e suggerimenti.

Answer 2

Abbiamo riscontrato problemi con la nostra applicazione WPF durante il collegamento di schermi tattili. Ciò era dovuto a un bug nel framework di automazione in .Net. Ha causato il rallentamento della nostra applicazione o l'interruzione del thread dell'interfaccia grafica.

Si può leggere di più circa il problema: http://social.msdn.microsoft.com/Forums/en-IE/windowsaccessibilityandautomation/thread/6c4465e2-207c-4277-a67f-e0f55eff0110

La soluzione suggerita nel thread sopra dove si toglie tutti i listener di eventi automazione periodicamente lavorato per noi.

Questa non è una risposta reale ma poiché non ho abbastanza rep?(Immagino) Non riesco a utilizzare la funzione di commento :)

Answer 3

Provare un errore globale e vedere cosa produce.

public partial class App : Application 
    { 
     [STAThread] 
     public static void Main() 
     { 
       var application = new App(); 

       application.DispatcherUnhandledException += 
        new DispatcherUnhandledExceptionEventHandler(application_DispatcherUnhandledException); 

       application.InitializeComponent(); 
       application.Run(); 
     } 

     static void application_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e) 
     { 
      LogAndClose("Global exception: " + e.Exception.ToString()); 
     } 

     public static void Log(string text) 
     { 
      try 
      { 
       System.IO.File.AppendAllText(Environment.CurrentDirectory + "\\Log.txt", 
        "[" + DateTime.Now.ToString("MM/dd/yy HH:mm:ss") + "] " + text + "\r\n"); 
      } 
      catch { } 
     } 

     public static void LogAndClose(string text) 
     { 
      Log(text); 

      try 
      { 
       Application.Current.Shutdown(); 
      } 
      catch { } 
     } 
    } 

Answer 4

Provare a utilizzare ANTS profiler per vedere se si dispone di una perdita di memoria. Puoi scoprirlo facilmente con solo la versione di prova di 2 settimane che danno.

Answer 5

Hai provato a distanza il debug del sistema di produzione?

Che cosa è necessario eseguire il debug remoto sono:

• implementare Msvcmon.exe
• connessione di rete tra il sistema di sviluppo e produzione
• assicurarsi che la versione locale e remota del codice sono in sincronia. È inoltre possibile creare sulla macchina di sviluppo e xcopy distribuire la build di debug sul computer remoto. Se è puro codice .net è facile. Se si dispone anche di codice C++, assicurarsi che le versioni di debug delle DLL C++ siano sul computer di produzione. Oppure, creare la versione di rilascio e il debug remoto.
• impostare un account utente utilizzato per la connessione. Questo è in realtà un po 'complicato. Google remote debugging credentials per alcuni suggerimenti.
• non dimenticare di disabilitare tutti i firewall!

È possibile allegare a un processo già in esecuzione, ma è anche possibile avviare l'app dall'interno di Visual Studio.

Se il sistema di sviluppo si trova lontano dal sistema di produzione, utilizzare un laptop e un desktop remoto per portare il proprio studio di sviluppo sul sistema di produzione. Lo faccio regolarmente. Anche una distanza di cinque metri tra i due è fastidiosa.

Posso approfondire questo argomento, se c'è interesse, o se ci si imbatte in problemi di configurazione della connessione.

Buona fortuna!