Stiamo avendo System.AccessViolationException non deterministico generato da codice nativo. È difficile riprodurlo, ma a volte succede. Non sono sicuro di poter eseguire "il debug" solo perché il tempo necessario per la violazione dell'accesso è di circa 2 ore e non vi è alcuna garanzia che la violazione dell'accesso si verifichi.Determinare il motivo di System.AccessViolationException
La libreria nativa viene utilizzata dai wrapper gestiti. Viene utilizzato da java a JNI e viene utilizzato da .NET attraverso JNI di IKVM. Il problema è stato riprodotto solo durante il codice di IKVM, ma i set di dati sono diversi e non c'è modo di testare l'applicazione java con i dati utilizzati dall'applicazione di IKVM.
Ho fonti per tutto, ma (se possibile) voglio evitare di fare un gran numero di modifiche.
Credo che lo stack di chiamate native fornisca informazioni sufficienti sulla ragione di questa violazione di accesso.
Esistono modi efficaci per determinare il motivo di questa violazione di accesso?
Penso che la soluzione ideale per me sia qualche modifica nel codice o nell'ambiente di processo, quindi si bloccherà con il dump della memoria in caso di questa violazione di accesso, quindi posso apportare tali modifiche e semplicemente aspettare.
Hm .. Ho modificato il mio codice nativo in modo che abbia sicuramente una violazione di accesso e ricompilato con i simboli di debug. Quando ho avviato il processo normalmente e ho collegato il debugger di Visual Studio. Ho aggiunto un punto di interruzione per il lancio di AccessViolationException, ma non è stato rilevato. Eventuali suggerimenti? – okutane
OK, mi sono trovato che il punto di interruzione dovrebbe essere violazione di accesso Win32. – okutane