Enjay wrote:I could get the game to crash then screenshot the contents of the microsoft crash report window
You're compiling your own builds. That means you have access to the debugger, so you should run the program from inside there, and it will break on the exact line where the error occurred. No need to guess where it's happening. (In this case, it's memory corruption that is caught while freeing memory.)
To set up the arguments for debugging, right click on the zdoom project from Solution Explorer and edit its Properties:
- step1.png (7.12 KiB) Viewed 639 times
Then make sure the Working Directory is set to $(TargetDir) and set whatever Command Arguments you want to test with.
- step2.png (13.1 KiB) Viewed 639 times
After you hit OK, you can then debug it by pressing F5 (or choosing Start Debugging from the Debug menu).
Alternatively, you can also run the debug build outside the debugger and then attach the debugger after it crashes. In this case, running inside the debugger caused it to crash at exit rather than right away (probably because Windows adds extra info to the memory blocks when it sees that it's being run inside a debugger, so the corruption is in a different place), so I can run it outside the debugger and then choose to debug it once it crashes:
- This screenshot is for Vista, but XP gets a Debug button added to its crash window, too.
- step3.png (6.89 KiB) Viewed 639 times
This pops up a list of possible Visual Studio instances you can attach to it. Since I already have the ZDoom project open, I choose that one:
- step4.png (5.5 KiB) Viewed 639 times
After you break into it with the program, it tells you the error that occurred and marks the line as close to the error point as it has source code for:
- step5.png (8.11 KiB) Viewed 639 times
You can use the Call Stack pane to see what path it followed through the program to reach the point where it crashed. Clicking on each entry will take you to the corresponding line, and you can examine variables and such in the functions by holding your mouse over them. The yellow error is the exact point where the crash occurred, and the curly green arrow is the closest point for which source code is available. In this case, since the error is memory corruption and not caught until after the fact, this window is mostly useful to identify that something went wrong while it tried to free a block of memory.
- step6.png (7.39 KiB) Viewed 640 times
Depending on what went wrong, the Output pane may or may not provide useful information. (Be sure to set the Show output from option to Debug.) In this case, it's just a repeat of the popup that you got when you broke into the debugger, but in other cases, it might be more informative.
- step7.png (7.25 KiB) Viewed 638 times
[quote="Enjay"]I could get the game to crash then screenshot the contents of the microsoft crash report window[/quote]
You're compiling your own builds. That means you have access to the debugger, so you should run the program from inside there, and it will break on the exact line where the error occurred. No need to guess where it's happening. (In this case, it's memory corruption that is caught while freeing memory.)
To set up the arguments for debugging, right click on the zdoom project from Solution Explorer and edit its Properties:[attachment=6]step1.png[/attachment]
Then make sure the Working Directory is set to $(TargetDir) and set whatever Command Arguments you want to test with.[attachment=0]step2.png[/attachment]After you hit OK, you can then debug it by pressing F5 (or choosing Start Debugging from the Debug menu).
Alternatively, you can also run the debug build outside the debugger and then attach the debugger after it crashes. In this case, running inside the debugger caused it to crash at exit rather than right away (probably because Windows adds extra info to the memory blocks when it sees that it's being run inside a debugger, so the corruption is in a different place), so I can run it outside the debugger and then choose to debug it once it crashes:[attachment=5]step3.png[/attachment]
This pops up a list of possible Visual Studio instances you can attach to it. Since I already have the ZDoom project open, I choose that one:[attachment=4]step4.png[/attachment]
After you break into it with the program, it tells you the error that occurred and marks the line as close to the error point as it has source code for:[attachment=3]step5.png[/attachment]
You can use the Call Stack pane to see what path it followed through the program to reach the point where it crashed. Clicking on each entry will take you to the corresponding line, and you can examine variables and such in the functions by holding your mouse over them. The yellow error is the exact point where the crash occurred, and the curly green arrow is the closest point for which source code is available. In this case, since the error is memory corruption and not caught until after the fact, this window is mostly useful to identify that something went wrong while it tried to free a block of memory.[attachment=2]step6.png[/attachment]
Depending on what went wrong, the Output pane may or may not provide useful information. (Be sure to set the Show output from option to Debug.) In this case, it's just a repeat of the popup that you got when you broke into the debugger, but in other cases, it might be more informative.[attachment=1]step7.png[/attachment]