Attualmente sto eseguendo il debug di un gioco molto vecchio (quindi non c'è un supporto clienti) che continua a bloccarsi in determinate condizioni e ho scoperto che è perché la conversione da unsigned short a unsigned è avvenuta con la conversione firmata (possibilmente codice simile a "short int x = 0x8000; unsigned int y = (unsigned int) x" che porta a y = 0xffff8000 invece di 0x00008000)
Ora devo eseguire il debug del gioco nel codice di disassemblaggio per scoprire tutto il comando movsx che esegue la conversione sbagliata e cambiarli in comando movzx (ci sono molti punti in cui la conversione firmata è corretta, quindi non posso semplicemente cambiare tutti i movsz in MOVZX).
Il problema è che quando mi trovo su un frame in crash (dove un'altra funzione tenta di accedere all'indirizzo 0xffff8000, ad esempio), la funzione di arresto anomalo potrebbe essere a miglia di distanza dal codice movsx originale che esegue la conversione. La funzione di arresto anomalo (e i relativi chiamanti) viene chiamata migliaia di volte, quindi non è possibile inserire un punto di interruzione prima di un certo punto e vedere come cambia il valore del registro. Sembra che, ogni volta che eseguo il programma, l'indirizzo dello stack sia diverso dalla precedente, quindi i punti di interruzione dei dati non funzionano anche perché non conosco l'indirizzo da interrompere prima che si verifichi l'arresto anomalo.
Ho bisogno di un buon metodo (un modo che abbia il 100% di possibilità di trovare il bug in un tempo relativamente costante) per scoprire quando il valore 0xffff8000 viene inserito nello stack. Se qualcuno con esperienza nel debug di asm può darmi alcune tecniche per ottenere questo, lo apprezzerò molto.
EDIT: (Sebbene la domanda nel titolo non sia ancora stata risolta, le seguenti informazioni che ho trovato, che mi aiutano a correggere lo scenario specifico, potrebbero essere utili a qualcuno in futuro)
Ho scoperto che Visual Studio fornisce talvolta lo stack di chiamate errato. Sembra trovare il callstack basato sulla ricerca del valore del puntatore dello stack, quindi se una funzione inizia con qualcosa come "sub esp, 2Ch", allora il callstack sarà rovinato.
Per eseguire il debug di questo problema, è necessario impostare manualmente un punto di interruzione prima dell'arresto anomalo, a condizione che il registro abbia il valore sbagliato e, quando viene raggiunto, è necessario modificare manualmente il registro sul valore corretto; dopo di che esegui la funzione fino alla fine e vedi dove ritorna.