Which is the first NDIS routine registered by miniport with NDIS that needs to be called when networ

Discussion in 'Windows Vista Drivers' started by Praveen Kumar Amritaluru, Dec 19, 2006.

  1. Which is the first NDIS routine registered by miniport with NDIS that needs to be called when network device is disabled?

    When I try to disable the ethernet device, the device manager hangs and device disable never seems to get disabled.

    I see lots of incoming traffic and packets getting indicated from my driver to NDIS.

    \windows\inf\setuapi.app.log has the log enclosed below.

    Wondering why disable is not going through.. Looking at my device context I dont have any pendings sends to be completed.

    Neither is my pause routine getting called. Nor is Ndis close routine getting called. Any what the problem could be?



    Regds,



    cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
    dvi: Using exported function 'NetClassInstaller' in module 'C:\Windows\system32\NetCfgx.dll'.
    dvi: Class installer == NetCfgx.dll,NetClassInstaller
    dvi: Using exported function 'NciDeviceInstall' in module 'C:\Windows\system32\nci.dll'.
    dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
    dvi: Using exported function 'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
    dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
    dvi: Using exported function 'FDCoInstaller' in module 'C:\Windows\system32\fdco1ins.dll'.
    dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
    dvi: CoInstaller 1: Enter 00:28:50.265
    dvi: CoInstaller 1: Exit
    dvi: CoInstaller 2: Enter 00:28:50.281
    dvi: CoInstaller 2: Exit
    dvi: CoInstaller 3: Enter 00:28:50.281
    dvi: CoInstaller 3: Exit
    dvi: Class installer: Enter 00:28:50.281
    dvi: Class installer: Exit
    dvi: Default installer: Enter 00:28:50.281
    dvi: {Change State}
    dvi: Device Instance = '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
    dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
    dvi: Using exported function 'NetClassInstaller' in module 'C:\Windows\system32\NetCfgx.dll'.
    dvi: Class installer == NetCfgx.dll,NetClassInstaller
    dvi: Using exported function 'NciDeviceInstall' in module 'C:\Windows\system32\nci.dll'.
    dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
    dvi: Using exported function 'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
    dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
    dvi: Using exported function 'FDCoInstaller' in module 'C:\Windows\system32\fdco1ins.dll'.
    dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
    dvi: CoInstaller 1: Enter 13:34:36.234
    dvi: CoInstaller 1: Exit
    dvi: CoInstaller 2: Enter 13:34:36.234
    dvi: CoInstaller 2: Exit
    dvi: CoInstaller 3: Enter 13:34:36.234
    dvi: CoInstaller 3: Exit
    dvi: Class installer: Enter 13:34:36.234
    dvi: Class installer: Exit
    dvi: Default installer: Enter 13:34:36.234
    dvi: {Change State}
    dvi: Device Instance = '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
    dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
    dvi: Using exported function 'NetClassInstaller' in module 'C:\Windows\system32\NetCfgx.dll'.
    dvi: Class installer == NetCfgx.dll,NetClassInstaller
    dvi: Using exported function 'NciDeviceInstall' in module 'C:\Windows\system32\nci.dll'.
    dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
    dvi: Using exported function 'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
    dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
    dvi: Using exported function 'FDCoInstaller' in module 'C:\Windows\system32\fdco1ins.dll'.
    dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
    dvi: CoInstaller 1: Enter 14:00:13.609
    dvi: CoInstaller 1: Exit
    dvi: CoInstaller 2: Enter 14:00:13.625
    dvi: CoInstaller 2: Exit
    dvi: CoInstaller 3: Enter 14:00:13.625
    dvi: CoInstaller 3: Exit
    dvi: Class installer: Enter 14:00:13.625
    dvi: Class installer: Exit
    dvi: Default installer: Enter 14:00:13.625
    dvi: {Change State}
    dvi: Device Instance = '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
    dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
    cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
    cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
    <ins>
     
    Praveen Kumar Amritaluru, Dec 19, 2006
    #1
    1. Advertisements

  2. Try ndiskd, see

    http://groups.google.com/group/micr..._frm/thread/4e5ff068f010b374/3cd6528d23ea80cc

    See also

    "INFO: NDIS Debug Tracing and Kernel Debugger Extensions"
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q248413

    "Getting Trace from NETCFG.DLL"
    http://www.ndis.com/papers/

    Stephan
     
    Stephan Wolf [MVP], Dec 19, 2006
    #2
    1. Advertisements

  3. Praveen Kumar Amritaluru

    soviet_bloke Guest

    Neither is my pause routine getting called. Nor is Ndis close routine getting called.


    What are "pause" and "close" routines???? Are you speaking about
    MiniportPnPEventNotify() and MiniportHalt() routines,
    or "close routine" means MiniportShutdown()???

    In your case MiniportHalt() should be the one that gets called first,
    and what you do in in it is just the reverse of MiniportInitialize().
    MiniportShutdown() should not call any NDIS functions.

    Are you sure you have implemented MiniportHalt() properly???

    Anton Bassov
     
    soviet_bloke, Dec 19, 2006
    #3
  4. Thanks Stephan for the link. It gives much useful info for debugging.
     
    Praveen Kumar Amritaluru, Dec 19, 2006
    #4
  5. Hi,

    Here is the information I got in windbg following the instructions in
    the link:
    http://groups.google.com/group/micr..._frm/thread/4e5ff068f010b374/3cd6528d23ea80cc

    It talks about some references being held by upper layers.
    But is that the reason why my miniporthalt routine is not getting called?
    What reference are they talking about?

    Is it some sends pending to be completed? Or some other requests pending?
    If so is it possible to find what exactly is pending/held by my driver that
    is stopping from MiniportHalt routine getting called?

    Regds,


    4.000044 82c55ad0 0002447 Blocked nt!KiSwapContext+0x26
    nt!KiSwapThread+0x389
    nt!KeWaitForSingleObject+0x414
    ndis!ndisPauseMiniport+0x157
    ndis!ndisCloseMiniportBindings+0x18d
    ndis!ndisPnPRemoveDevice+0x1ab
    ndis!ndisPnPDispatch+0x2ec
    nt!IovCallDriver+0x252
    nt!IofCallDriver+0x1b
    nt!ViFilterDispatchPnp+0xd3
    nt!IovCallDriver+0x252
    nt!IofCallDriver+0x1b
    nt!IopSynchronousCall+0xce
    nt!IopRemoveDevice+0xd5
    nt!PnpRemoveLockedDeviceNode+0x172
    nt!PnpDeleteLockedDeviceNode+0x2b
    nt!PnpDeleteLockedDeviceNodes+0x4c
    nt!PnpProcessQueryRemoveAndEject+0x8ac
    nt!PnpProcessTargetDeviceEvent+0x38
    nt!PnpDeviceEventWorker+0x201
    nt!ExpWorkerThread+0xfd
    nt!PspSystemThreadStartup+0x9d
    nt!KiThreadStartup+0x16




    kd> !ndiskd.miniports
    NDIS Driver verifier level: fa
    NDIS Failed allocations : 0
    Miniport Driver Block: 91b58df0, Version 1.0
    Miniport: 97ffd488, NetLuidIndex: 2, IfIndex: 15, Microsoft ISATAP Adapter
    Miniport Driver Block: 936e1570, Version 0.1
    Miniport: 936e60e8, NetLuidIndex: 4, IfIndex: 10, <xyz>
    Miniport Driver Block: 869e1200, Version 0.0
    Miniport: 89e54370, NetLuidIndex: 1, IfIndex: 3, WAN Miniport (PPTP)
    Miniport Driver Block: 89e55c48, Version 0.0
    Miniport: 869e1488, NetLuidIndex: 0, IfIndex: 4, WAN Miniport (PPPOE)
    Miniport Driver Block: 89e584e0, Version 0.0
    Miniport: 89e550e8, NetLuidIndex: 0, IfIndex: 5, WAN Miniport (IPv6)
    Miniport: 869ef0e8, NetLuidIndex: 3, IfIndex: 6, WAN Miniport (IP)
    Miniport Driver Block: 868fcdb0, Version 0.0
    Miniport: 869f60e8, NetLuidIndex: 0, IfIndex: 2, WAN Miniport (L2TP)
    Miniport Driver Block: 868f7d40, Version 0.0
    Miniport: 868fc0e8, NetLuidIndex: 5, IfIndex: 9, Teredo Tunneling
    Pseudo-Interface
    kd> !ndiskd 936e60e8
    No export ndiskd found
    kd> !ndiskd.miniport 936e60e8

    Miniport 936e60e8 : <xyz>, v6.0

    AdapterContext : 93719000
    Flags : 2c452218
    BUS_MASTER, 64BIT_DMA, IGNORE_TOKEN_RING_ERRORS
    DESERIALIZED, RESOURCES_AVAILABLE, SUPPORTS_MEDIA_SENSE
    DOES_NOT_DO_LOOPBACK, MEDIA_CONNECTED, SG_DMA
    PnPFlags : 00700031
    PM_SUPPORTED, REMOVE_IN_PROGRESS, DEVICE_POWER_ENABLED
    VERIFYING, HARDWARE_DEVICE, NDIS_WDM_DRIVER
    MiniportState : STATE_PAUSING
    IfIndex : 10
    Ndis5MiniportInNdis6Mode : 0
    InternalResetCount : 0000
    MiniportResetCount : 0000
    References : 7
    UserModeOpenReferences: 0
    PnPDeviceState : PNP_DEVICE_REMOVED
    CurrentDevicePowerState : PowerDeviceD0
    Bus PM capabilities
    DeviceD1: 1
    DeviceD2: 1
    WakeFromD0: 0
    WakeFromD1: 1
    WakeFromD2: 1
    WakeFromD3: 1

    SystemState DeviceState
    PowerSystemUnspecified PowerDeviceUnspecified
    S0 D0
    S1 D3
    S2 D3
    S3 D3
    S4 D3
    S5 D3
    SystemWake: S4
    DeviceWake: D3

    WakeupMethods Enabled 2:
    WAKE_UP_PATTERN_MATCH
    WakeUpCapabilities:
    MinMagicPacketWakeUp: 4
    MinPatternWakeUp: 4
    MinLinkChangeWakeUp: 4
    Current PnP and PM Settings: : 00000030
    DISABLE_WAKE_UP, DISABLE_WAKE_ON_RECONNECT,
    No Resources Allocated
    MediaType : 802.3
    DeviceObject : 936e6030, PhysDO : 936a0ac0 Next DO: 936cbdc0
    MapRegisters : 00000000
    FirstPendingPkt: 00000000
    DriverVerifyFlags : 00000000
    Miniport Interrupt : 00000000
    Miniport version 6.0
    Miniport Filter List:
    Filter 977cf620: FilterDriver 89e0a0e0, FilterModuleContext 977cf378
    <xyz>-QoS Packet Scheduler-0000
    Miniport Open Block Queue:
    936fe4b8: Protocol 89e23740 = TCPIP, ProtocolBindingContext 936fe868,
    v6.0
    936fec58: Protocol 92c16e78 = LLTDIO, ProtocolBindingContext 936fe008,
    v6.0
    936fd470: Protocol 91b25c50 = RSPNDR, ProtocolBindingContext 936fd820,
    v6.0
    kd> !ndiskd.mopen 936fe4b8
    Miniport Open Block 936fe4b8
    Protocol 89e23740 = TCPIP, ProtocolContext 936fe868, v6.0
    Miniport 936e60e8 = <xyz>, v6.0

    MiniportAdapterContext: 93719000
    Flags : 01000000
    OPEN_USE_MULTICAST_LIST,
    References : 1
    kd> !ndiskd.mopen 936fec58
    Miniport Open Block 936fec58
    Protocol 92c16e78 = LLTDIO, ProtocolContext 936fe008, v6.0
    Miniport 936e60e8 = <xyz>, v6.0

    MiniportAdapterContext: 93719000
    Flags : 00000000
    References : 1
    kd> !ndiskd.mopen 936fd470
    Miniport Open Block 936fd470
    Protocol 91b25c50 = RSPNDR, ProtocolContext 936fd820, v6.0
    Miniport 936e60e8 = <xyz>, v6.0

    MiniportAdapterContext: 93719000
    Flags : 00000000
    References : 1
     
    Praveen Kumar Amritaluru, Dec 19, 2006
    #5
  6. Praveen Kumar Amritaluru

    soviet_bloke Guest

    Praveen,

    I see the possible reason for your problem......

    Imagine if there is some legacy protocol driver bound to your miniport.
    Once it is legacy driver, it does not have PnP handler that would be
    called in event of NIC removal, and, hence, it has no chance to get
    informed about NIC removal so that it cannot unbind itself from your
    miniport. Imagine what would happen if miniport driver had been
    unloaded and the protocol passed NDIS_OPEN_BLOCK that describes the
    binding between this protocol and your driver to any NDIS function that
    expects it.... BANG!!!!!!!


    In order to avoid the above scenario, NDIS just would not allow
    unloading your miniport driver, in the first place, until all legacy
    protocol drivers bound to it unbind themselves from your miniport


    Examine the bindings between your miniport and protocol drivers. If you
    find some legacy protocol bound to it, try to unload it before
    removing your NIC (unless it does not implement its Unload() routine,
    you will be able to unload it via SC Manager)

    Anton Bassov
     
    soviet_bloke, Dec 20, 2006
    #6
  7. So your driver is a NDIS-WDM miniport?

    In this case consider the description of MiniportPnPEventNotify() in
    the DDK, excerpt:

    "When a miniport driver receives notification of a surprise removal, it
    should note internally that the device has been removed and cancel any
    pending IRPs that it sent down to the underlying bus driver. After
    calling the MiniportPnPEventNotify function to indicate the surprise
    removal, NDIS calls the miniport's MiniportHalt function. If the
    miniport driver receives any requests to send packets or query or set
    OIDs before its MiniportHalt function is called, it should immediately
    complete such requests with a status value of
    NDIS_STATUS_NOT_ACCEPTED."

    Stephan
     
    Stephan Wolf [MVP], Dec 20, 2006
    #7
  8. Praveen Kumar Amritaluru

    soviet_bloke Guest

    Stephan,

    And what is supposed to happen when NIC is removed if your miniport is
    PnP-compliant (i.e. at least of NDIS-version 5.1) and some legacy
    protocol driver is still bound to it???

    Apparently, your driver will stay resident, but just return an error on
    all subsequent calls to it (unless NIC gets re-inserted), right?

    Anton Bassov
     
    soviet_bloke, Dec 20, 2006
    #8
  9. Surprise Removal is not applicable to our device. Currently checking out the
    case of pending OIDs or send packets.

    Looks like IRP_MN_QUERY_REMOVE is getting processed by
    underlying bus driver and success returned meaning BD is not holding any
    resources
    including pending IRPs.

    Soviet,

    I dont see legacy protocol driver in the bind list. Do you see any in the
    o/p that I sent yday.
    QUOTe
    936fe4b8: Protocol 89e23740 = TCPIP, ProtocolBindingContext 936fe868,
    v6.0
    936fec58: Protocol 92c16e78 = LLTDIO, ProtocolBindingContext 936fe008,
    v6.0
    936fd470: Protocol 91b25c50 = RSPNDR, ProtocolBindingContext 936fd820
    UNQUOTe

    Regds,
     
    Praveen Kumar Amritaluru, Dec 20, 2006
    #9
  10. Praveen Kumar Amritaluru

    soviet_bloke Guest

    I dont see legacy protocol driver in the bind list. Do you see any in the
    It does not work this way - WinDbg is not going to tell you that. What
    you have to do is:

    1. Get all protocols, bound to your driver, from WinDbg
    2. Check info about your miniport under
    HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318},
    namely, 'UpperBind' value of 'Linkage' key - it list all protocols that
    are configured to bind to your miniport

    3. If you see some protocol driver that appears under (1) but not under
    (2), you can be sure that it has not been installed via Device Manager,
    so that this is not PnP-compliant installation

    Anton Bassov
     
    soviet_bloke, Dec 20, 2006
    #10
  11. Imagine if there is some legacy protocol driver bound to your miniport.
    This is NDIS3, so, obsolete even for NT4.
     
    Maxim S. Shatskih, Dec 21, 2006
    #11
  12. PnP-compliant (i.e. at least of NDIS-version 5.1) and some legacy
    I think there are no more NDIS3 protocols. All protocol drivers shipped with
    NT4 (!) are already NDIS4 and have the unbind handlers, so you can start and
    stop the NIC drivers on NT4 without reboot.

    Also I think that unbind handler is _mandatory according to the documentation_
    for all protocols for w2k and later. So, I have the strong suspect that NDIS3
    protocol is considered to be broken piece of code on w2k and later.
     
    Maxim S. Shatskih, Dec 21, 2006
    #12
  13. (2), you can be sure that it has not been installed via Device Manager,
    Sorry, for protocols, it is not Device Manager, it is NetCfg :)
     
    Maxim S. Shatskih, Dec 21, 2006
    #13
  14. Praveen Kumar Amritaluru

    soviet_bloke Guest

    Maxim,
    What about third-party drivers????? The way they may *THEORETICALLY* be
    written is described below
    According to MSDN documentation, you need to call NdisOpenAdapter()
    only from PtBindAdapter(), and, in order to be able do so, you need
    ..INF file - NDIS needs an info about underlying adapter in the
    registry, because it has to pass the appropriate string to
    PtBindAdapter(). This is the short story.

    The long story is that, in practical terms, you still can install your
    driver via SC Manager, and call NdisOpenAdapter() from DriverEntry -
    even if MSDN says you cannot do so.....
    This works *EVERYWHERE*, including pre-NDIS 6 protocols on Vista....

    In other words, you still can have non-PnP (i.e NDIS3-style)
    installation on your machine on any modern OS system, so that your
    PnP-related functions will never get called - even if you have supplies
    their addresses upon protocol registration, it is, in practical terms,
    still just a legacy driver....


    Anton Bassov
     
    soviet_bloke, Dec 21, 2006
    #14
  15. Praveen Kumar Amritaluru

    soviet_bloke Guest

    Sorry, for protocols, it is not Device Manager, it is NetCfg :)

    This is my omission, I admit....

    Thank you for correction

    Anton Bassov
     
    soviet_bloke, Dec 21, 2006
    #15
  16. I think there are no more NDIS3 protocols. All protocol drivers shipped
    with
    I think that MS does not guarantee NDIS3 protocols to work on w2k anyway.
    So, NDIS3 protocols are no more supported and documented.
    Yes, protocols require installation via NetCfg. The name in the INF must match
    the name passed to NdisRegisterProtocol.
    ....and then MS does not promise you that the OS will not crash just after. If
    the OS will crash - then MS will respond to this "sorry, you have a bug in your
    code, using outdated no-more-supported feature is a bug".
    I would not be surprised that such an approach breaks something in the OS, for
    instance, the ability to unload/reload the NIC drivers.
    ....with who-knows-what negative impact on the OS.
     
    Maxim S. Shatskih, Dec 21, 2006
    #16
  17. Praveen Kumar Amritaluru

    soviet_bloke Guest

    Maxim,


    This is *EXACTLY* why I mentioned the whole thing. The problem is that,
    although such approach normally works, you never know what "surprize"
    in may have for you up its sleeve,
    and when (or if) it is about to show it...

    I don't exclude the possibility that the OP has such protocol driver on
    his machine, so that it started showing its tricks - otherwise, I just
    don't see any obvious reason why his MiniportHalt() does not get
    called.

    Anton Bassov
     
    soviet_bloke, Dec 21, 2006
    #17
  18. If a protocol driver registers with NDIS without having an Unbind handler,
    NDIS will fail the protocol registration. I believe we added this check in
    W2K. So no matter how such a protocol has been "installed" on a system, it
    can not register with NDIS and bind to an adapter (as a protocol you can not
    bind to a miniport without registering with NDIS first).

    I have not read the entire thread yet, but the original problem reported
    might be due to an OID request that has not been completed by the miniport.
    That would block NDIS from unbinding protocols which is a prerequisite for
    halting the miniport.

    -ali
     
    Alireza Dabagh [MS], Dec 24, 2006
    #18
  19. Have you checked to make sure you do not have any outstanding OID requests
    on the miniport?
    Is this an NDIS 6 driver?

    -ali

    --
    This posting is provided "AS IS" with no warranties, and confers no rights.

    Which is the first NDIS routine registered by miniport with NDIS that needs
    to be called when network device is disabled?
    When I try to disable the ethernet device, the device manager hangs and
    device disable never seems to get disabled.
    I see lots of incoming traffic and packets getting indicated from my driver
    to NDIS.
    \windows\inf\setuapi.app.log has the log enclosed below.
    Wondering why disable is not going through.. Looking at my device context I
    dont have any pendings sends to be completed.
    Neither is my pause routine getting called. Nor is Ndis close routine
    getting called. Any what the problem could be?

    Regds,

    cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
    dvi: Using exported function 'NetClassInstaller' in module
    'C:\Windows\system32\NetCfgx.dll'.
    dvi: Class installer == NetCfgx.dll,NetClassInstaller
    dvi: Using exported function 'NciDeviceInstall' in module
    'C:\Windows\system32\nci.dll'.
    dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
    dvi: Using exported function 'WlanDeviceClassCoInstaller' in module
    'C:\Windows\system32\wlaninst.dll'.
    dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
    dvi: Using exported function 'FDCoInstaller' in module
    'C:\Windows\system32\fdco1ins.dll'.
    dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
    dvi: CoInstaller 1: Enter 00:28:50.265
    dvi: CoInstaller 1: Exit
    dvi: CoInstaller 2: Enter 00:28:50.281
    dvi: CoInstaller 2: Exit
    dvi: CoInstaller 3: Enter 00:28:50.281
    dvi: CoInstaller 3: Exit
    dvi: Class installer: Enter 00:28:50.281
    dvi: Class installer: Exit
    dvi: Default installer: Enter 00:28:50.281
    dvi: {Change State}
    dvi: Device Instance =
    '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
    dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
    dvi: Using exported function 'NetClassInstaller' in module
    'C:\Windows\system32\NetCfgx.dll'.
    dvi: Class installer == NetCfgx.dll,NetClassInstaller
    dvi: Using exported function 'NciDeviceInstall' in module
    'C:\Windows\system32\nci.dll'.
    dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
    dvi: Using exported function 'WlanDeviceClassCoInstaller' in
    module 'C:\Windows\system32\wlaninst.dll'.
    dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
    dvi: Using exported function 'FDCoInstaller' in module
    'C:\Windows\system32\fdco1ins.dll'.
    dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
    dvi: CoInstaller 1: Enter 13:34:36.234
    dvi: CoInstaller 1: Exit
    dvi: CoInstaller 2: Enter 13:34:36.234
    dvi: CoInstaller 2: Exit
    dvi: CoInstaller 3: Enter 13:34:36.234
    dvi: CoInstaller 3: Exit
    dvi: Class installer: Enter 13:34:36.234
    dvi: Class installer: Exit
    dvi: Default installer: Enter 13:34:36.234
    dvi: {Change State}
    dvi: Device Instance =
    '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
    dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
    dvi: Using exported function 'NetClassInstaller' in
    module 'C:\Windows\system32\NetCfgx.dll'.
    dvi: Class installer ==
    NetCfgx.dll,NetClassInstaller
    dvi: Using exported function 'NciDeviceInstall' in
    module 'C:\Windows\system32\nci.dll'.
    dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
    dvi: Using exported function
    'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
    dvi: CoInstaller 2 ==
    wlaninst.dll,WlanDeviceClassCoInstaller
    dvi: Using exported function 'FDCoInstaller' in
    module 'C:\Windows\system32\fdco1ins.dll'.
    dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
    dvi: CoInstaller 1: Enter 14:00:13.609
    dvi: CoInstaller 1: Exit
    dvi: CoInstaller 2: Enter 14:00:13.625
    dvi: CoInstaller 2: Exit
    dvi: CoInstaller 3: Enter 14:00:13.625
    dvi: CoInstaller 3: Exit
    dvi: Class installer: Enter 14:00:13.625
    dvi: Class installer: Exit
    dvi: Default installer: Enter 14:00:13.625
    dvi: {Change State}
    dvi: Device Instance =
    '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
    dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
    cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
    cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
    <ins>
     
    Alireza Dabagh [MS], Dec 24, 2006
    #19
  20. Praveen Kumar Amritaluru

    soviet_bloke Guest

    Alireza,
    Indeed, under modern OS versions you cannot register a protocol without
    having specified its Unload() handler, but still you can install it via
    SC Manager and bind to adapters from DriverEntry(), i.e. do it the way
    NDIS3 drivers do (although MSDN says you cannot do it).


    In other words, from NdisRegisterProtocol()'s perspective, you are
    registering a perfectly valid NDIS 4/5 protocol driver, but, unless it
    has been installed with .INF file, NDIS just does not seem to treat
    your driver as PnP-compliant one, despite NDIS version that you have
    specified upon protocol registration. For example, its PtBindAdapter()
    does not get called upon DriverEntry()'s return the way it is supposed
    to happen with protocol drivers of any NDIS version above 3 - instead,
    you have to call NdisOpenAdapter() right from DriverEntry() the way you
    do it with legact drivers if you install it via SC Manager. Therefore,
    unless your driver has been installed with an .INF file, all your
    PnP-related handlers seem to be just a piece of dead code that never
    gets invoked, so that, in practical terms, this is just a legacy driver



    Anton Bassov
     
    soviet_bloke, Dec 24, 2006
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.