C/C++ Debugging c++ in assembly without source code

[Mighty Professional]

This tutorial is a work in progress it is useless in its current form. I am posting it so I do not lose progress as it will take several days to create the necessary crash dumps and information. 

 

Spoiler

 

This is a tutorial that will teach you the basics of debugging c++ programs in assembly with our without source code. This tutorial will teach you just enough assembly to debug c++ applications, it will teach you some clever tricks to get a good idea of what is going on in your c++ programs without having to know how to read assembly completely. This tutorial will not teach you how to write assembly, there is plenty of tutorials on the internet to do so if that is what you are looking for. This tutorial will concentrate on 64 bit intel processors as this is the most likely program you will be debugging. Other processors will be covered briefly. All the processors can be googled to get the corresponding information anyway. 

 

Why would you ever need to do this?

 

1. The most common scenario is that you have released your program to the public and you get a crash dump from someone. Now you may be thinking "No problem let me just grab the old trusty debugger and get to work". The problem is that your program is most likely compiled into "Release" mode. While it is easy to debug crashes when developing in "Debug" mode, when switching to release things get a little bit harder. All of the compiler debug information is thrown out to keep the executable small and speedy. On top of that it has compiled your c++ into a different set of assembly instructions to get every possible extra cycle out of your program. The debug information is not only not available, it often confuses your debugger and will actually cause it display the wrong information (more on why that happens later)
2. Another likely scenario is that you are using a 3rd party SDK and you do not have access to the source code. Your coding is crashing somewhere inside the 3rd party library and you have no way of telling what is going wrong. Another similar scenario is that the 3rd party library is poorly documented and you need to go into the assembly to see what types of arguments it expects, whether it checks for null etc. 

 

The most common problems you will be facing

• Uninitialized Variables
• Dangling Pointers
• Memory Corruption
• Race Conditions
• Deadlocks

 

Why cant I just use the watch window?

As mentioned above, in release mode your watch window will show garbage values or none at all. This is because in debug mode the compiler stores the debug information in certain registers and memory locations to that the debugger knows how to find these values. In release mode this is not done, the compiler is then confused and showing the wrong memory locations. Trying to use the watch window in release mode ends up looking something like this.

 

 

Likewise the callstack window will be full of fake values as well, it should only be used for navigation.

 

Why cant I just read the source?

You do not have access to the source code most of the time as discussed above. Your view will most likely look like one of these if you are lucky. 

 

There is a good chance this is all you will be able to use:

 

 

 

 

 

 

[Oddly]

Love love LOVE debugging with assembly

If you're not working in Visual studio and your IDE does not have a disassembler built in, I recommend using

http://gcc.godbolt.org

 

This website is not for entire applications, it's more or less viewing what a segment of your C++ code is in assembly to view what low operations each method is creating. It's good for debugging, but is more for optimizations than anything. Also lets you select different versions of assembly. I keep it book marked for when I do work on Linux or work with crossplatform applications and compilers such as gcc or mingw.