I have a simple KMDF driver for a custom PCIe device on a 64-bit Windows 2008 R2. The driver is handling cancellations correctly (i.e., when the application is terminated with a + c, the active request is completed in the EvtRequestCancel. Event tracing confirms this.
However, when I attempt to uninstall the driver or disable the device using Control Manager when a request is active, the progress bar spins for a couple of seconds and a message pops up that the system must be restarted for changes to take effect. If the request is active the operation completes immediately.
Tracing shows that the EvtIoStop callback is not being called. I was thinking that this event will be called for this case (this is a sequential, power managed queue processing only IOCTL requests). Is this assumption correct or do I need to be ding something else? The code to create the queue follows.
Thanks!
// Configure a non-default, sequential, queue for IoControl requests.
WDF_IO_QUEUE_CONFIG_INIT(
&wdfQueueConfig,
WdfIoQueueDispatchSequential
);
wdfQueueConfig.EvtIoDeviceControl = DriverEvtIoDeviceControl;
wdfQueueConfig.EvtIoStop = DriverEvtIoStop;
ntsRC = WdfIoQueueCreate(
wdfDevice,
&wdfQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&(pDevContext->wdfQueueIoCtlPatterns)
);
What does setupapi.dev.log look like? Who is vetoing the operation? Does the app with the open handle register for file handle notifications (on the file handle itself, not notifications on the device interface arrival) and close the handle when a query remove comes?
Look at !wdfkd.wdflogdump to see what is happening as well.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@bellsouth.net
Sent: Friday, March 21, 2014 9:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Control Panel driver uninstall/disable
I have a simple KMDF driver for a custom PCIe device on a 64-bit Windows 2008 R2. The driver is handling cancellations correctly (i.e., when the application is terminated with a + c, the active request is completed in the EvtRequestCancel. Event tracing confirms this.
However, when I attempt to uninstall the driver or disable the device using Control Manager when a request is active, the progress bar spins for a couple of seconds and a message pops up that the system must be restarted for changes to take effect. If the request is active the operation completes immediately.
Tracing shows that the EvtIoStop callback is not being called. I was thinking that this event will be called for this case (this is a sequential, power managed queue processing only IOCTL requests). Is this assumption correct or do I need to be ding something else? The code to create the queue follows.
Thanks!
// Configure a non-default, sequential, queue for IoControl requests.
WDF_IO_QUEUE_CONFIG_INIT(
&wdfQueueConfig,
WdfIoQueueDispatchSequential
);
wdfQueueConfig.EvtIoDeviceControl = DriverEvtIoDeviceControl;
wdfQueueConfig.EvtIoStop = DriverEvtIoStop;
ntsRC = WdfIoQueueCreate(
wdfDevice,
&wdfQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&(pDevContext->wdfQueueIoCtlPatterns)
);
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
The application that opens a handle to the device MUST call RegisterDeviceNotification for that handle (use DBT_DEVTYP_HANDLE/DEV_BROADCAST_HANDLE), and MUST close the handle in the context of WM_DEVICECHANGE/DBT_DEVICEREMOVEPENDING message.
The setupapi.dev log has entries saying that the query removal was vetoed by my driver with "(veto type 5: PNP_vetoOutstandingopen).
This makes sense because the user mode application has a “file” handle open to the device (created via CreateFile).
At the moment, the application is simply performing a non-overlapped DeviceIoControl and waiting for completion (which I am not doing as normal inside the driver in order to test driver implementation of driver uninstall/disable – expecting a EvtIoStop which will complete the operation).
From your suggestions above it seems that the behavior I am observing is normal and that I need to have the application register for notifications on the file handle and close it when the query remove arrives? Could you please direct me to a couple of function names so I can lookup and teach myself how to setup these notifications!
Thanks!
RegisterDeviceNotification. You will probably want CancelIo or CancelIoEx on another thread to cancel the synchronous IOCTL call
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@bellsouth.net
Sent: Friday, March 21, 2014 10:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Control Panel driver uninstall/disable
The setupapi.dev log has entries saying that the query removal was vetoed by my driver with "(veto type 5: PNP_vetoOutstandingopen).
This makes sense because the user mode application has a “file” handle open to the device (created via CreateFile).
At the moment, the application is simply performing a non-overlapped DeviceIoControl and waiting for completion (which I am not doing as normal inside the driver in order to test driver implementation of driver uninstall/disable – expecting a EvtIoStop which will complete the operation).
From your suggestions above it seems that the behavior I am observing is normal and that I need to have the application register for notifications on the file handle and close it when the query remove arrives? Could you please direct me to a couple of function names so I can lookup and teach myself how to setup these notifications!
Thanks!
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thank you Don and Alex! I did learn something new today.
One last follow-up: If I open the device in a console mode application (no windows), then is there a way to register for these notifications? RegisterDeviceNotification seems to want a window or service handle to send the notifications to (I don’t really want to implement a service for testing purposes).
If there is no easy way to do this, I will switch my driver testing application over to a Windowed version with overlapped I/O and/or multiple threads.
Thanks for the pointers!
xxxxx@bellsouth.net wrote:
One last follow-up: If I open the device in a console mode application (no windows), then is there a way to register for these notifications? RegisterDeviceNotification seems to want a window or service handle to send the notifications to (I don’t really want to implement a service for testing purposes).
You can create a hidden window in a console application. Just create it
in a separate thread with its own message loop.
(Actually, you can create ANY kind of window in a console application.
The ONLY difference between a console application and a GUI application
is that the console application has an initial connection to a console
window.)
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Your console app would need to spin a thread up, create a hidden window, run the message loop and process the notifications there. You need a second thread anyways to call Cancelio on the synchronous IOCTL call.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@bellsouth.net
Sent: Friday, March 21, 2014 10:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Control Panel driver uninstall/disable
One last follow-up: If I open the device in a console mode application (no windows), then is there a way to register for these notifications? RegisterDeviceNotification seems to want a window or service handle to send the notifications to (I don’t really want to implement a service for testing purposes).
If there is no easy way to do this, I will switch my driver testing application over to a Windowed version with overlapped I/O and/or multiple threads.
Thanks for the pointers!
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Note that you MUST use overlapped I/O in these scenarios. If you open a handle without FILE_FLAG_OVERLAPPED, CloseHandle issued from another thread will block until DeviceIoControl completes.
You need to issue an overlapped DeviceIoControl, and have your thread wait on both event handle for OVERLAPPED, and a SEPARATE event handle that a device notification message handler will set. Note that you MUST use a separate thread for your DeviceIoControl, OR use MsgWaitForMultipleObjectsEx function to wait for the events. In the latter case, you don’t have to have a separate event to notify about cancel.
When you need to cancel DeviceIoControl, call CancelIo from the same thread. Then you MUST wait for the operation to complete as cancelled, before deleting the event. OVERLAPPED structure *must* stay valid until the request is completed and its event is set in OVERLAPPED. Call to CancelIo doesn’t guarantee it.
Make sure your driver doesn’t block inside DEVICE_IO_CONTROL handler.
Ok – thank you to both of you. I do know how to implement hidden threads; was simply wondering if there was another way to receive notifications (e.g., to an event handle). I will implement a full-fledged windows-mode test application if I am going to go through the bother of creating a window and message loop.
The driver itself is well-behaved and does not block inside events 
Cheers!
You can create an invisible window as a receiver of WM_DEVICECHANGE, and use it in a console application, too. You should use a separate thread with a message loop for the window, though, if it’s a console app.
> One last follow-up: If I open the device in a console mode application (no windows), then is there a
way to register for these notifications? RegisterDeviceNotification seems to want a window or
service handle
Console apps can trivially create windows, both visible and hidden ones (the latter is what you need).
The ONLY differences between console/windows app are:
- stdin/out/err
- will CMD wait for it if it is started from CMD or will not?
Note that this notification for a service handle always uses Unicode string (not T string as the doc says).
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com