Pregunta

Estoy tratando de generar una versión de lanzamiento para una aplicación C ++ que he escrito. La aplicación funciona bien (depuración y liberación) cuando la ejecuta desde VS2008; pero cuando ejecuta el ejecutable se bloquea casi cada vez.

Ahora, ¿hay algún truco para poder ejecutar esta aplicación como una aplicación independiente sin tener que ejecutar todo el código y encontrar el error que lo está causando?

Gracias de antemano.

¿Fue útil?

Solución

En resumen, no.

tendrá que encontrar el error, si funciona dentro de VS, entonces me arriesgaría a suponer que es un problema de tiempo, posiblemente esté sobrescribiendo datos de hilos compartidos, esto sería menos probable (aunque aún es posible ver) dentro de VS ya que se ejecuta en un entorno de depuración que lo ralentiza un poco.

Si desea ayuda para encontrar su error, díganos más. De lo contrario, cree su versión con símbolos de depuración (pdbs), instale DrWatson como depurador del sistema y ejecútelo de forma independiente. Cuando se bloquea, DrWatson creará un archivo de minivolcado, cárguelo en WinDbg (mi favorito) y podrá ver exactamente dónde está su error (incluso le dirá que el volcado contiene una excepción y lo mostrará por defecto Necesita agregar su ruta de código fuente y ruta a sus símbolos en WinDbg para que haga esto correctamente).

Entonces también sabrá cómo diagnosticar fallas cuando la aplicación también se ejecute en el sitio.

Otros consejos

¿Estás cargando recursos externos? Si verifica que sus rutas relativas sean correctas en el programa C ++.

Una posibilidad es que su programa use datos de almacenamiento no inicializados . Al iniciar un programa desde el depurador, se habilita el montón de depuración de NT, lo que hace que el asignador de montón llene nuevos bloques de memoria con un patrón de relleno, y también permite algunas comprobaciones de montón. El lanzamiento del mismo programa desde fuera del depurador deja deshabilitado el montón de depuración NT, pero si el programa se vinculó con la versión de depuración del tiempo de ejecución C, entonces el montón de depuración CRT todavía estará habilitado.

Una posibilidad mucho menos probable es que su programa requiera SeDebugPrivilege que se establecerá en su token de proceso . El depurador habilita este privilegio en su token de proceso, lo que tiene el efecto secundario de que todos los programas iniciados desde el depurador heredan este privilegio. Si su programa intenta usar OpenProcess () / ReadProcessMemory () / WriteProcessMemory () y no maneja los errores correctamente, es concebible que podría bloquearse.

Hay algunas posibilidades. Además de lo que ya se ha mencionado, ejecutar una aplicación desde Visual Studio se ejecutará en el mismo contexto de seguridad que la instancia de Visual Studio. Entonces, si, por ejemplo, está trabajando en Vista, es posible que se encuentre con una violación de seguridad no controlada si está intentando acceder a archivos protegidos o al registro.

¿Qué sucede si crea una versión de depuración y la ejecuta de manera independiente? ¿Se estrella? Si es así, generalmente puede ingresar al depurador desde allí y obtener una pila de llamadas para ver cuál es el mal funcionamiento.

De los detalles que ha proporcionado, parece que puede haber un problema con la biblioteca. ¿Estás ejecutando el programa en la misma computadora? De lo contrario, también deberá implementar las bibliotecas adecuadas para su aplicación. Si está ejecutando en la misma computadora pero fuera del entorno de desarrollo, asegúrese de que su aplicación pueda ver las bibliotecas apropiadas.

La mejor manera que he encontrado para depurar en el lanzamiento es crear un volcado de bloqueo cuando ocurre un bloqueo y el volcado me permite cargar símbolos de depuración en mi computadora de desarrollo y descubrir qué está pasando. Más información aquí: http://www.debuginfo.com/articles/effminidumps.html

También puede ir a file = > abra en Visual Studio y abra el .exe, por lo que no lo está iniciando bajo el depurador per se. No estoy seguro si ayudará.

http://blogs.msdn.com/saraford/archive/2008 / 08/21 / did-you-know-you-can-debug-an-ejecutable-that-isn-ta-part-of-a-visual-studio-project-without-using-tools-attach-to-process -296.aspx

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top