Maybe you know this situation. After spending more hours together with the debugger than it is good for you are ready to shout: “It must be the compiler. It couldn’t be the source code.” Normally someone else will you then remember on one of the general rules. <Don’t blame the compiler. If you put garbage in it will give you garbage back.>

Well last week I was looking for a problem that unfortunately only occurs on a test system without any debugger at all. To make the whole thing even more badly the application simply terminates without showing our friend Dr. Watson. Using some tracelogs I was able to find the region that cause the problem but not the function that was responsible. I finally decide to give the remote debugger a chance and to my surprise I was able to attach it before the app crashes and it reports a access violation back to my development system. Unfortunately the debugger was not able associate the source code on my system with the app on the test system but I got the memory address of the failing instruction. Maybe you already know this little trick. The Visual Studio debugger allows you to set breakpoint on instruction addresses and will translate the address to a function name if possible.

After this step I know the function and I even know why it was only happening on the test system. The function contains some 3DNow code that will not be used on any system. Anyway I don’t know how old this function is but it has never failed in this way before. Out of good ideas I decide to take a look at the generate code and directly for the instruction that caused the crash it does some really crazy things with the stack pointer.

This remembers me on another general rule: “No rule without exception”. It may very uncommon these days but there is still a chance that you can blame the compiler and win. The chances are small but at least this shows us that anything is possible.

It’s time again to take a look at the last DirectX SDK. But this time there isn’t much to report.

XACT is upgraded to version 2.6 and as always after a version upgrade the GUIDs change.

The second change are some constants for DirectSound. As stated in the “What’s new” this change is mainly about the speaker configuration.

Finally the version of the whole SDK is upgraded and that’s all what you will find in the includes.