3

This is definitely a beginner question but the WinDbg docs didn't help me out much because most of it is oriented around debugging programs with PDB files available. I tried .reload but it didn't have any effect.

Here is a simple call to MessageBox disassembled with WinDbg/kd:

00000000`012f1000 6a00            push    0
00000000`012f1002 68d0202f01      push    offset ReverseMe+0x20d0 (012f20d0)
00000000`012f1007 68dc202f01      push    offset ReverseMe+0x20dc (012f20dc)
00000000`012f100c 6a00            push    0
00000000`012f100e ff159c202f01    call    dword ptr [ReverseMe+0x209c (012f209c)]

Why is WinDbg not resolving the function name on the call for me? I can't imagine someone would be able to reverse engineer a program like this. When I trace the instructions, I'll end up at MessageBoxW so at least on some level WinDbg knows what is going on. I mean, it should, because the PDBs for the Windows APIs are available.

Improve this question
0

2 Answers 2

Reset to default
2

If WinDbg does not show method names, the symbols are not correct.

Use

.symfix C:\debug\symbols

to be able to download PDB files from Microsoft. Then use

.sympath+ C:\mypdbs

to add the symbols of your own application.

Finally, use

.reload /f

to make use of them.

Improve this answer
1

To resolve function names you need symbol information and symbol information is kept in pdb file if you do not have pdb file then it is definitely a very very hard task until you learn a few tricks / memorize a few patterns / understand few gotchas

windbg knows nothing about symbols if you have the symbol file do .reload /f depending on the psb type(private pdb / public pdb) and compilation type (release / debug ) windbg will resolve public names and or private locals

if you do not have symbol information you may need piece it together

messagebox without symbol info 

0:000> u 401000
image00400000+0x1000:
00401000 6a00            push    0
00401002 6800304000      push    offset image00400000+0x3000 (00403000)
00401007 6819304000      push    offset image00400000+0x3019 (00403019)
0040100c 6a00            push    0
0040100e e807000000      call    image00400000+0x101a (0040101a)
00401013 6a00            push    0
00401015 e806000000      call    image00400000+0x1020 (00401020)
0040101a ff2508204000    jmp     dword ptr [image00400000+0x2008 (00402008)]

based on disassembly you may need to look for the right information or simply view the hex i know MessageBoxA takes two ascii strings so i print them with %ma to know what is pointed by the call (jmp [402008] i print the symbol information of the call (i know microsoft provides public symbols for its core dlls i know user32.dll is a microsoft dll and i know i have the symbols (pdb file for this user32.dll)

0:000> .printf "%ma\n%ma\n%y\n" , 403000, 403019,poi(402008)
Iczelion's tutorial no.2
Win32 Assembly is Great!
user32!MessageBoxA (7e4507ea)

now the same application with symbols

see windbg properly resolving function names when symbol info is available in disassembly 

0:000> u 401000
dbgmsgbox!start [dbgmsgbox.asm @ 17]:
00401000 6a00            push    0
00401002 6800304000      push    offset dbgmsgbox!MsgCaption (00403000)
00401007 6819304000      push    offset dbgmsgbox!MsgBoxText (00403019)
0040100c 6a00            push    0
0040100e e807000000      call    dbgmsgbox!MessageBoxA (0040101a)
00401013 6a00            push    0
00401015 e806000000      call    dbgmsgbox!ExitProcess (00401020)
dbgmsgbox!MessageBoxA:
0040101a ff2508204000    jmp     dword ptr [dbgmsgbox!_imp__MessageBoxA (00402008)]

the information printed out earlier by printf hack is now available with pertinent type information

0:000> ?? (char *) @@((403000))
char * 0x00403000
 "Iczelion's tutorial no.2"
0:000> ?? (char *) @@((403019))
char * 0x00403019
 "Win32 Assembly is Great!"
0:000> ln poi(402008)
(7e4507ea)   user32!MessageBoxA   |  (7e450838)   user32!MessageBoxExW
Exact matches:
    user32!MessageBoxA = <no type information>
Improve this answer
4
  • I tried .reload /f but it did not really help. So is this an inherent limitation of WinDbg? I know that I can't expect it to know all the symbols (eg. the names of non-exported functions of ReverseMe) without the PDB files. But I have seen other debuggers and disassemblers show the calls to WinAPI functions correctly. For example, OllyDbg v. 2.01 shows "CALL DWORD PTR DS:[<&USER32.MessageBoxW>]" for the same executable. When I single step the call, WinDbg shows it correctly inside the MessageBoxW function. Would I need to write a custom extension for it to fetch the names for me?
    – dvvr
    Commented Mar 1, 2015 at 16:17
  • please read the complete reply and try to apply all the suggested examples to your current scenerio by using .printf command you can retrieve the symbol information for the call you dont have to write any extension do not compare ollydbg or ida to windbg ollydbg is an excellent usermode debugger and has some inbuilt analysis capability ida's disassembler also has analysis capability builtin to identify patterns windbg is primarly meant for kernel debugging. user mode debugging with fancy function names is not the contract for windbg.
    – blabb
    Commented Mar 2, 2015 at 6:19
  • @blabb: "user mode debugging with fancy function names is not the contract for windbg." - I solely (>95%) use WinDbg for user mode debugging.
    – Thomas Weller
    Commented Mar 24, 2015 at 22:14
  • yeah sure you can use windbg for usermode debuging the issue was about display of fancy function names without relevent pdb files where other usermode debugers like ollydbg are a bit better and my reply points to some workarounds on how to find some clues about symbols
    – blabb
    Commented Mar 24, 2015 at 23:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.