News:

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

Main Menu

WinDbg Symbol Problem

Started by raleep, January 25, 2014, 12:29:50 PM

Previous topic - Next topic

raleep

I understand that most of you do not use WinDbg, so this question is mostly for those who do (if any).

WinDbg reports itself unable to find "symbol file".  It is able to find data locations by symbol name (eg. "dbpth1", where pth1 is a data location), but not code locations:

0:003> bpsvtpf
Bp expression 'svtpf' could not be resolved, adding deferred bp


When WinDbg starts, in the command window I get:

CommandLine: d:\lft\lfw.exe -y d:\lft
Symbol search path is: d:\lft
Executable search path is:
ModLoad: 00400000 00438000   lfw.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 69930000 69966000   C:\Program Files\Norton Security Suite\NortonData\21.1.0.18\Definitions\BASHDefs\20140121.001\UMEngx86.dll
ModLoad: 77f10000 77f59000   C:\WINDOWS\system32\gdi32.dll
ModLoad: 7e410000 7e4a1000   C:\WINDOWS\system32\USER32.dll
ModLoad: 763b0000 763f9000   C:\WINDOWS\system32\comdlg32.dll
ModLoad: 77dd0000 77e6b000   C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e70000 77f03000   C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fe0000 77ff1000   C:\WINDOWS\system32\Secur32.dll
ModLoad: 5d090000 5d12a000   C:\WINDOWS\system32\COMCTL32.dll
ModLoad: 7c9c0000 7d1d7000   C:\WINDOWS\system32\SHELL32.dll
ModLoad: 77c10000 77c68000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77f60000 77fd6000   C:\WINDOWS\system32\SHLWAPI.dll
(994.c1c): Break instruction exception - code 80000003 (first chance)
eax=00261eb4 ebx=7ffd7000 ecx=00000007 edx=00000080 esi=00261f48 edi=00261eb4
eip=7c90120e esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:
7c90120e cc              int     3


In my d:\lft directory are among others:
d:\lft\at.bat
LFW.ASM
lfw.exe
lfw.ilk
lfw.obj
lfw.pdb

I assemble using a batch file:

d:\lft\at.bat

d:\prog\masm32\bin\ml /c /coff /Cp /Fl /W2 /Zi /Id:\prog\masm32\include d:\lft\lfw.asm >errs.lfw
if errorlevel 1 goto erfc
d:\prog\masm32\bin\link /SUBSYSTEM:WINDOWS /LIBPATH:d:\prog\masm32\lib /DEBUG /DEBUGTYPE:CV lfw.obj >>errs.lfw
IF errorlevel 1 goto erfc
exit
:erfc
type errs.lfw
pause


Does anyone see what is wrong?

Thanks
Robert

sinsi

Have you made ''svtpf" PUBLIC?

You might also want to make an environment variable if you want to download symbols from Microsoft
_NT_SYMBOL_PATH=srv*f:\asm\symbols*http://msdl.microsoft.com/download/symbols
Of course, change f:\asm\symbols to wherever you want them stored locally, or omit it to always download them.

GoneFishing

Also you may make all symbols public by adding /Zf option to ML command line

When at initial breakpoint try to dump all symbols to console:
Quotedt lfw!*
and post the output here .
We'll see what's wrong with them

MtheK

  I've been using WinDbg for many years.

  I also use /Zi and /coff (latter required also) in the ml cmd-line to make the .pdb.

  I know that symbols don't work for EQUs but DO work w/this:
SCREENBUF BYTE 0 DUP(00h). 

  I've also never been able to use them in code and have to use displacement from .lst to set a bp (ie: bp mainCRTStartup+xxxx) which works.
These are all in .data; a PATHOUT: label in code does NOT show up:
0:000> x /v dsntoday!PATH*
prv global 0040a938    4 DSNTODAY!PATHEXTD = 0
prv global 0040a3aa    1 DSNTODAY!PATHEXTF = 0x4e 'N'
prv global 0040a93c    1 DSNTODAY!PATHEXTP = 0x2e '.'
prv global 0040c10b    2 DSNTODAY!PATHL = 0
prv global 0040a934    4 DSNTODAY!PATHEXTL = 0x400
prv global 0040a946    1 DSNTODAY!PATHEXTO = 0x00 ''
prv global 0040a3ab    1 DSNTODAY!PATHEXTN = 0x4e 'N'
prv global 0040a3ac    1 DSNTODAY!PATHEXTSKIP = 0x00 ''
prv global 0040a92c    1 DSNTODAY!PATHEXT = 0x50 'P'

  But they work great in .data when I have my source open and use the memory window.

  A dt for me shows HUNDREDS of items, all un-familiar:
          DSNTODAY!HDC
...
except for .data labels:
0:000> dt DSNTODAY!path*
          DSNTODAY!PathData
          DSNTODAY!PathData
0040a938  DSNTODAY!PATHEXTD
0040a3aa  DSNTODAY!PATHEXTF
0040a93c  DSNTODAY!PATHEXTP
0040c10b  DSNTODAY!PATHL
0040a934  DSNTODAY!PATHEXTL
0040a946  DSNTODAY!PATHEXTO
0040a3ab  DSNTODAY!PATHEXTN
0040a3ac  DSNTODAY!PATHEXTSKIP
0040a92c  DSNTODAY!PATHEXT


MtheK

  For some reason, that   /Zf   failed for me; using it, I can no longer use
'bp mainCRTStartup' in that my source line no longer turns RED and PF5 (g) no
longer works. Going back to   /Zi   then works as B 4 (ie: bp turns my line
RED and PF5 stops there)???

GoneFishing

#5
...

MtheK

   I also know that, once I re-asm&lnk, previous crashdumps fail:

Unable to load image h:\d\TOOLS\MYPROGS\DSNTODAY\V1R2M1\DSNTODAY.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for DSNTODAY.exe
*** ERROR: Module load completed but symbols could not be loaded for DSNTODAY.exe

I have to re-create the dump, which then works:

*** WARNING: Unable to verify checksum for DSNTODAY.exe

I think that's 'cause of the timestamp change?

MtheK

  Also, and I don't know why, I've found that, just B 4 the LINK, I have to
DELETE the existing .pdb or I get some "conflicts" (I don't remember the specifics)
when debugging???

MtheK

  Ah, I doc'd why:

rem WARNING : Internal timestamp inconsistency.
rem WARNING : The PDB file is from another time.   (from DUMPPE if NOT del'd 1st?)

MtheK

  And, I gotta say this again: I LOVE how it pinpoints the failing line:

FOLLOWUP_IP:
DSNTODAY!mainCRTStartup+2e2c [DSNTODAY.ASM @ 4153]
00403e2c cc              int     3

FAULTING_SOURCE_CODE: 
  4149:          JE    YESINT3
  4150:          CMP   DEBUGFLG,'Y'
  4151:          JNE   NOINT3
  4152: YESINT3:
> 4153:          INT   3
  4154: NOINT3:
  4155:          RESTREGS
  4156:          RET
  4157:
  4158:

but dis-like that the source window, and .lst, doesn't show line#, so I had to write
a separate program to show the line#.


MtheK

...nor does the source window seem to have a FIND; I can select EDIT
which starts NOTEPAD, but that also doesn't have line# (a la SPF2 in IBM MF).

GoneFishing

no need to write your own addition for source line# support:
just look to status bar for cursor position in source window or check "Show source line for each instruction " for disassembly window.

Did you try "CTRL-F" ?


MtheK

  Ah, dis-asm...cool.

  I'm in Win7 and 'x' also works, but NOT for code label PATHOUT:

0:000> x /v DSNTODAY!*
*** WARNING: Unable to verify checksum for DSNTODAY.exe
pub global 00401000    0 DSNTODAY!mainCRTStartup = <no type information>

MtheK

  Yes, CTL-F works! THANK YOU!!!

MtheK

  The status bar @ the bottom shows line# and col#...DUH!!! THANKS AGAIN!