none
Pnp Driver remove/re-install without Reboot requirement RRS feed

  • General discussion

  • Hello everyone,

    I am executing windows driver certification test case which is related with 
    driver uninstall and install cycle. However this case not tolerated with Windows 
    reboot request. I found some logs in the setupapi.app.log same as below;

    cmd: cscript.exe  "Reinstall_With_IO.wsf" /WDTF/DeviceID:"PCI\VEN_000A&DEV_0001&SUBSYS_00000A&REV_01\3&11583659&0&10" 
    /IOPeriod:20000 /Cycles:3 /logo
    !    dvi: Query-removal was vetoed by PCI\PCI\VEN_000A&DEV_0001&SUBSYS_00000A&REV_01\3&11583659&0&10 (veto type 5: 
    PNP_VetoOutstandingOpen)
    !    dvi: Setting needs reboot
    !    dvi: Query-and-Remove failed: 0x17: CR_REMOVE_VETOED

    I've also collected kernel debug logs;
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_DEVICE_RELATIONS...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_REMOVE_DEVICE...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_CANCEL_REMOVE_DEVICE...CriticalDeviceCoInstaller: DIF_INSTALLDEVICE called
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_DEVICE_RELATIONS...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_REMOVE_DEVICE...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_CANCEL_REMOVE_DEVICE...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver_Trace...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver_Trace...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver_Trace...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver_Trace...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver_Trace...
    > DispatchPnP()::IRP_MN_QUERY_CAPABILITIES...
    > debug: DispatchPnP() for \DosDevices\MyDriver00...
    > DispatchPnP()::IRP_MN_QUERY_DEVICE_RELATIONS...
    > debug: DispatchPnP() for \DosDevices\MyDriver_Trace...
    > DispatchPnP()::IRP_MN_QUERY_DEVICE_RELATIONS...[82A872A8] WskProIRPGetAddrInfo is called

    Current driver has already handle IRP_MN_REMOVE_DEVICE. However, it's not enough for reboot requirement issue. 
    I am not sure how can I realise this missig IRP cases so any idea or suggest would be greatly appreciated. 

    Cheers


    • Edited by berte Wednesday, April 3, 2013 12:33 PM info
    Wednesday, April 3, 2013 12:30 PM

All replies

  • Are you handling all the remove actions IRP_MN_QUERY_REMOVE_DEVICE, IRP_MN_CANCEL_REMOVE_DEVICE,  IRP_MN_ REMOVE_DEVICE, and IRP_MN_SURPRISE_REMOVAL?   Is this driver KMDF?  If not why not?  The state machine for PnP/Power is very large and complex and using KMDF is the easiest way to get this support correct. 


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, April 3, 2013 12:42 PM
  • Hi Donald,

    Thanks for your quick reply. This driver is common for Windows and another OS also Windows part is not designed with KMDF. Only IRP_MN_REMOVE_DEVICE has already been handled current driver. I am still digging MSDN pages but I did not come across useful example.

    Could you please share any example for these IRPs ? 

    Cheers


    Peace at home, peace in the world -- Mustafa Kemal

    Wednesday, April 3, 2013 1:23 PM
  • Unless you have a complex state machine for your device trying to reuse a driver from another OS in a Windows environment is just a bad idea.  I have been charged with creating drivers where a Linux or other OS already has a driver many times.  Everytime management pushes to reuse the code, by the time I am done, the code (or code patterns) from the other OS represent 5% of less of the Windows driver, and these are the ones done with KMDF.  Without KMDF the percentage drops to less than 1%.

    If you don't want to use KMDF take a look at the PCIDRV sample in the WDK.  Assume since this is obviously your first Windows PnP driver, that you will need to take 3 to 4 months to get it functioning to a resonable level.  Also, tell your management that you expect to spend 1 to 2 months a year for the next several years applying fixes to the plug and play/power state machine (assuming that the driver is used alot).

    Really, I find it much faster to convert a non-Windows driver to KMDF than to WDM.  And it is more likely that you will be able to find the non-Windows code patterns in a KMDF driver than if you use WDM.  I have handed drivers off to folks who develop for Linux having used WDM and KMDF.  For the WDM driver I end up supporting it, for the KMDF driver most of the time the Linux folks can figure it out, maintain and expand the driver.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, April 3, 2013 1:39 PM
  • Donald, thank you  for your advice and mentor.

    Peace at home, peace in the world -- Mustafa Kemal

    Wednesday, April 3, 2013 4:25 PM
  • for the KMDF driver most of the time the Linux folks can figure it out, maintain and expand the driver.

    Hmm. Then we may see a KMDF-like hack for Linux, quite soon.   :)

    -- pa

    I think VirtualBox guest drivers already makes this option :-)

    Cheers



    Peace at home, peace in the world -- Mustafa Kemal

    Wednesday, April 3, 2013 4:35 PM