Symbolic debugging with Olly

[jj2007]

... 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!

Code Select Expand

*** 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

[GregL]

The 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.

[UtillMasm]

 :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.

[jj2007]

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

[oex]

- 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

[japheth]

- 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! )

[jj2007]

Thanks, Japheth. That works, too. But I would never had found that solution by consulting the VC help...

[Alloy]

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.

[redskull]

(of course, CDB is ways better than VC. However, it's for real programmers only! )

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

[GregL]

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.

[japheth]

(of course, CDB is ways better than VC. However, it's for real programmers only! )

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".

[jj2007]

You can pass a commandline, too (even without changing the directory):

"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.

[GregL]

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.

[jj2007]

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.

[UtillMasm]

 :dazzled:
StrongOD v0.2.9.548
      let OllyDbg v1.10 Load MS public symbols & Detach a process. :toothy

Code Select Expand

http://www.tuts4you.com/download.php?view.2674