0

I am writing a Ndis 6 miniport 802.11 driver for a usb based hardware. The device is working properly - in face when I install the driver it works fine. But if I disable and then enable interface from control panel the initializeHandler is not beeing invoked. Disabled is working perfectly fine. When I enable the interface the driver entry also returns success.

Can anybody please help me out? What would be the reason for it?

Regards, Souvik

Souvik
  • 601
  • 1
  • 8
  • 16

1 Answers1

0

Usually this means that the previous DEVICE_OBJECT has not been fully deleted yet. Its name is still in-use, so the new DEVICE_OBJECT cannot register a new device with that name.

The previous device might get stuck if there are open handles to the device. If you have any code that opens device handles, you should make sure that they get closed. Also make sure that you've free'd all the objects that your miniport allocates. E.g., match calls to NdisAllocateTimerObject with calls to NdisFreeTimerObject. Make sure that your MiniportHaltEx handler is being called and it returns.

Also, if you have a kernel debugger attached, you can inspect the situation with !ndiskd.miniport. It will tell you if the previous miniport is still present, and if so, what state it is in.

Jeffrey Tippet
  • 3,146
  • 1
  • 14
  • 15
  • Thanks a lot for your reply. There are some timers used in my code but they have been created using WdfTimerCreate. Does this kind of timer needs to be freed? I was checking the DDK sample code - they only perform TimerCreate/start/stop on WDFTIMER. Moreover can I stop the WDFTIMER when it is not been started? If I start a WDFTIMER without stopping it, will there be any issue? My MpHalt routine returns successfully. Even I have observed DriverEntry to be called and returned STATUS_SUCCESS when I re-enable the interface. – Souvik Dec 12 '11 at 05:30