PRO:
If I understand you correctly, no. You won’t see “__imp” for anything
linked statically, including the MS CRT, and you won’t even necessarily
see it for things linked dynamically, depending on how it was specified
that a certain function should be exported. I can’t say I recall the
exact details for certain, and I think they may have changed, but,
minimally, you definitely could arrange it with a .DEF file that a
function could be exported by any legal name you wish, or even just an
ordinal. The later is very uncommon these days (the MFC libraries are
the only ones that I can think of these days), but the former covers
just about all windows system files. Using __declspec(dllexport) will
result in __imp, and I’m not sure what EXPORT on the LINK command line
does, or even if it still works. As far as the symbol having typed
arguments and source file names, that more or less necessarily means no
more than that the pdb has private symbols.
This is the best I’ve go. To be honest, I spend 90% of time reverse
engineering where I never have source code, and I’m a trace person for
my own stuff, so I pretty much never see source files in WinDbg.
I hope this helps,
mm
>> xxxxx@garlic.com 2007-02-05 09:34 >>>
Martin,
Yeah, sure I was not very clear. Actually I was hesitating to put this
up
here since it is not directly related drivers, but surely indirectly
related.
No the build process is not mine. There are more than a dozen of
libraries
that are being built, and there are about 4 krnl-mode modules.
Basically the question is that if a symbol shows up like the one I
mentioned without and __imp tag, and shows up like xyz( params types)
[source file], can I assume that it came from a source file that is
being
compiled.
Example: in foo.c I have foo(char *, char *), and maid a library
foo.lib
in bar.c I’ve a main.c that links with foo.lib. Now if I fire windbg,
and
try to see the symbols, while I’m debugging bar.exe, I should see
__imp_foo(char *) or something like this but not without __imp tag.
On the other hand, if I compile both files together, and get bar.exe
then
I should see foo(char *, char *) [foo.c]. Or may be there are other
variations depending on the flags.
VS8 is not needed to build the product, it is there so that some perf
related instrumentation (plug-ins) can be used. Also depending on the
various selection there could be crt sources in the machine.
Since the project files ( including sources ) probably does not
include
any crt source files specifically, I’m bit confused about the way
windbg
is representing the symbol. I said probably, because the build machine
did
not need VS8 and other VS’s don’t have any crt installed specifically
sprint.f. BTW, I could experiment those to find out, but thought
someone
might have seen this kind of thing.
As an aside, actually couple things needs to be straightened out –
-
Need to clean the routine that is exercising sprintf(…) to make
sure
it is not passing some uninitialized stack vars. Then when time comes
make
this to counted version.
-
On the kmode side need to make sure, it is not trying to grab those
user mode helper routine.
Special Note ( and personal opinion based on experience):
-
I’ve seen how traces could be very difficult when services and
drivers
interacts (even though some of the very fine quality frame work for
logging services are in place).
-
And this is where I’m bit unconfortable to use windbg or vs
debugger,
since multiple debugging sessions makes it harder!
-pro
PRO:
This is probably a silly question, but are you sure that the product
was built with link time dynamic linking, and not either static
linking
or runtime dynamic linking? Either of these would explain the lack
of
__imp__xxx symbols, although I think the first would seem fairly
unlikely. If you’re using VC8 and are in fact linking dynamically
at
link time, then I don’t see how a mismatch could be the cause since
VC8
uses assemblies.
I’m probably missing something, but, all in all, I’m not really sure
what you’re saying here.
mm
>>> xxxxx@gmail.com 2007-02-03 10:46 >>>
My apologies if this is OOB traffic.But if I look at the depth, this
might
be the best place to drop this for quick response.
I was hacking a build system that builds couple services and drivers.
A
long
route would be to closely watch what are being compiled and what
libraries
are linked with. The debug build does not work in the sense that it
shows
access violation.
Release build works. Stepping thru the code, gets me to a crt
routine.
By looking at the x command output I see -
xyz!.sprintf(char*, char*) [sprintf.c]
If I could recall, if it were pulled in from lib then I should have
seen
something with __imp somewhere. So to me that in the build env.,
somewhere
it it pulling crt source. By searchinng thru the Harddisk, I found
there is
VS 8 ( ie. 2005) that has the crt sources in the machine. It could be
(
and
I’m guessing at this point) that the lib and the corresponding dll
could be
a mismatch from the target machine’s OS ( XP pro w/ sp2). 32bit env.
Also the stack shows the source info, when I asked for and identical
to
what
I see from the x command.
The routine that exercise the crt routines have uninitialized stack
variables, that could carry random values depending on the position
of
the
stars of our universe :-(, and I will take care of those by rubbing
some
sand paper to the owner’s nose.
Any top off the head idea to confirm my guess?
tia
-pro
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer