Domanda

Sto cercando di generare una build di rilascio per un'applicazione C ++ che ho scritto. L'applicazione funziona correttamente (debug e rilascio) quando lo si esegue da VS2008; ma quando esegui il file eseguibile si blocca quasi ogni volta.

Ora, c'è un hack in modo da poter eseguire questa applicazione come applicazione standalone senza dover scorrere tutto il codice e trovare il bug che lo sta causando?

Grazie in anticipo.

È stato utile?

Soluzione

In breve, no.

dovrai trovare il bug, se funziona all'interno di VS, quindi rischierei di indovinare che si tratta di un problema di temporizzazione, probabilmente stai sovrascrivendo i dati condivisi del thread, questo sarebbe meno probabile (anche se è ancora possibile vedi) all'interno di VS come viene eseguito in un ambiente di debug che lo rallenta un po '.

Se vuoi aiuto per trovare il tuo bug, allora dicci di più. Altrimenti, costruisci la tua versione con i simboli di debug (pdbs), installa DrWatson come debugger di sistema ed eseguilo da solo. Quando si arresta in modo anomalo DrWatson creerà un file minidump, lo caricherà in WinDbg (il mio preferito) e sarai in grado di vedere esattamente dove si trova il tuo bug (ti dirà anche che il dump contiene un'eccezione e te lo mostrerà per impostazione predefinita È necessario aggiungere il percorso e il percorso del codice sorgente ai simboli in WinDbg per farlo funzionare correttamente.

Quindi saprai anche come diagnosticare gli arresti anomali quando l'app viene eseguita anche sul posto.

Altri suggerimenti

Stai caricando risorse esterne? Se si verifica che i percorsi relativi siano corretti nel programma C ++.

Una possibilità è che il tuo programma utilizzi dati heap non inizializzati . L'avvio di un programma dal debugger abilita l'heap di debug NT, che fa sì che l'allocatore di heap riempia i nuovi blocchi di memoria con un modello di riempimento e consente anche un controllo dell'heap. L'avvio dello stesso programma dall'esterno del debugger lascia disabilitato l'heap di debug NT, ma se il programma era collegato alla versione di debug del runtime C, l'heap di debug CRT sarà comunque abilitato.

Una possibilità molto meno probabile è che il tuo programma richieda SeDebugPrivilege da impostare nel suo token di processo . Il debugger abilita questo privilegio nel suo token di processo, che ha l'effetto collaterale che tutti i programmi avviati dal debugger ereditano questo privilegio. Se il tuo programma tenta di utilizzare OpenProcess () / ReadProcessMemory () / WriteProcessMemory () e non gestisce correttamente gli errori, è possibile che potrebbe andare in crash.

Ci sono alcune possibilità. Oltre a quanto già menzionato, l'esecuzione di un'app da Visual Studio verrà eseguita nello stesso contesto di sicurezza dell'istanza di Visual Studio. Quindi, ad esempio, se stai lavorando su Vista, potresti provare a violare una violazione della sicurezza non gestita se stai tentando di accedere a file protetti o al registro.

Cosa succede se si crea una versione di debug e la si esegue autonomamente? Si schianta? In tal caso, di solito puoi entrare nel debugger da lì e ottenere uno stack di chiamate per vedere qual è il malfunzionamento.

Dai dettagli forniti, sembra che potrebbe esserci un problema con la libreria. Stai eseguendo il programma sullo stesso computer? In caso contrario, dovrai anche distribuire le librerie appropriate per la tua applicazione. Se si esegue sullo stesso computer ma al di fuori dell'ambiente di sviluppo, assicurarsi che l'applicazione possa vedere le librerie appropriate.

Il modo migliore che ho trovato per eseguire il debug in versione è creare un dump di arresto anomalo quando si verifica un incidente e il dump mi consente quindi di caricare i simboli di debug sul mio computer di sviluppo e scoprire cosa sta succedendo. Maggiori informazioni qui: http://www.debuginfo.com/articles/effminidumps.html

Puoi anche andare su file = > apri Visual Studio e apri il file .exe, quindi non lo avvierai dal debugger di per sé. Non sono sicuro che possa aiutare.

http://blogs.msdn.com/saraford/archive/2008 / 08/21 / fatto-si-sa-you-can-debug-an-eseguibile-che-ISN-ta-parte-di-un-visual-studio-progetto-senza-con-tools-attach-to-processo -296.aspx

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top