[Winpcap-users] pcap_findalldevs Hangs when called in Windowsservice

[Gianluca Varenni]

Matt,

sorry for the long delay.

I briefly tried your code, and apart for the issue of the service dependency (which is a known issue of WinPcap), I didn't see the service blocking on pcap_findalldevs. Have you tried running the barebone service on several machines, and see if it blocks?

Have a nice day
GV


----- Original Message ----- 
  From: matt jaffa 
  To: winpcap-users at winpcap.org 
  Sent: Friday, March 31, 2006 3:29 PM
  Subject: Re: [Winpcap-users] pcap_findalldevs Hangs when called in Windowsservice


  So we added nm and NPF to dependencies to our service and the service started up just fine. But within the Service it is hanging on the pcap_findalldevs. So adding those two dependencies got it to start up but it just sits there in the pcap_findalldevs call. 

  Does anyone have a working service which is using winpcap that just doesn't hang in pcap_findalldevs?

  Thanks
   
  On 3/27/06, Bryan Kadzban <bryan at kadzban.is-a-geek.net> wrote: 
    matt jaffa wrote:
    > Hi,
    >
    > When we are calling pcap_findalldevs in a Windows service the service 
    > seems to hang in that function call.

    Your service needs to depend on NPF.

    The reason is that NPF is set up to start on demand (basically, when the
    first program makes a packet.dll or wpcap.dll call, the service will be 
    started), not at startup.  When packet.dll loads (it's a dependency of
    wpcap.dll), it tries to start the NPF service for you, but since your
    service is starting, the service control manager is holding a lock.  It 
    has to release the lock before any other service can start.  (Eventually
    something times out, NPF gets to start, packet.dll loads, and your
    service finishes starting up.)

    The fix is to make NPF start before your service; the only supported way 
    to do this is to set a DependOnService REG_MULTI_SZ value in your
    service's registry key.  The data in the registry value should be the
    name of any services you depend on; setting it to NPF by itself is
    probably sufficient. 

    Er, actually...  If you're using a new enough WinPcap version (probably
    3.1 and newer), you'll also have to depend on the nm (Network Monitor)
    service.  (packet.dll loads up wanpacket.dll, which loads up another DLL 
    that starts the nm service if it's needed.  So the same thing applies;
    nm has to be running before either packet.dll or wanpacket.dll get
    loaded.)  So set it to both NPF and nm.


    _______________________________________________ 
    Winpcap-users mailing list
    Winpcap-users at winpcap.org
    https://www.winpcap.org/mailman/listinfo/winpcap-users 








------------------------------------------------------------------------------


  _______________________________________________
  Winpcap-users mailing list
  Winpcap-users at winpcap.org
  https://www.winpcap.org/mailman/listinfo/winpcap-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20060416/ccfb00a2/attachment.htm