[Winpcap-users] WanPacket.cpp, DllMain, and LoadLibrary

Gianluca Varenni gianluca.varenni at cacetech.com
Mon Aug 29 16:17:03 GMT 2005

----- Original Message ----- 
From: "Bryan Kadzban" <bryan at kadzban.is-a-geek.net>
To: <winpcap-users at winpcap.org>
Sent: Sunday, August 28, 2005 7:17 PM
Subject: [Winpcap-users] WanPacket.cpp, DllMain, and LoadLibrary

>I was recently looking into the WanPacket.dll sources (due to a long
> delay when starting a process that used it - the delay didn't have to do
> with it directly, but rather what else it loads, and what they do at
> load time).  I am wondering why WanPacket.cpp does a LoadLibrary on
> npp/ndisnpp.dll.  The DllMain documentation ([1]) says that calling
> LoadLibrary from inside DllMain is prohibited, and a few technical
> people at Microsoft agree ([2], [3], and [4]).  Plus, the module handle
> that LoadLibrary returns is never used (it is checked in a couple
> places, to ensure it's not NULL, but it isn't passed to GetProcAddress
> or similar).
> Is it only being loaded so that other functions can check whether it
> exists before using it (presumably so they don't try to use it on
> NT4/9x/ME)?  If that's the reason, then wouldn't it make more sense to
> attempt the LoadLibrary at the start of those functions, and then do the
> FreeLibrary right after checking the result?  (To keep the DLL lifetime
> correct.)  Or have a separate static-linkage variable instead of the
> module handle, and set it to 1 or 2 depending on whether LoadLibrary
> works from any of these functions, so that you don't have to call it
> more than once?  (Of course, you might not call it at all, depending on
> the functions called by the program.)

The reason for that "strange" LoadLibrary is to fix a bug in the Microsoft 
NetMon COM component (which is used to capture from Dialup/VPN adapters). 
Basically, that DLL should be manually loaded before any attempt to call one 
of the NetMon functions, otherwise you'll experience random Access violation 
crashes. This "dirty" solution was provided directly by the Microsoft 
Support to one of the WinPcap users, and it did fix the issue. It was my 
fault not to add some more comment in the WinPcap code for that weird code.

However, as you mentioned, there is a bug in that code. In fact, as the MSDN 
documentation clearly states (and I didn't see it, my bad), you should not 
call LoadLibrary from with the DllMain function. I plan to add a fix to this 
in the next weeks, and maybe put a test version of WanPacket.dll on the 

Have a nice day

> (Both of these options would basically delay-load the DLL instead of
> loading it at DllMain time.  I don't believe linking directly against it
> is possible, since it's in the npp/ subdirectory of system32/.  But it
> only hosts COM stuff anyway, and COM knows how to load it when needed,
> so directly linking against it should not be required.)
> Or am I missing something?
> Thanks!
> [1]
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp
> [2] http://blogs.msdn.com/larryosterman/archive/2004/04/23/118979.aspx
> [3] http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx
> [4] http://blogs.msdn.com/oleglv/archive/2003/12/12/43069.aspx
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users

More information about the Winpcap-users mailing list