PBM: Dependency Walker never resolves MPR.DLL Parent Import WNetRestoreConnectionA
Vince C.
I've always had that behaviour of Depends.exe when I ran it whatever
executable I open. First the full list of modules shows a sandglass for
every file below and inculding ActiveDS.DLL. Second MPR is displayed red and
there is a message saying "Warning: At least one module has an unresolved
import due to a missing export function in a delay-load dependent module."
I must use Depends.exe that came with Visual Studio 6 instead. I've tried
Depends.exe that comes with Platform SDK February 2001 and Platform SDK
October 2002; same results. Can someone tell me what's wrong?
Thanks.
Vince C.
Maximus
>
> I must use Depends.exe that came with Visual Studio 6 instead. I've tried
> Depends.exe that comes with Platform SDK February 2001 and Platform SDK
> October 2002; same results. Can someone tell me what's wrong?
>
You might want to try out Dependency Scanner from PE Explorer
http://www.heaventools.com
~~~~
Max
![Li-Yan Zhang [MS]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Li-Yan Zhang [MS]
The shell does some funky stuff with respect to mpr.dll (they link to both
the NT version of mpr.lib and the Win9x Ansi version so their binary can
run on both platforms) that confuses depends.exe.
WNetRestoreConnectionA is a Win9x-only API (NT only supports
WNetRestoreConnectionW. As a result, depends.exe has trouble with
shlwapi.dll since WNetRestoreConnectionA really isn't in mpr.dll, though
that API will never be called by shlwapi.dll on NT.
If you scenario is similar, please don't worry about it--it's a non-issue.
Thanks,
Li-Yan Zhang
VS.NET, Visual C++
Microsoft
This posting is provided "AS IS" with no warranties, and confers no rights.
Got .Net? http://www.gotdotnet.com
Vince C.
Yes, it is in all case I think but I've only checked a few and not the
zillions of dlls on my system ;)
> The shell does some funky stuff with respect to mpr.dll (they link to both
> the NT version of mpr.lib and the Win9x Ansi version so their binary can
> run on both platforms) that confuses depends.exe.
> WNetRestoreConnectionA is a Win9x-only API (NT only supports
> WNetRestoreConnectionW. As a result, depends.exe has trouble with
> shlwapi.dll since WNetRestoreConnectionA really isn't in mpr.dll, though
> that API will never be called by shlwapi.dll on NT.
>
> If you scenario is similar, please don't worry about it--it's a non-issue.
Well, thanks, Li. But it looks like a bug - you call it «confusion» ;).
Isn't there a way to setup a proper in the lookup folder configuration to
avoid all this and get a clear view? Since version 1.0 doesn't seem to be
confused, there should be a way to have above versions «mimic» the way
version 1.0 resolves externals, shouldn't there?
Besides lots of binaries are marked with the sandglass and I really dislike
this as it is only confusing me with what's going on. Isn't there a
workaround to have Depends.exe lookup the right binaries in the right
locations?
Thanks.
Vince C.
Steve Miller
This is normal and not a bug in Dependency Walker. The sandglass you
see next to many modules means that those modules are delay-loaded.
Delay loaded modules are only loaded if actually called into. It is
essentaully the same as calling LoadLibrary followed by GetProcAddress
on all the used functions, except that the code is automatically
generated by the linker and a delay-load static library.
Many people use delay-load DLLs when they are not sure if a DLL exists
or if a function in a DLL exists. In the case of MPR.DLL, it does not
export WNetRestoreConnectionA on Windows XP. That function only
exists in the Windows 9x/Me version of MPR.DLL. SHLWAPI.DLL calls
WNetRestoreConnectionA on Windows 9x/Me and WNetRestoreConnectionW on
Windows NT/2K/XP. By delay-loading MPR.DLL, it can choose which
function it needs to call at runtime and then call it. On Windows XP,
SHLWAPI.DLL never attempts to call WNetRestoreConnectionA, so there is
not a problem. However, Dependency Walker does not know this and sees
WNetRestoreConnectionA listed as a potential dependency, so it flags
it as a warning. There is no way to know if a module will actually
call a function in another module at runtime. In the case of
SHLWAPI.DLL, it is well known that it does not call
WNetRestoreConnectionA on Windows XP.
Usually you can ignore warnings in Dependency Walker unless your
program is having problems. If Dependency Walker finds a real
problem, it will flag it as an error and not a warning.
This is also talked about in the FAQ at
http://www.dependencywalker.com
- Steve
Vince C.
"Steve Miller" <stev...@pobox.com> a écrit dans le message de news:
e600951c.02123...@posting.google.com...
[...]
> This is normal and not a bug in Dependency Walker. The sandglass you
> see next to many modules means that those modules are delay-loaded.
> Delay loaded modules are only loaded if actually called into. It is
> essentially the same as calling LoadLibrary followed by GetProcAddress
> on all the used functions, except that the code is automatically
> generated by the linker and a delay-load static library.
>
[...]
> Usually you can ignore warnings in Dependency Walker unless your
> program is having problems. If Dependency Walker finds a real
> problem, it will flag it as an error and not a warning.
You might find I'm insisting but I've learnt a software should report any
error or warning it encounters. If it is a real error or warning the user
must fix it. If it is a false positive the developer must fix it. Fair
enough.
Here we found ourselves in front of something that is reported by
Depends.exe as a warning but the story tells "it's normal under XP"... Hmmm,
if it's normal, then the program must not report it is an error. If the
program has no bugs, the warning is true and the previous sentence is...
wrong. This is called a paradox.
Anyway I don't like that
warning-that-is-not-a-warning-and-which-I-can-safely-ignore; because I'm a
developer and developers don't like warnings nor errors. Any normal
situation should be reflected as such instead of asking the user not to
mind. I'm inventing nothing; I'm just putting what I've learnt from WOSA in
simple words.
So my suggestion is if it's normal, then Depends.exe should be aware not to
look for WNetRestoreConnectionA whenever it "realizes" it runs under XP (or
W2K or whatever). We, developers, have been asked many times by Microsoft
(see WOSA) to check the platform under which our software are running. So
why should Depends.exe get an exemption?
And, frankly, there are better icons to show delay-load than a sandglass;
say a lightning, for instance since it clearly shows something dynamic.
Moreover it appears sometimes in VB to show that concept. A sanglass means
"still processing" to me. Although the information appear in the tree, the
user who, like me, is used to the good-looking concepts Microsoft has tought
many times, feels it a bit misleading. I think you'll agree on that.
Best regards,
Vince C.
Steve Miller
> So my suggestion is if it's normal, then Depends.exe should be aware not to
> look for WNetRestoreConnectionA whenever it "realizes" it runs under XP (or
> W2K or whatever). We, developers, have been asked many times by Microsoft
> (see WOSA) to check the platform under which our software are running. So
> why should Depends.exe get an exemption?
Depends is a diagnostic tool that just reports what it sees. It does
know what OS it is running on, but it doesn't skew the results because
of it. In the case of SHLWAPI.DLL, that module clearly lists
WNetRestoreConnectionA in its delay-load import table. Depends is not
going to just ignore this. Who knows, maybe a new version of
SHLWAPI.DLL will be released that does require WNetRestoreConnectionA
on XP, and will break applications. Then people would be saying, "why
doesn't Depends tell me this?"
These special cases are not as simple as "I'm on XP, so ignore this
case". Modules can be redistributed to other OS'es, some future patch
may change the behavior of SHLWAPI.DLL, etc. It is easier to just
report the truth than to try an make assumptions about what is going
on.
Just in the last few weeks, I've started seeing MPRAPI.DLL,
NETSHELL.DLL, NETCFGX.DLL, and NETMAN.DLL all having issues with
missing delay-load functions in SETUPAPI.DLL. Everything seems to run
fine, so I'm guessing this is normal. I wouldn't want Depends to
hardcode the removal of this warning either. If Depends followed this
model, there would have to be a new release of Depends every time some
developer decides to delay-load to a module missing a function.
One feature that might be nice to have is to allow users to suppress
certain warnings. In the case of SHLWAPI.DLL, you would see it the
first time, but could choose to never see it again for that version of
SHLWAPI.DLL. Depends could maybe even have an option to disable all
warnings, or just delay-load warnings.
- Steve
Vince C.
> Depends is a diagnostic tool that just reports what it sees. It does
> know what OS it is running on, but it doesn't skew the results because
> of it. In the case of SHLWAPI.DLL, that module clearly lists
> WNetRestoreConnectionA in its delay-load import table. Depends is not
> going to just ignore this. Who knows, maybe a new version of
> SHLWAPI.DLL will be released that does require WNetRestoreConnectionA
> on XP, and will break applications. Then people would be saying, "why
> doesn't Depends tell me this?"
You're right after all. Depends detects an error/warning and reports it,
full stop. But I'd said "if it's normal" (i.e. having a reference to a
non-existing entry under XP) then the tool should be fixed. OTOH it also
meant: and if it's not, then the system must be fixed.
However, what is not normal - and you seem to agree on that too - is to have
a reference to a non existing function. So leave Depends intact and have the
system fixed instead. After all the one which is not normal is the system,
isn't it :-) ?
> These special cases are not as simple as "I'm on XP, so ignore this
> case". Modules can be redistributed to other OS'es, some future patch
> may change the behavior of SHLWAPI.DLL, etc. It is easier to just
> report the truth than to try an make assumptions about what is going
> on.
I also think so, as I explained above.
> One feature that might be nice to have is to allow users to suppress
> certain warnings. In the case of SHLWAPI.DLL, you would see it the
> first time, but could choose to never see it again for that version of
> SHLWAPI.DLL. Depends could maybe even have an option to disable all
> warnings, or just delay-load warnings.
Good idea. And I would also add an option to enable delay-load analysis.
Just to get back to the same situation as version 1.0, which only looked for
hard-coded dependencies.
Best regards,
Vince C.