News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Win 10: no symbols in OllyDbg

Started by jj2007, December 15, 2023, 09:55:21 AM

Previous topic - Next topic

jj2007

With identical settings and files, Olly version 2.0 shows me symbols in Win7 but not in Windows 10.

Olly version 1.0 shows me symbols but has trouble injecting code (so it says), so I can't work with the old version.

Has anybody experienced this problem?

2B||!2B

Which symbols you wan't to load? PDB of the file you're trying to debug or system dlls pdb files?
I have always been using 1.10 version. Don't have that issue you're facing. Can you show a pic?

TimoVJL

May the source be with you

jj2007

Quote from: 2B||!2B on December 15, 2023, 01:59:20 PMPDB of the file you're trying to debug

Yes. The system symbols work fine, my own symbols are the problem. They are normally embedded in the exe, but even with a pdb file (when using ML.exe) I can't see the symbols.

@Timo: DbgHelp.dll of 21.3.2008

jj2007

Quote from: TimoVJL on December 15, 2023, 07:04:50 PMWhat dbghelp.dll was used ?

Hi Timo,

I found a dbghelp.dll version 21.11.2010, and now my symbols are back - thanks a lot :thup:

It's weird: I get symbols for most executables but not for all. And those that don't give me symbols get udd files 100 times (!) bigger... something is wrong here :rolleyes:

Besides, although I gave Olly a udd folder and path, it continues to write the udd files to its main folder :cool:

TimoVJL

Version 10.0.19041 worked on my test in Windows 10
But you can try with an older dbghelp.dll too
May the source be with you

adeyblue

I'm pretty sure I read somewhere that in newer versions of dbghelp and friends they were removing support for COFF symbols, leaving only pdb ones as supported. It would fit since COFF symbols are the ones embedded in the exe, but I have tried to find some sort of reference or source for this at all and completely failed, so I might have dreamt it and be talking complete nonsense.

I suppose the easiest way to test is to load turn on symbol loading debugging.
Open a cmd,
set DBGHELP_DBGOUT=1 (ie, create an environment variable)
then start the debugger from that cmd
If it has a place to view the output from OutputDebugString, and it uses dbghelp/dbgeng, that should show the debug output from the symbol loading.
Then you can compare the differences

jj2007

Quote from: adeyblue on December 16, 2023, 01:38:01 PMin newer versions of dbghelp and friends they were removing support for COFF symbols, leaving only pdb ones as supported. It would fit since COFF symbols are the ones embedded in the exe

That makes sense, adeyblue. I was using a recent version, but now I reverted to DbgHelp.dll version 6.1.7601.17514 of 21.11.2010, and guess what? Symbols are back (thanks again, Timo, for this hint :thup: ).

Btw I tried with pdb files (it seems only ml.exe creates them - I mostly use UAsm64), but no symbols. So I'm not totally convinced of the pdb & COFF support story (which I had heard before, e.g. see here)

However, I still have two problems:
1. Olly 2.0 doesn't care about the three paths given in Debugging Data: D:\Masm32\OllyDbg\Udd\
They are registered in OllyDbg.ini (by Olly itself!) as...
Debug data directory[0]=.\Udd\
Debug data directory[1]=.\Udd\
Debug data directory[2]=.\Udd\
... but Olly ignores that and writes the whole udd crap to its own folder.

2. While a normal (console and GUI) udd file has about 1MB, Olly gives me 100MB files for everything built with my GUI package*). The executables are around 60kB without symbols, 440kB with symbols, but the udd files are 101MB in both cases.

No serious problem there, everything works fine, but still, it intrigues me why Olly behaves like that :cool:

*) A full-fledged Rtf reader in 17 lines, printing included:
GuiParas equ "Hello World", w500, h400, b LiteBlueGreen, icon Printer    ; width+height, background colour
GuiMenu equ @File, &Open, &Save, &Print, -, E&xit, @Edit, Undo, Copy, Paste
include \masm32\MasmBasic\Res\MbGui.asm
  GuiControl MyEdit, "RichEdit", wCL$(), bcol LiteYellow, fcol Black, font -14    ; load file in commandline
  GuiControl MyStatus, "statusbar", wRec$("Started "+fTime$())
Event Menu
  Switch_ MenuID    ; 0...n: see the order of the GuiMenu line above
  Case_ 0
  .if FileOpen$("Rich sources=*.asc|All sauces=*.as?;*.inc|All files=*.*")
    SetWin$ hMyEdit=FileRead$(FileOpen$())
  .endif
  Case_ 1: MsgBox 0, "Saving not implemented, sorry", "Hi", MB_OK
  Case_ 2: <void PrintRtf(hMyEdit)>        ; print selection (if any) or whole document
  Case_ 3: invoke SendMessage, hGui, WM_CLOSE, 0, 0
  Case_ 4: invoke SendMessage, hMyEdit, WM_UNDO, 0, 0
  Endsw_
GuiEnd
There is definitely some serious coding under the hood, but why a factor 100 for the udd files?

TimoVJL

May the source be with you

jj2007


TimoVJL

Now we wait tests within Windows 11
May the source be with you