To install I added
UpperFilters as a Multi SZ with MyServiceName
to
HKLM\System\CurrentControlSet\Control\Class{4D36E965-E325-11CE-BFC1-08002BE10318}
I then used sc to install the service with the .sys file in system32\drivers
sc create MyServiceName type= kernel start= demand binPath= system32\drivers\MyServiceName.sys
argh I may have found my problem in driver entry. Works on XP and none above though. The way I changed it is probably better anyways. So until I have more problems (hopefully not)…
Thanks very much to those that helped me. I really appreciate it!
Doron,
Do you have a suggestion to disabled/enable the cdrom devices programmically for installs that don’t reboot?
Devcon
d
debt from my phone
From: xxxxx@projekt6.com
Sent: 9/12/2012 12:34 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Legacy Driver Unload problems.
Doron,
Do you have a suggestion to disabled/enable the cdrom devices programmically for installs that don’t reboot?
NTDEV is sponsored by OSR
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
so I have got past all the stuff I have been stuck on however I ran into another problem with removing my control device.
Will IoDeleteDevice remove the device if a user mode has called CreateFile on it and has not closed the handle? Something is preventing my control device from removing and I assume it must be that.
IoDeleteDevice will decrement the pointer reference count on the device. Each open file handle will increment the reference count so the device object will stay alive until the handles are closed. When you mix and match pnp and legacy device objects, unloading becomes difficult to do properly
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@projekt6.com
Sent: Friday, September 14, 2012 12:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Legacy Driver Unload problems.
so I have got past all the stuff I have been stuck on however I ran into another problem with removing my control device.
Will IoDeleteDevice remove the device if a user mode has called CreateFile on it and has not closed the handle? Something is preventing my control device from removing and I assume it must be that.
NTDEV is sponsored by OSR
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
Is there a message or something that you can send that will close all the open handles? What is the proper or best way to force the handles to close so the device can be removed if there is one?
Thanks.
There is no way with a control device to do any of that. That is why a pnp device has a path to do query removal -> removal where apps/drivers who have open handles can gracefully close them to allow unload. If this is a kmdf based filter driver, you can easily enumerate a raw pdo instead of your control device
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@projekt6.com
Sent: Friday, September 14, 2012 1:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Legacy Driver Unload problems.
Is there a message or something that you can send that will close all the open handles? What is the proper or best way to force the handles to close so the device can be removed if there is one?
Thanks.
NTDEV is sponsored by OSR
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
xxxxx@projekt6.com wrote:
Is there a message or something that you can send that will close all the open handles?
There is no way to close an application’s handles out from under it.
Applications are in charge in Windows. That’s why people buy computers,
after all. They are allowed to assume that their handles remain valid.
What is the proper or best way to force the handles to close so the device can be removed if there is one?
The applications must cooperate. If the applications aren’t designed to
cooperate, then you have no choice except to reboot.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It is not a kmdf driver. The only thing I use the control device for is communicate with a shared event created by the user mode application and to send custom IO control codes to. My guess at the solution would be make an event that the user mode would get to close the handle when the control device is getting delete and then allow the driver to wait for that event to be triggered before deleting the device but this would only work for my user mode app. That should be fine as I really don’t want others connecting to it and it is a secured device for only admin and system sessions. Do you know a better solution?
Infinitely blocking and waiting for your app to tell you to change state (allow the remove) is a very very bad idea.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@projekt6.com
Sent: Friday, September 14, 2012 2:12 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Legacy Driver Unload problems.
It is not a kmdf driver. The only thing I use the control device for is communicate with a shared event created by the user mode application and to send custom IO control codes to. My guess at the solution would be make an event that the user mode would get to close the handle when the control device is getting delete and then allow the driver to wait for that event to be triggered before deleting the device but this would only work for my user mode app. That should be fine as I really don’t want others connecting to it and it is a secured device for only admin and system sessions. Do you know a better solution?
NTDEV is sponsored by OSR
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
I do agree that is a bad idea and actually I may have thought about this wrong…
Shouldn’t I be able to just close the device handle after sending the event to the driver. There is no real need to keep the handle open right? The driver makes a pointer to the event with ObReferenceObjectByHandle so both the user mode app and the driver can work with the event. The event is then dereferenced on driver unload. Once I send the handle to the event I should be closing the file handle correct?
Yes, after the even has been referenced the app handle can be closed.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@projekt6.com
Sent: Friday, September 14, 2012 2:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Legacy Driver Unload problems.
I do agree that is a bad idea and actually I may have thought about this wrong…
Shouldn’t I be able to just close the device handle after sending the event to the driver. There is no real need to keep the handle open right? The driver makes a pointer to the event with ObReferenceObjectByHandle so both the user mode app and the driver can work with the event. The event is then dereferenced on driver unload. Once I send the handle to the event I should be closing the file handle correct?
NTDEV is sponsored by OSR
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
How will you detect & handle process termination? There won’t be any way to
deref the event because you won’t see a handle close if there is no handle
open.
or is this a design like ‘there is one and only one process with one and
only one handle shared with KM’?
wrote in message news:xxxxx@ntdev…
I do agree that is a bad idea and actually I may have thought about this
wrong…
Shouldn’t I be able to just close the device handle after sending the event
to the driver. There is no real need to keep the handle open right? The
driver makes a pointer to the event with ObReferenceObjectByHandle so both
the user mode app and the driver can work with the event. The event is then
dereferenced on driver unload. Once I send the handle to the event I should
be closing the file handle correct?
NTDEV,
There is only one user mode application that I plan to use the shared event with. The driver will function with or without the reference to an event. I am testing every way I can think of possible and at this point I have had 0 issues with the event. The only thing I can think of that is left is seeing if it is possible for the user mode application to detect when the driver had reloaded so it can pass a reference to the event again. Also if the user mode application exits without a crash, it first sends a IOCTL to the driver to dereference the event.
so the case you need to worry about is when the app runs, registers it’s
event with the driver, crashes, and a new instance of the app is started.
It obviously want’s to use a new event, but this is hard to differentiate
against two (or more) app instances are started concurrently and your driver
needs to behave reasonably for both cases
wrote in message news:xxxxx@ntdev…
NTDEV,
There is only one user mode application that I plan to use the shared event
with. The driver will function with or without the reference to an event. I
am testing every way I can think of possible and at this point I have had 0
issues with the event. The only thing I can think of that is left is seeing
if it is possible for the user mode application to detect when the driver
had reloaded so it can pass a reference to the event again. Also if the user
mode application exits without a crash, it first sends a IOCTL to the driver
to dereference the event.
When the driver gets a new event, it will first dereference the previous if it has one. I didn’t want to just replace the pointer to the event and leave it in memory if it does not get dereferenced. The event is only used to trigger a notification to the user from the user mode so if it dereference it for a new one, that is ok. If the user mode app crashes, I assume that reference is gone and then event will be cleared after the driver dereferences it correct?