The key word here is “trace”.
Turn on your debugger and run your program. When it crashes it will tell you exactly which line caused the crash, and you can work from there.
BTW, clobbering a user’s power and screensaver settings is not very nice. You should first get them and then restore them before the program terminates. Make sure to set an abnormal exit handler to do it. If you are compiling with MSVC, use the MSVC-specific __try and __finally SEH handlers around main() to do it. If you are using GCC, make sure you have a .fini section to do it.
@rankery, I have only one instruction to work from, so I can't see any more than that. You need to be able to find a point before this failure in the code when the ds register is set, or when something at ds:[726cc0h] is being initialized. We simply have no other information out here.
compile it in debug mode. you get an assembly instruction because its using release code.
then once its compiled in debug mode, use your debugger to trap the error in real code.
if you are deep in the libraries, 'step out' until you are back in your code. that can also drop you to assembly -- you went too deep with the step-ins. you can also binary search your code.. put stops in it and run it, did it crash? If not, go farther, did it crash? find the offending line. It will be a memory/array/etc type access problem. perhaps zeromemory is misused?
@rankery, @jonnin is on to the plan, just wanted to say if you have the option in your debugger, you can use the "call stack" to see "how deep" you are into the libraries.
It shows you want in your code made the call that got into trouble.