Me a kid in the arena of 32 bit assembly.... I just want to know whether there are any good 32 bit debuggers. Don't have $$ hence can't buy softICE... Tried CodeView but not sure whether it can debug .386 assembly code.
Posted on 2001-07-28 10:40:17 by Unregistered
hi
ollydbg ,it is very good debuger(in my opinion ), has a function that you wont find in other debugers

they just released new version 1.04
and the best thing that it is free

http://home.t-online.de/home/Ollydbg/


eko:alright:
Posted on 2001-07-28 15:06:24 by eko
windbg from ms sdks is free but not very userfriendly

jeremy gordon is writing gobug that looks very promising
http://www.godevtool.com/index.html

trw2000 at http://www.knlsoft.com/ is pretty good and
has free demo version
Posted on 2001-08-17 22:49:46 by dsfsdfsdfsdf
Just checked out ollydbg, looks pretty good to me :alright:

http://home.t-online.de/home/Ollydbg/
Posted on 2001-08-18 03:55:54 by Mel
it is located at
http://www.ollydbg.f2s.com

so, if u use OllyDBG dont forget to stop by
and say hello ... maybe test MapConv (plugin
to import .map files)

cya
TBD
Posted on 2001-08-20 00:51:01 by TBD
Personally, I've never seen the need for a debugger. They either give me too much or too little info.

I use macros to dump info into message boxes, a console window, or files, depending on what I'm doing. (Console's are best but not always possible).

Check my page for the tut on this.
Posted on 2001-08-21 22:37:55 by Ernie
yes, i've been using ernie's macros since i got them months ago. until now i didn't re-install softice since i last reformatted my disks. i even had ida4 but it seems like harder to learn than win32asm itself ;)

.pix

ps// although you don't actually need $$ to get hold of si and ida (except for the phone bill if you're paying ;)), i don't recommend using them, unless you're trying to crack/hack a certain app. but i find it easier to learn asm by writing asm code from the ground up (with the libs of course) than by reverse engineering apps (obviously).
Posted on 2001-08-25 15:52:53 by pixelwise
I've been giving Windbg a pretty good workout the last few days, and I like it. I didn't have any problems getting "friendly" with it. :)

It took a few minutes to get the "default" startup the way I like it, but now it's good to go. I've got the disassem window on top, the listing file (using the built in editor) under it, and the memory display under that. On the right are the regs, call stack and command windows. You need at least 1024x768 to get all this stuff on screen...

I don't have symbolic debugging working yet, but you really don't need it with a listing and link map. I hear you need an older version of LINK, one that supports MSPDB41.DLL, in order to get symbolic debugging working.

So, if anyone knows where I might find same... ... ...

:)
Posted on 2001-08-29 22:34:50 by S/390
S/390
IF by symbolic debugging you mean being able to trace thru and set breakpoints in your source code as well as view your variables in the variable watch then all you need to do is use the debugging options when assembling and linking your program.
I only occasionally use the dissassembly window...most of the time it's disabled.

I use Windbg all the time, when I need more real estate I simply bump up the screen resolution to 1280x1024, as a matter of fact I mostly debug at this screen resolution. Still easy on the eyes if a session is kept short...

Oh not sure if you know this but if you save your workspace for each executable you debug then after you update the executable you just need to load it's workspace...provided you don't change too much then all your original breakpoints(source code) will be set!

the Martial
Posted on 2001-08-31 08:43:07 by MArtial_Code
MArtial,

I must be missing something. What options do you use? I've tried various combinations of /Zi and /Zd in ML and /debug, /debugtype:cv and /pdb:none with link, all without success. :confused:
Posted on 2001-08-31 10:21:41 by S/390
S/390
here's the command line I use, some of the stuff towards the end are Radasm stuff.

ML.EXE /c /Zi /Zd /coff /Cp /nologo /I$I,2

LINK.EXE /DEBUG /DEBUGTYPE:CV /SUBSYSTEM:WINDOWS /VERSION:4.0 /LIBPATH:$L,3,4

from your message above it looks as if the PDB:none option may be to blame

the thing is when a file is being debugged for the very first time i get a dialog box saying "Symbol information for the current line could not be located in the currently loaded symbols" it asks whether to perform the search immediately or to return to UI while the search proceeds or cancel

if i select the first option then it fails to find the symbols. if I choose the second option then it finds the symbols and everything is fine from then on... at this point I save the workspace...
hope that helps
By the way I'm running the W2K version

The Martial
Posted on 2001-08-31 15:18:46 by MArtial_Code
Thanks MArtial, but I've tried that combo. I get a box that says "No symbolic info for debuggee". But it runs fine in asm mode with or without the debug info attached.

Must be something different with the 9x version I guess. I saw a post here a while ago about the newer version of MSPDB causing a problem. Now if I could only find an old linker that uses 41...

:)
Posted on 2001-09-01 04:17:48 by S/390
This one from Win32SDK for WinNT 4.0 (which was free available as I remember) uses MSPDB41.DLL

japheth
Posted on 2001-09-02 07:29:59 by japheth
Thanks japheth. I'll check it out & let you know if it works. :)
Posted on 2001-09-02 14:47:43 by S/390
Thanks anyway japheth, but 95B doesn't like that ver of Link at all. It blows-up with an invalid seek error... :eek:
Posted on 2001-09-02 20:49:34 by S/390
S/390,

MSPDB41.DLL is needed to execute link. You should have a copy of this dll in your WinDbg dir. I have no problems executing this exe with Win95B.

japheth
Posted on 2001-09-03 02:27:02 by japheth