I usually compile my projects with pdb symbols and load them on Windbg. Do you guys think it s overkill? After all, we are already programming at the lowest level...
Do you just inspect code manually? Hex editors? Messageboxes?!
Share your methods with us...
Fabio,
Its usually the case that different people use whatever they like best. The only criterion is if it does the job for you. I tend to display values at the console OR use title bars, status bars and even message boxes if it will do the job. I do this mainly because I am a lot faster doing debugging this way.
1. I use the deb (http://www.webalice.it/jj2006/MasmBasicQuickReference.htm#Mb1019) macro, almost exclusively in console mode
deb 4, "some text", eax, ecx, somevar, xmm0, ST(0)
The source I am currently working on most has 140 occurrences of deb in 2,400 lines. The advantage is that you actually run your app at full speed while seeing the debugged variables (including Ansi and Unicode strings) in the console.
2. If that is not enough, I insert an int 3 and launch Olly (http://www.ollydbg.de/version2.html).
Another alternative, which I use frequently in full blown software is OutputDebugString. The output can be viewed with DbgView.exe. This works for all sorts of applications. Producing a log file to disk is also helpful in some cases.
Quote from: aw27 on March 14, 2018, 07:51:14 PMOutputDebugString
Can be quite useful indeed, see Detecting and debugging heap corruption (http://masm32.com/board/index.php?topic=5314.msg67040#msg67040). But this is most relevant for bugs that corrupt the heap, it won't help much with bugs in your own code that does not involve the heap.
Quote from: jj2007 on March 14, 2018, 09:26:08 PM
Quote from: aw27 on March 14, 2018, 07:51:14 PMOutputDebugString
Can be quite useful indeed, see Detecting and debugging heap corruption (http://masm32.com/board/index.php?topic=5314.msg67040#msg67040). But this is most relevant for bugs that corrupt the heap, it won't help much with bugs in your own code that does not involve the heap.
All sorts of bugs because it is a print to a "console" independent of your program, does not disturb it then.
For "normal" code or function results, I use message boxes or output to the console.
For complex algorithms I print it out to a log file, also handy for recognizing patterns.
For "unknown phenomenas" I use Ollydbg.
Sometimes I use numbered checkpoints for spotting the line of code that leads to segfault or crash.
Conditional compilation with debug macros enabled is another possible method.
Quote from: GoneFishing on March 15, 2018, 12:00:04 AM
Conditional compilation with debug macros enabled is another possible method.
Very nice with DbgWin, wich is in MASM32 package
I use for all my projects pdb (debug builds) symbols files and use any debugger :t
Quote from: Fabioxds on March 14, 2018, 05:33:58 PM
Share your methods with us...
Depending of the computer i'm using will be olly or x32dbg. In all cases i mainly use debuggers when i can't find the problem first in the code. :idea:
step 1) don't write bugs :P
step 2) sometimes, i may use a MessageBox to display a particular value or string
step 3) sometimes, i may use OllyDebug, if i need to see register contents
step 4) if i want to display a lot of values, i may attach a console window and dump them there
OutputDebugString works fine on Windows XP 64-bit.
Generally i use message boxes.
when writing some graphic drawing program, many times you can spot a different behaviour than desired and understand when UV scrolling waterfall code produces sideways than downwards, you have accidently coded scrolling in U coordinates of vertices, when you intended to change V coordinates
I use ollydbg also, useful if you want to make use of fpu code that uses several fp registers, I code for example it to use st4,st3 and I singlestep thru it to see where I need to change st4's to st5's and st3's in my code to make fpu code works as intended
some things in science has been discovered by pure luck, sometimes mistakes, like infrared showed up on film beyond the red light, when using a prisma
here it suddenly looked cool, because of a bug in code it uses wrong texture
I use combination of the DbgWin and Donkey's vKim like debug macros for outputting text, strings, registers and variables and occasionally dumping structures etc.
Then i also use x64dbg occasionally with program assembled with debug settings and pdb, which allows source level view and disassembly as well.
I use the xAnalyzer plugin in x64dbg to add api call information and parameters, to the comments, and i added my own definitions for some libaries i have for functions and constants
CPU View:
(https://s20.postimg.org/j53rfiv25/MUIProgress_Bar_Cpuview.png)
Source View:
(https://s20.postimg.org/97sqmgv65/MUIProgress_Bar_Sourceview.png)
Of course the xAnalyzer plugin works with standard windows api calls as well like so:
(https://s20.postimg.org/4yo0kemst/MUIProgress_Bar_Win_Apicalls.png)
Quote from: fearless on March 18, 2018, 05:00:06 AM
Source View:
(https://s20.postimg.org/97sqmgv65/MUIProgress_Bar_Sourceview.png)
That's really neat code block remarks in your WndProc! With your permission I'm going to use that style. Thanks!