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
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.
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
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
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)???
...
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?
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???
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?)
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#.
...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).
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" ?
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>
Yes, CTL-F works! THANK YOU!!!
The status bar @ the bottom shows line# and col#...DUH!!! THANKS AGAIN!
You're welcome :t
F9 is also cool, tho I DO have to ALWAYS open the source window, even if it's already there, whether I use this F9 or BP xxx in the command window, to be
able to step thru my source.
Quote from: sinsi on January 25, 2014, 02:44:34 PM
Have you made ''svtpf" PUBLIC?
...
Never occurred to me. But it seems to work. Thank you!
Quote from: vertograd on January 25, 2014, 09:20:17 PM
Also you may make all symbols public by adding /Zf option to ML command line
Great to know. But it does not work for me. I'll work on it.
0:000> bpkey
Bp expression 'key' could not be resolved, adding deferred bp
0:000> bl
0 eu 0001 (0001) (key)QuoteWhen 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
ntdll!DbgBreakPoint:
7c90120e cc int 3
0:000> dt lfw!*
lfw!HDC
lfw!HIGHCONTRASTA
lfw!SV2CVW2_PARAMS
lfw!USER_INFO_1006
lfw!MDICREATESTRUCTA
lfw!EMREOF
lfw!LPBYTE
...Huge list, 88k, includes at end [at least many of] my symbols in no discernable order, eg
0040f320 lfw!ktb
00410748 lfw!mwxx
0040f250 lfw!ctr
00413be0 lfw!obpl
004178de lfw!smcap
00417444 lfw!fla0
0040dd0a lfw!mvar78
0040dc81 lfw!mvar68
0040dc15 lfw!mvar58
0040db88 lfw!mvar48
0040db00 lfw!mvar38
0040da73 lfw!mvar28
0040d9ec lfw!mvar18
0041345a lfw!inpsrc
00413b78 lfw!clsr
004174ac lfw!insp
00414102 lfw!omscThey appear to be all data symbols.
Do you want me to post the whole list, or attach a zip?
...
Quote from: MtheK on January 26, 2014, 01:11:06 AM
I also use /Zi and /coff (latter required also) in the ml cmd-line to make the .pdb.
Can't speak for WinDbg but Olly needs only
ml /c /coff /Zi ...
link /debug ...
Quote from: vertograd on January 26, 2014, 06:10:35 AM
Quote from: raleep on January 26, 2014, 05:50:54 AM
...
Do you want me to post the whole list, or attach a zip?
No, thank you :biggrin:
I just wanted to make sure that WinDbg loads the symbols . Sometimes I use 'dt' when I have troubles with setting breakpoints. BTW is "svtpf" listed by 'dt' or 'x' commands?
svtpf is not listed by 'dt'. I haven't tried 'x'.
QuoteQuote from: raleep on January 26, 2014, 05:13:48 AM
Quote from: sinsi on January 25, 2014, 02:44:34 PM
Have you made ''svtpf" PUBLIC?
...
Never occurred to me. But it seems to work. Thank you!
Is the problem solved now?
It is good enough for my present needs. 2 remaining problems, which I will not be working on immediately:
Breakpoints set by this method are transient and have to be reset to appear in the next WinDbg session,
/Zf does not work for me, so I know no way to make all symbols public.
Even if these problems were resolved, my recent experience has shown me how limited is the utility of accessing code symbols from the command window.
Thanks
deleted
Ah: /Zi AND /Zf TOGETHER now works w/bp. I added SYMCHK (w/its' weird way I have to place my .pdb) to my .bat and when I keep /Zi out, SYMCHK fails as "mis-matched" (my cmd-line options) but says this:
DBGHELP: DSNTODAY - public symbols
and if I remove /Zf, it says this:
DBGHELP: DSNTODAY - private symbols & lines
but I guess it's for .data only. I've always used /Zi.
...and an OOPS in SYMCHK itself:
[SYMCHK] Line nubmers: TRUE
;)
DUMPBIN seems to show my .code labels, for example:
SECTION HEADER #6
COFF SYMBOL TABLE
5F5 00005F43 SECT1 notype () Static | ABENDINUSE
and what I assume is a displacement matches what's in .lst:
00005F43 ABENDINUSE:
so maybe somehow WinDbg could use them?
I made some tests with Olly and JWasm, and they showed that
/Zi turns on symbols of local args (but no global jumps)
/Zf turns on jumps (but no local symbols)
Do not assume that ML does the same.
DUMPBIN runs quirky. DBH seems better; SRCH shows each of my labels in 1 of 32 groups:
4 0 SymTagLabel : mainCRTStartup
4d 100a3b8 SymTagData : ACTSHORT
268 100f000 SymTagData : SECDESC
d94 0 SymTagLabel : ABENDINUSE
tho it's from the .pdb. SymTagLabels seem to be my .code, and SymTagDatas my .data, labels. Perhaps all but 1 .code is N/A if the "displ" is 0 (all my SymTagLabels are 0)? All my SymTagDatas equal my displ if I subtract that x'100a000' from it.
An ENUM program!* shows those other (EXTRN; addrs outside of my .code bounds? other "CSECTs"?) (WinAPI "commands") symbols.
FINALLY! I can NOW use my .code labels in a bp command in the command window. Kinda crappy, but if I do this right B 4 my ASM END directive:
PUBLIC WRITEOUT
then I can do 'bp WRITEOUT' in the cmd window w/o it saying it can't resolve the symbol. x /v now also shows it. Then F5 (g) stops at it, just like when I use F9 in the source window.
Of course, this means that every label u want to stop on must be coded.
Perhaps there is a way to use the PUBLIC directive to force all .code labels to work this way?