The testbed below may be helpful in convincing OllyDbg to show symbolic names - a real advantage for debugging your code.
This works fine under the following conditions:
A. Assembler is ml.exe, version 6.15
Notes:
- commandline options are /c /coff /Zi (/Zd does not make a difference)
- 6.15 knows SSE2, in contrast to 6.14, but is not included in the Masm32 package; try the GeneSys version (http://www.masm32.com/board/index.php?topic=12847.msg99232#msg99232)
- 6.14 introduces a few extra jmps on top of file but works fine if you have no SSE code
- Jwasm (http://www.japheth.de/JWasm.html) works fine but not always, and has minor problems with local variables 1)
B. Linker is link.exe, version 6.14
Notes:
- command line options are /debug /Subsystem:xxx and nothing else.
- polink seems not to work, but maybe somebody knows a trick...?
- link version 9.0 produces "fatal error LNK1101: incorrect MSPDB80.DLL version; recheck installation of this product" (I did reinstall Visual C++ Express from here (http://www.microsoft.com/express/download/))
C. Debugger is OllyDbg (http://www.ollydbg.de/) version 1.1 (Odbg110.zip)
Notes:
- Olly 2.0 is sometimes more powerful but no symbols, sorry...!
- In Olly 1.0, choose the following debugging options:
DisAsm: Show symbolic addresses
Stack: Show names of local variables (this affects the stack window in the lower right corner, very handy!)
Analysis 1: Show ARGs and LOCALs in procedures
Analysis 2: Show arguments of known functions
include \masm32\include\masm32rt.inc
MyProc PROTO: DWORD, :DWORD
Externdef MyLabel:NEAR
Externdef MyLabelInProc:NEAR
.data
MyDword dd 123
MyString db "Ciao", 0
hw db "Hello World at 1024 bytes", 0
.data?
AnyVar dd ?
.code
start: jmp MyLabel
m2m AnyVar, MyDword
MyLabel:
mov AnyVar, 12345678h
invoke MyProc, offset MyString, MyDword
print offset hw, 13, 10, 10
getkey
invoke ExitProcess, 0
MyProc proc ptrMyString, MyDwordArg
LOCAL MyLocVarA:DWORD, MyRect:RECT
LOCAL Loc4Bytes[4]:BYTE
lea edx, Loc4Bytes
mov MyLocVarA, 12345678h
mov MyRect.left, 123h
mov MyRect.top, 456h
mov MyRect.right, 321h
mov MyRect.bottom, 654h
je MyLabelInProc
inc eax
jmp MyLabelInProc
mov eax, ptrMyString
sub eax, ecx
mov ecx, MyDwordArg
MyLabelInProc::
ret
MyProc endp
end start
If everything works fine, you will see the testbed code as below.
<ModuleEntryPoint> $/EB 0C jmp short MyLabel
00401012 .|FF35 00404000 push dword ptr [MyDword]
00401018 .|8F05 40414000 pop dword ptr [AnyVar]
MyLabel >\C705 40414000 7856>mov dword ptr [AnyVar], 123456>
00401028 . FF35 00404000 push dword ptr [MyDword]
0040102E . 68 04404000 push offset MyString ; ASCII "Ciao"
00401033 . E8 20000000 call MyProc
00401038 . 68 09404000 push offset hw ; /Arg1 = 00404009 ASCII "Hello World at 1024 bytes"
0040103D . E8 76000000 call StdOut ; \StdOut
00401042 . 68 23404000 push offset ??001A ; /Arg1 = 00404023 ASCII CR,LF,LF,""
00401047 . E8 6C000000 call StdOut ; \StdOut
0040104C . E8 9F000000 call ret_key
00401051 . 6A 00 push 0 ; /ExitCode = 0
00401053 . E8 3A010000 call ExitProcess ; \ExitProcess
MyProc $ 55 push ebp
00401059 . 8BEC mov ebp, esp
0040105B . 83C4 E8 add esp, -18
0040105E . 8D55 E8 lea edx, [local.Loc4Bytes]
00401061 . C745 FC 78563412 mov [local.MyLocVarA], 1234567>
00401068 . C745 EC 23010000 mov [local.MyRect], 123
0040106F . C745 F0 56040000 mov [local.MyRect+4], 456
00401076 . C745 F4 21030000 mov [local.MyRect+8], 321
0040107D . C745 F8 54060000 mov [local.MyRect+C], 654
00401084 . 74 0B je short MyLabelInProc
00401086 . 40 inc eax
00401087 . EB 08 jmp short MyLabelInProc
00401089 . 8B45 08 mov eax, [arg.ptrMyString]
0040108C . 2BC1 sub eax, ecx
0040108E . 8B4D 0C mov ecx, [arg.MyDwordArg]
MyLabelInProc > C9 leave
00401092 . C2 0800 retn 8
1) JWasm misinterprets Local variables in the lower right corner:
(http://www.webalice.it/jj2006/pics/JWasmLocalVars.png)
Additionally, you can open the 'source' window to view your original source code, and observe the highlighted line as your step through. I would guess, however, that you would need the /Zd option for this.
-r
Hi Jochen,
Nice work. Why not to create a HTML or a pdf document?
Quote from: Vortex on January 05, 2010, 09:16:24 PM
Hi Jochen,
Nice work. Why not to create a HTML or a pdf document?
Hi Erol,
Thanks, but why create one? This
is an HTML document :bg
But jokes apart: There should be a Campus subforum "Welcome to noobs" explaining the top ten useful tools and the top ten pitfalls when coding in Masm.
Strictly limited in size, and moderated. For example, the .if eax<0 thing pops up regularly (http://www.masm32.com/board/index.php?topic=13057.msg101267#msg101267), and how many times have the older members here typed the links to the Iczelion tutes, or the path to the Masm32 help files that apparently are unreachable for the ordinary unguided noob...?
Quote from: redskull on January 05, 2010, 09:09:39 PM
Additionally, you can open the 'source' window to view your original source code, and observe the highlighted line as your step through. I would guess, however, that you would need the /Zd option for this.
-r
Red,
I only see an empty window when I click on View, Source. /Zd is on. What's the trick?
The "trick" (read: bug) is to double-click the source line in the CPU window to open it the first time; subsequent times will open normal.
To eludicate: When you initially load the file, you should see the current source line appear in the CPU window, in the 4-line box inbetween the dissassembly and the memory dump. Something like:
test.asm:25. invoke ExitProcess,NULL
Double click on THAT line, exactly, and it will open up the 'source' window, displaying your source, with the current line highlighted. Stepping through it will change the line, as appropriate. If you close the Source window, you can open it normally (via the 'S' box on the far right of the menu bar), provided you opened it via the double-click method earlier at least once.
my build commands:
ml /c /coff /Zi /Zd test.asm
link /subsystem:windows /debug /release test.obj
-r
Quote from: redskull on January 06, 2010, 12:30:59 AM
in the 4-line box inbetween the dissassembly and the memory dump. Something like:
test.asm:25. invoke ExitProcess,NULL
Double click on THAT line, exactly, and it will open up the 'source' window
Great, very helpful :U
But apparently, /Zd is not needed...
hi JJ2007:
Try imstalling the Redistribute 2008 from Microsoft!
Always run VCvars32 before you use ML or CL.
You only need to do this if you don t start VC Express.
This is also explained in Assembler and C sub forum.
Regards: herge
Quote from: herge on January 07, 2010, 01:55:15 PM
Always run VCvars32 before you use ML or CL.
Hi Herge,
I wish it would be that simple...
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin>"C:\Program Files\Microsoft
Visual Studio 9.0\Common7\Tools\vsvars32.bat"
Setting environment for using Microsoft Visual Studio 2008 x86 tools.
So far, so good. But when I build the file, the linker yells an "application failed because it could not find mspdb80.dll" box at me. If I copy the file to \masm32\bin\mspdb80.dll, I get the other error: fatal error LNK1101: incorrect MSPDB80.DLL version ...
Anyway, ml 6.15 or JWasm work fine.
Regards,
Jochen
Quoteunreachable for the ordinary unguided noob...?
but jj = you guys are my guide. :U
Quote from: jj2007 on January 07, 2010, 02:34:35 PM... If I copy the file to \masm32\bin\mspdb80.dll, I get the other error: fatal error LNK1101: incorrect MSPDB80.DLL version ...
I've the same problem with ml/link v9.0 ... but with version 10 it works (include in Visual Studio 2010 beta (http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx)).
qWord
I have no trouble with version 9, specifically 9.00.21022.08. Here is my 'minimum install'
ml.exe
link.exe
mspdb80.dll
msobj80.dll
mspdbcore.dll
mspdbserv.exe
As an interesting side note, mspdbserv.exe is launched whenever you link with the /DEBUG switch, and stays active pretty much forever. I'm not sure if this is by design or not (to make subsequent linking go faster), but it can only be killed via task manager.
-r
mspdbserv.exe ... that was the missing link :bg
Quote from: jj... If I copy the file to \masm32\bin\mspdb80.dll, I get the other error: fatal error LNK1101: incorrect MSPDB80.DLL version ...
Don't copy the file to \masm32\bin, but do put the original location of mspdb80.dll (%VSINSTALLDIR%Common7\IDE) in your PATH so link.exe can find it. That has always worked for me.
Hi JJ2007:
Start VC2008 c++, Tools 2008 Command Prompt
Do your thing here. Does it work now.
Add the directory where ML or CL is to your path.
This has to be done manually.
Also set INCLUDE environmental variable.
I think you can run ML and CL with out starting VC2008 but I
will agree it s a pain in the butt to do.
Regards: herge
Quote from: Greg Lyon on January 08, 2010, 03:50:37 AM
Quote from: jj... If I copy the file to \masm32\bin\mspdb80.dll, I get the other error: fatal error LNK1101: incorrect MSPDB80.DLL version ...
Don't copy the file to \masm32\bin, but do put the original location of mspdb80.dll (%VSINSTALLDIR%Common7\IDE) in your PATH so link.exe can find it. That has always worked for me.
Hey, that worked, no more error, great :U
The only remaining little problem is that Olly refuses to accept the symbols produced by version 9.0... holy crap!
*** Link using link with /Subsystem:Windows /debug /debugtype:cv "TinyPlotter.obj" rsrc.obj /OUT:"TinyPlotter.exe" ***
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
*** Assembling and linking took 1375 milliseconds ***
08.01.10 14:43 168,480 TinyPlotter.ilk
08.01.10 14:43 265,216 TinyPlotter.pdb
08.01.10 14:43 22,016 TinyPlotter.exe
08.01.10 14:43 350,197 TinyPlotter.obj
08.01.10 14:43 7,187 TinyPlotter.asc
Quote from: jjThe only remaining little problem is that Olly refuses to accept the symbols produced by version 9.0... holy crap!
I know you guys think OllyDbg is the bee's knees, but try using the Visual C++ debugger, it beats the pants off of OllyDbg. The Express Edition works just as well as the other versions. It requires ml /Zi and link /debug.
:snooty:
OllyDbg v1.10 + StrongOD v0.2.6.415 (Let OllyDbg load MS public symbols).
OllyDbg is easy.
VC Debugger or WinDbg is bad, very very bad.
Quote from: Greg Lyon on January 12, 2010, 03:00:59 AM
try using the Visual C++ debugger
I tried, and wasted already half an hour trying to find the essential info on how to
launch the bloody debugger with my executable. VC 2008 Express Edition gives me plenty of broken links in its help file... a typical M$ product. No wonder we get so much broken bloatware.
But after wasting some more time on numerous web sites where desperate people are guessing how VC might be convinced to debug something, I decided to use common sense. This works:
- insert these two lines in your code where you want to start debugging:
MsgBox 0, "Ready?", "Hi", MB_OK
INT 3
- assemble and run your executable (/Zi for assembly, /debug for linking)
- don't click OK right now when you see the above box...
- launch VC Express
- under Tools/Attach to process, choose your running executable, and click Attach
- switch to the "Hi, Ready" box and click OK
- VC may ask you for the source, e.g. MyCode.asm
- VC will say you triggered a breakpoint
- click Break
- in VC, choose Debug/Windows/Registers
- press F11 to step through your code
- F9 toggles a breakpoint, F5 will run until it hits the next breakpoint
Quote from: jj2007 on January 12, 2010, 08:51:49 AM
- insert these two lines in your code where you want to start debugging:
MsgBox 0, "Ready?", "Hi", MB_OK
INT 3
- assemble and run your executable (/Zi for assembly, /debug for linking)
- don't click OK right now when you see the above box...
- launch VC Express
- under Tools/Attach to process, choose your running executable, and click Attach
- switch to the "Hi, Ready" box and click OK
- VC may ask you for the source, e.g. MyCode.asm
- VC will say you triggered a breakpoint
- click Break
- in VC, choose Debug/Windows/Registers
- press F11 to step through your code
- F9 toggles a breakpoint, F5 will run until it hits the next breakpoint
.... Take a deep breath :bg
Quote from: jj2007 on January 12, 2010, 08:51:49 AM
- insert these two lines in your code where you want to start debugging:
MsgBox 0, "Ready?", "Hi", MB_OK
INT 3
- assemble and run your executable (/Zi for assembly, /debug for linking)
- don't click OK right now when you see the above box...
- launch VC Express
- under Tools/Attach to process, choose your running executable, and click Attach
- switch to the "Hi, Ready" box and click OK
- VC may ask you for the source, e.g. MyCode.asm
- VC will say you triggered a breakpoint
- click Break
- in VC, choose Debug/Windows/Registers
- press F11 to step through your code
- F9 toggles a breakpoint, F5 will run until it hits the next breakpoint
Rather complicated. I don't think the VC debugger is that bad. In fact, it is very simple:
- assembly your source with -Zi switch, link it with /Debug switch
- start VC IDE
- "open" your .EXE under menu item File/Open/Project-Solution (object typ "Executable")
- start debugger with F11
The one issue which I found is that VC wants to be smart and will stop at symbol WinMain ( or main ) only, not at the true entry.
(of course, CDB is ways better than VC. However, it's for real programmers only! )
Thanks, Japheth. That works, too. But I would never had found that solution by consulting the VC help...
I use a batch file to assemble, link and start visual studio express debugging. Something like:
ml /nologo /Zi /Zd /c /coff %1.asm
link /nologo /SUBSYSTEM:WINDOWS /DEBUG /DEBUGTYPE:cv %1.obj
cd c:\program files (x86)\microsoft visual studio 9.0\common7\ide\
vcexpress %1.exe
should work.
Quote from: japheth on January 12, 2010, 12:35:26 PM
(of course, CDB is ways better than VC. However, it's for real programmers only! )
Quote from: UtillMasm on January 12, 2010, 04:24:39 AM
VC Debugger or WinDbg is bad, very very bad.
Why so much angst towards WinDbg? I find the suite no harder to use than DEBUG.EXE itself, and far more powerful than Olly (e.g. try to debug the kernel with Olly), yet they seem to be eschewed almost 100% by everyone. What gives?
-r
Yeah Japheth has it right for loading an .exe to debug from within the IDE.
When loading an .exe to debug from the command-line, or from a batch file, use the /debugexe switch.
vcexpress %1.exe /debugexe
or
devenv %1.exe /debugexe
If you have just finished building an .exe from within the IDE, use Debug -> Step Into. Or just F11.
Then you may want to right-click on the code and select "Go To Disassembly".
"Go To Disassembly" used to be on the Debug menu but it is not now. If you customize the menus you can put it back.
Quote from: redskull on January 13, 2010, 02:28:14 AM
Quote from: japheth on January 12, 2010, 12:35:26 PM
(of course, CDB is ways better than VC. However, it's for real programmers only! )
Quote from: UtillMasm on January 12, 2010, 04:24:39 AM
VC Debugger or WinDbg is bad, very very bad.
Why so much angst towards WinDbg? I find the suite no harder to use than DEBUG.EXE itself, and far more powerful than Olly (e.g. try to debug the kernel with Olly), yet they seem to be eschewed almost 100% by everyone. What gives?
WinDbg and CDB use the very same "debug engine", so they are more or less equally powerful. But I usually prefer the simple "cmdline" interface. I don't think there is any "angst".
You can pass a commandline, too (even without changing the directory):
Quote"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\VCExpress.exe" ImgConverter.exe /debugexe /test.png /jpg
Note that VC chokes if you change this strange order of commandline parameters. The /debugexe must come behind your executable name but before your commandline switches.
jj,
Right. I use that method from within an editor to load the file I'm working on into the VC debugger. QE could be set up to do the same. Very handy.
Quote from: Greg Lyon on January 14, 2010, 01:43:03 AM
Right.
Half right. I have wasted an hour yesterday trying to find out how to pass
my params
/test.png /jpg. I was getting desperate because I kept changing them but VC kept using
an old set of my switches. Eventually I found them under Project/Properties
where I never put them by hand. So VC kept them and ignored the new ones I passed through the command line. The behaviour is pretty erratic, if somebody finds a pattern it would be helpful.
:dazzled:
StrongOD v0.2.9.548
let OllyDbg v1.10 Load MS public symbols & Detach a process. :toothy
http://www.tuts4you.com/download.php?view.2674
jj,
The documentation here (http://msdn.microsoft.com/en-us/library/ms241274.aspx) shows you being able to put the /debugexe switch before the executable and parameters. Maybe it's different for the Express Edition, I don't know. I have never had a problem with it, though I rarely use command-line parameters.
Greg,
Thanks, I tried again and today it works. No idea why it didn't work yesterday... ::)