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.
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:
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:
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
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
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
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
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.
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.
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).
.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).
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... ... ...
:)
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... ... ...
:)
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
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
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:
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:
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
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
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...
:)
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...
:)
This one from Win32SDK for WinNT 4.0 (which was free available as I remember) uses MSPDB41.DLL
japheth
japheth
Thanks japheth. I'll check it out & let you know if it works. :)
Thanks anyway japheth, but 95B doesn't like that ver of Link at all. It blows-up with an invalid seek error... :eek:
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
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