Debuggers - What's your favorite one to use, and why?

[japheth]

Hmmmm no gobug users here ?  :(

Perhaps it's just a bit unknown? If you believe that it's underrated, then it's ok if you advertise it ( Decently! Not the E-Cube way! ). Is it better than my favorite CDB?

[Dogim]

Hmmmm no gobug users here ?  :(

Perhaps it's just a bit unknown? If you believe that it's underrated, then it's ok if you advertise it ( Decently! Not the E-Cube way! ). Is it better than my favorite CDB?

A happy New Year to all, forgot the data has changed to 2011.
I was just curios how many used Gobug, i use Goasm,however i do use olly occasionally, but mainly Gobug, because i,m a beginner, i like the Gobug feature "Break op API error", which helps a lot,and the detailed execution log display is nice, i must say i haven't used olly that much, maybe these feature are also included in olly or in other debuggers.
I don't know cdb, so i can't compare them
I stay away from IDA , looks to complicated for a beginner :red, but if any could convince me to use other debuggers , i liked to hear it, and why of course.
But that's what this topic's about  :thumbu

[clive]

I guess the more wise are better than I thought and don't use debuggers.

Well there is a lot of truth there.

It depends on what you think debuggers can actually do. If you don't understand what the instructions do, or how your code should flow, they might be more useful than if you do.

Debuggers are good at looking at fine grain instruction operation, examining faulting conditions, and looking at other peoples code. When something faults, that's one of the easiest things to fix. With Visual Studio/C installed, any faulting app will drop into the debugger. If you compiled/assembled/linked your application, DLL, etc, with debug symbols enabled (/Zi), it will pull in the PDB files and use them. For system components you can pull symbols from a Microsoft server.

Debuggers are not much use for real time failures, and algorithmic issues with your code. First you need to be able to read and follow your own code. Add instrumentation, sanity checks, and actually test parts of your code as you write them, so when they are combined as a whole they will work as you expect.

You can output telemetry to the debug console, and use tools like DebugView to see what's going on. This can be helpful for GUI apps, and driver code.

Test your code in a simple framework/harness, use a C compiler and use the inline assembler. I test a lot of embedded code on a PC, where I have more resources, like file systems, and can emulate hardware. It's a lot easier to dig out stupid semantic and algorithmic issues on a PC, than on a piece of custom hardware.

I used to use SoftICE for driver work, not sure what I'd use today, probably WinDbg. Olly is pretty good for looking at applications you didn't write yourself, the symbol stuff is sometimes quirky. Visual Debugger should be fine unless your code is totally hopeless.

These days I mostly use hardware debuggers (ARM w/JTAG or trace units),  but again the aforementioned methods substantially limit the amount of time, and problems, that require such attention.

[donkey]

I use GoBug for the most part but also OllyDbg. Depends mostly what I am trying to examine, each has its own advantages. For examining code OllyDbg does a slightly better job at finding procedures but GoBug has some imaginative ways to halt execution, for example on API errors which really helps when debugging a GUI application.

[jj2007]

GoBug has some imaginative ways to halt execution, for example on API errors

That is one feature I miss in Olly. Others are to skip the non-usercode part (i.e. not to waste time deep inside a Windows API, or a CRT algo), and a key that advances to the end of a loop. Otherwise Olly is a great tool, and free.

[BogdanOntanu]

GoBug has some imaginative ways to halt execution, for example on API errors

That is one feature I miss in Olly. Others are to skip the non-usercode part (i.e. not to waste time deep inside a Windows API, or a CRT algo), and a key that advances to the end of a loop. Otherwise Olly is a great tool, and free.

Kidding?

you mean break on API, execute until user code, F4 to execute and break "here" aka at end of loop ?
Olly has all this and much more... well unless you are using Olly 2.x ... because that version is not yet finished

[Shooter]

I use GoBug for the most part but also OllyDbg.

Is GoBug free?

[Dogim]

I use GoBug for the most part but also OllyDbg.

Is GoBug free?

I use GoBug Version 2.03.01 , this version is not free, but the 0.91 version is.

[Dogim]

Kidding?
you mean break on API,

Wich version of olly can do this  BogdanOntanu ?

[BogdanOntanu]

Kidding?
you mean break on API,

Wich version of olly can do this  BogdanOntanu ?

Please excuse the edit .. I wanted to reply and pressed the wrong button :D

Probably all Olly 1.xx can do it... but for sure Olly 1.10 can do that.

see here: in the FAQ: http://www.ollydbg.de/faq.htm

And there are also a lot of plugins that add more features to this (management etc).

But to quote from another forum (RCE):

...
To breakpoint on an API function its easy enough just to hit Ctrl+G (Goto Address), then type in the API name like VirtualProtect and Olly will take you there. F2 to set the breakpoint. Couldn't get much easier than that!
...

[donkey]

GoBug has some imaginative ways to halt execution, for example on API errors

That is one feature I miss in Olly. Others are to skip the non-usercode part (i.e. not to waste time deep inside a Windows API, or a CRT algo), and a key that advances to the end of a loop. Otherwise Olly is a great tool, and free.

Kidding?

you mean break on API, execute until user code, F4 to execute and break "here" aka at end of loop ?
Olly has all this and much more... well unless you are using Olly 2.x ... because that version is not yet finished

No, that's not what I mean. I mean that it will break only if the API throws an error (GetLastError type, not a hardware exception)

[Shooter]

I prefer the MS Visual C++ debugger. It works great for MASM programs as well as C/C++ programs. I have gotten used to it over the years and I won't settle for anything else. I really don't care for WinDbg and OllyDbg is OK but it just doesn't have all the features the VC++ debugger has.

I just downloaded and tried it, but either I'm missing out on how to set up, or my version doesn't have the type of features that Olly has. It just looked like an ordinary debugger to me. What features make it better than Olly?

-Shooter

[GregL]

Shooter,

For one thing it supports x64.

It has all the features of OllyDbg and more. Pull up the Registers window (it supports CPU, FPU, MMX, SSE, SSE2), the Memory window (you can view memory in any type from BYTE to QWORD to REAL4 and REAL8), the Call Stack window, the Watch window (will display REAL10 variables) etc.  OllyDbg just comes up short in my book.

It's just a matter of personal taste, and what you are used to using.  You asked what my favorite debugger is and I told you.

[Shooter]

GregL,
I'm not challenging your choice in debuggers, I simply was just curious what you liked about it.

Do you know if MS Visual C++ debugger has a feature like Olly's Analyze?

Also, Olly has that ability (not sure what it's actually called) to show what the variable names are prior to calling an API. For example, prior to calling User32.DialogBoxParamA, the right column of the CPU window names the variables InitParam, DialogProc, hParent, TemplateName, and hInst and what they're set to, which is really handy to me as I'm still trying to learn what each function does. Can the MSVC debugger be set to show something like this?

One thing I haven't figured out how to get Olly to do automatically is to use labels as I have them in my .asm file (I have to manually add them in).

-Shooter

[jj2007]

Kidding?

you mean break on API, execute until user code, F4 to execute and break "here" aka at end of loop ?
Olly has all this and much more... well unless you are using Olly 2.x ... because that version is not yet finished

Dear Bogdan,
I understand you are a fan of Olly, so am I. But, as Edgar already wrote, "break if API error" is different. And there is also a difference between manually setting a breakpoint after a loop (I guess that is what you suggested) and simply hitting a key that brings you to the end of whatever loop.
As to "skip the API", the F8 key does that, but it does not distinguish between Windows APIs and own procs. Yes this is really a minor criticism - I am a fan of Olly, and hope that version 2 (2 like SSE2) is soon as perfect as Olly 1.0.