No option to disable my driver

Hi,

I’m in the process of writing a (KMDF) driver for a (driverless) device
that’s created by the isapnp.sys driver (shows up simply as “Motherboard
resources” in DM). My driver attaches to the device, reads the resources
(I/O port range) correctly etc, and appears happy. FWIW it’s based on the
KMDF PLX9X5X source.

Now I normally disable and re-enable the driver via device manager during
the development cycle - dozens if not hundreds of times - copying a new
.sys file into windows/system32/drivers each time.

However, I notice that on this particular driver, I don’t have the
“disable” option. It also happens to be hidden in Device Manager.

I’m guessing that’s because the parent device object (LPC Interface
Controller) is also hidden an doesn’t have a “disable” option either?!?

What do I need to do in my KMDF driver to add the “disable” option? I’m
assuming I need to override some PnP flags and/or callback but I can’t
find any info on what/where???

Any tips would be greatly appreciated!

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

> Hi,

I’m in the process of writing a (KMDF) driver for a (driverless)
device
that’s created by the isapnp.sys driver (shows up simply as
“Motherboard
resources” in DM). My driver attaches to the device, reads the
resources
(I/O port range) correctly etc, and appears happy. FWIW it’s based on
the
KMDF PLX9X5X source.

Now I normally disable and re-enable the driver via device manager
during
the development cycle - dozens if not hundreds of times - copying a
new
.sys file into windows/system32/drivers each time.

However, I notice that on this particular driver, I don’t have the
“disable” option. It also happens to be hidden in Device Manager.

I’m guessing that’s because the parent device object (LPC Interface
Controller) is also hidden an doesn’t have a “disable” option
either?!?

What do I need to do in my KMDF driver to add the “disable” option?
I’m
assuming I need to override some PnP flags and/or callback but I can’t
find any info on what/where???

Any tips would be greatly appreciated!

For KMDF it looks like you could use WdfDeviceSetDeviceState,
initialising the NotDisableable memory of the WDF_DEVICE_STATE parameter
as appropriate. I’m not sure that this will override the case you are
talking about though…

James

Setting NotDisableable to WdfFalse (how many negatives is that?) will not do what you want. Once not disableable is set, it cannot be cleared on later query device caps. Mark, basically you are hosed. The only thing that you might possibly do to aid development might be to create a simple KMDF filter for the parent stack and make sure that NotDisableable is WdfFalse there. This might disableable propagate downwards

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Wednesday, February 18, 2009 10:22 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] No option to disable my driver

Hi,

I’m in the process of writing a (KMDF) driver for a (driverless)
device
that’s created by the isapnp.sys driver (shows up simply as
“Motherboard
resources” in DM). My driver attaches to the device, reads the
resources
(I/O port range) correctly etc, and appears happy. FWIW it’s based on
the
KMDF PLX9X5X source.

Now I normally disable and re-enable the driver via device manager
during
the development cycle - dozens if not hundreds of times - copying a
new
.sys file into windows/system32/drivers each time.

However, I notice that on this particular driver, I don’t have the
“disable” option. It also happens to be hidden in Device Manager.

I’m guessing that’s because the parent device object (LPC Interface
Controller) is also hidden an doesn’t have a “disable” option
either?!?

What do I need to do in my KMDF driver to add the “disable” option?
I’m
assuming I need to override some PnP flags and/or callback but I can’t
find any info on what/where???

Any tips would be greatly appreciated!

For KMDF it looks like you could use WdfDeviceSetDeviceState,
initialising the NotDisableable memory of the WDF_DEVICE_STATE parameter
as appropriate. I’m not sure that this will override the case you are
talking about though…

James


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

Doron Holan wrote:

Setting NotDisableable to WdfFalse (how many negatives is that?) will
not do what you want. Once not disableable is set, it cannot be
cleared on later query device caps. Mark, basically you are hosed. The
only thing that you might possibly do to aid development might be to
create a simple KMDF filter for the parent stack and make sure that
NotDisableable is WdfFalse there. This might disableable propagate
downwards

Thanks for your input as usual, Doron.

It seems after making the change I can actually disable the device.
However, DM informs me that resources have changed and that I need to
reboot the system - i.e. the driver doesn’t actually unload. :frowning:

I subsequently tried adding PnPCaps (removable, supriseremovalOK) as well,
but to no avail. I’m guessing for the very reason you mentioned!?!

If I create a filter for the parent stack, any idea which attribute I
would need to set to prevent the “must reboot” scenario? Is it one of the
PnP caps I mentioned above???

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

Removablr means something else, s.r. Ok just means there is no ui when the device spontaneously disappears. I do not think this is due to res requirements changing, rather i think isapnp or another driver is failing the query remove in thw stack and so now the only way to enforce a disable is to reboot. Look at the setupapi logs, it should tell you who vetoed the qury

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mark McDougall
Sent: Wednesday, February 18, 2009 11:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] No option to disable my driver

Doron Holan wrote:

> Setting NotDisableable to WdfFalse (how many negatives is that?) will
> not do what you want. Once not disableable is set, it cannot be
> cleared on later query device caps. Mark, basically you are hosed. The
> only thing that you might possibly do to aid development might be to
> create a simple KMDF filter for the parent stack and make sure that
> NotDisableable is WdfFalse there. This might disableable propagate
> downwards

Thanks for your input as usual, Doron.

It seems after making the change I can actually disable the device.
However, DM informs me that resources have changed and that I need to
reboot the system - i.e. the driver doesn’t actually unload. :frowning:

I subsequently tried adding PnPCaps (removable, supriseremovalOK) as well,
but to no avail. I’m guessing for the very reason you mentioned!?!

If I create a filter for the parent stack, any idea which attribute I
would need to set to prevent the “must reboot” scenario? Is it one of the
PnP caps I mentioned above???

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266


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</http:>

Doron Holan wrote:

Removablr means something else, s.r. Ok just means there is no ui when
the device spontaneously disappears. I do not think this is due to res
requirements changing, rather i think isapnp or another driver is
failing the query remove in thw stack and so now the only way to
enforce a disable is to reboot. Look at the setupapi logs, it should
tell you who vetoed the qury

I think you were right in the 1st place. Although setting
“NotDisableable=WdfFalse” gives me the “Disable” option in DM, the
setupapi.log file suggests that - underneath it all - it’s still not
actually disableable…

#I292 Changing device properties of “ACPI\PNP0C02\2”.
#W109 Device “ACPI\PNP0C02\2” required reboot: Could not disable hardware
profile.

Thanks again Doron! I’ll look at that filter you suggested!

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

Doron Holan wrote:

The
only thing that you might possibly do to aid development might be to
create a simple KMDF filter for the parent stack and make sure that
NotDisableable is WdfFalse there. This might disableable propagate
downwards

A related question - what’s the best way for my driver to access PCI
configuration space of the parent device (enumerated by ISAPNP.SYS)? Do I
need a filter, and in what stack?

I need to extract a memory address from the PCI config space of the LPC
Bus Controller to use in my driver…

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

Mark McDougall wrote:

A related question - what’s the best way for my driver to access PCI
configuration space of the parent device (enumerated by ISAPNP.SYS)? Do I
need a filter, and in what stack?

I think I found something, involving IRP_MN_READ_CONFIG…

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

Yes, that is what you need to use, but you need to do it from a filter on the parent stack, you cannot do this from a child of the pci parent

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mark McDougall
Sent: Thursday, February 19, 2009 7:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] No option to disable my driver

Mark McDougall wrote:

> A related question - what’s the best way for my driver to access PCI
> configuration space of the parent device (enumerated by ISAPNP.SYS)? Do I
> need a filter, and in what stack?

I think I found something, involving IRP_MN_READ_CONFIG…

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266


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</http:>

Remember the WinDbg “.kdfiles” command. Using it, you don’t need to copy
your updated sys files everytime you build your driver. However, you DO have
to be able to refresh the image in memory and typically that means
Disable/Enable, unless you want to reboot everytime.

I did nopt see it mentioned but have you looked at the SetupApi functions?


The personal opinion of
Gary G. Little

.
“Mark McDougall” wrote in message news:xxxxx@ntdev…
> Doron Holan wrote:
>
>> Setting NotDisableable to WdfFalse (how many negatives is that?) will
>> not do what you want. Once not disableable is set, it cannot be
>> cleared on later query device caps. Mark, basically you are hosed. The
>> only thing that you might possibly do to aid development might be to
>> create a simple KMDF filter for the parent stack and make sure that
>> NotDisableable is WdfFalse there. This might disableable propagate
>> downwards
>
> Thanks for your input as usual, Doron.
>
> It seems after making the change I can actually disable the device.
> However, DM informs me that resources have changed and that I need to
> reboot the system - i.e. the driver doesn’t actually unload. :frowning:
>
> I subsequently tried adding PnPCaps (removable, supriseremovalOK) as well,
> but to no avail. I’m guessing for the very reason you mentioned!?!
>
> If I create a filter for the parent stack, any idea which attribute I
> would need to set to prevent the “must reboot” scenario? Is it one of the
> PnP caps I mentioned above???
>
> Regards,
>
> –
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, http:
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266
></http:>

Doron Holan wrote:

Yes, that is what you need to use, but you need to do it from a filter
on the parent stack, you cannot do this from a child of the pci parent

> A related question - what’s the best way for my driver to access PCI
> configuration space of the parent device (enumerated by ISAPNP.SYS)?
> Do I need a filter, and in what stack?

I’m finally back on this project again. I’ve got a KMDF filter driver,
based on the toaster example. It installs and loads OK over ISAPNP.SYS.

I’m trying to call WdfFdoQueryForInterface() from an IOCTL handler in the
filter driver, so I can get the PCI bus interface and then use
GetBusData() and SetBusData(). However, if I specify the filter’s
WDFDEVICE (which I obtained using WdfIoQueueGetDevice()), I get
STATUS_INVALID_PARAMETER.

I’m assuming I need to use some underlying WDFDEVICE?!? Is that correct,
and how do I obtain it from the filter driver?

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

No, it should be the your filter WDFDEVICE (you do not get a WDFDEVICE for any other device object in the stack). !wdfkd.wdflogdump would tell you if the KMDF API failed before it sent the QI, otherwise it could very well be that the underlying bus driver isapnp does not support the interface (since it is a pci bus interface, not really an isa based one)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Tuesday, March 03, 2009 4:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] No option to disable my driver

Doron Holan wrote:

> Yes, that is what you need to use, but you need to do it from a filter
> on the parent stack, you cannot do this from a child of the pci parent

>> A related question - what’s the best way for my driver to access PCI
>> configuration space of the parent device (enumerated by ISAPNP.SYS)?
>> Do I need a filter, and in what stack?

I’m finally back on this project again. I’ve got a KMDF filter driver,
based on the toaster example. It installs and loads OK over ISAPNP.SYS.

I’m trying to call WdfFdoQueryForInterface() from an IOCTL handler in the
filter driver, so I can get the PCI bus interface and then use
GetBusData() and SetBusData(). However, if I specify the filter’s
WDFDEVICE (which I obtained using WdfIoQueueGetDevice()), I get
STATUS_INVALID_PARAMETER.

I’m assuming I need to use some underlying WDFDEVICE?!? Is that correct,
and how do I obtain it from the filter driver?

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266


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</http:>

Doron Holan wrote:

No, it should be the your filter WDFDEVICE (you do not get a WDFDEVICE
for any other device object in the stack). !wdfkd.wdflogdump > driver name> would tell you if the KMDF API failed before it sent the
> QI, otherwise it could very well be that the underlying bus driver
> isapnp does not support the interface (since it is a pci bus interface,
> not really an isa based one)

I’m in the process of downloading the newer WDK (I’m still on 6000) so I
can use the wdflogdump…

In the mean-time, any ideas on how I can access PCI space for the ICH6/7
chipset if I can’t do it via a filter driver???

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

Doron Holan wrote:

Mark, basically you are hosed. The
only thing that you might possibly do to aid development might be to
create a simple KMDF filter for the parent stack and make sure that
NotDisableable is WdfFalse there. This might disableable propagate
downwards

In the DeviceAdd() routine of my filter, I have

WdfDeviceCreate(,&device);
deviceState.NotDisableable = WdfFalse;
WdfDeviceSetDeviceState(device, &deviceState);

For the record, it doesn’t appear to have propagated.

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

Doron Holan wrote:

No, it should be the your filter WDFDEVICE (you do not get a WDFDEVICE
for any other device object in the stack). !wdfkd.wdflogdump > driver name> would tell you if the KMDF API failed before it sent the
> QI, otherwise it could very well be that the underlying bus driver
> isapnp does not support the interface (since it is a pci bus interface,
> not really an isa based one)

“imp_WdfFdoQueryForInterface - WDFDEVICE 0x75A8D490 Device is either
legacy or is not a Fdo 0xc000000d(STATUS_INVALID_PARAMETER)”

Is this telling me it does not support the PCI interface?

Any ideas how to solve my problem? I need to access PCI config space of
the ICH6 chipset… :frowning: Do I need a lower filter driver???

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

This is failing in KMDF before it gets sent. Might be an overaggressive check that does not take a filter into account, I can look tomorrow. You can always build the QI irp yourself and send it, http://blogs.msdn.com/doronh/archive/2006/08/16/703157.aspx. You can also try WdfIoTargetQueryForInterface on the built in WDFIOTARGET (WdfDeviceGetIoTarget) off of the WDFDEVICE

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Tuesday, March 03, 2009 9:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] No option to disable my driver

Doron Holan wrote:

No, it should be the your filter WDFDEVICE (you do not get a WDFDEVICE
for any other device object in the stack). !wdfkd.wdflogdump > driver name> would tell you if the KMDF API failed before it sent the
> QI, otherwise it could very well be that the underlying bus driver
> isapnp does not support the interface (since it is a pci bus interface,
> not really an isa based one)

“imp_WdfFdoQueryForInterface - WDFDEVICE 0x75A8D490 Device is either
legacy or is not a Fdo 0xc000000d(STATUS_INVALID_PARAMETER)”

Is this telling me it does not support the PCI interface?

Any ideas how to solve my problem? I need to access PCI config space of
the ICH6 chipset… :frowning: Do I need a lower filter driver???

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266


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</http:>

Doron Holan wrote:

This is failing in KMDF before it gets sent. Might be an overaggressive
check that does not take a filter into account, I can look tomorrow.
You can always build the QI irp yourself and send it,
http://blogs.msdn.com/doronh/archive/2006/08/16/703157.aspx. You can
also try WdfIoTargetQueryForInterface on the built in WDFIOTARGET
(WdfDeviceGetIoTarget) off of the WDFDEVICE

After a few dozen reboots, I’m still no closer to getting this working.

If I grab device & iotarget in the deviceadd function and store them in
the device extension, then try to use either WdfFdoQueryForInterface() or
WdfIoTargetQueryForInterface() in the ioctl handler, then I get a system
reboot. Using the device returned from WdfCollectionGetItem() doesn’t work
either.

I’m close to giving up on this one.

One last thing to try might be to build a WDM filter and see if I have any
luck with that…

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

You are getting a reboot in the middle of debugging your driver? What is the bugcheck code/output of !analyze -v in this case?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Wednesday, March 04, 2009 8:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] No option to disable my driver

Doron Holan wrote:

This is failing in KMDF before it gets sent. Might be an overaggressive
check that does not take a filter into account, I can look tomorrow.
You can always build the QI irp yourself and send it,
http://blogs.msdn.com/doronh/archive/2006/08/16/703157.aspx. You can
also try WdfIoTargetQueryForInterface on the built in WDFIOTARGET
(WdfDeviceGetIoTarget) off of the WDFDEVICE

After a few dozen reboots, I’m still no closer to getting this working.

If I grab device & iotarget in the deviceadd function and store them in
the device extension, then try to use either WdfFdoQueryForInterface() or
WdfIoTargetQueryForInterface() in the ioctl handler, then I get a system
reboot. Using the device returned from WdfCollectionGetItem() doesn’t work
either.

I’m close to giving up on this one.

One last thing to try might be to build a WDM filter and see if I have any
luck with that…

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266


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</http:>

Doron Holan wrote:

You are getting a reboot in the middle of debugging your driver? What
is the bugcheck code/output of !analyze -v in this case?

OK, this one was my fault, sorry!

I’m using an only-slightly-modified toaster filter, and although I “knew”
it, it didn’t quite click on the right level in my brain that the ioctl
calls were being handled in the context of the control device object, not
the filter device object - in fact, it only hit me when I was building the
WDM version, and saw a warning about the device extension type! And here I
was trying to call QueryInterface…

Anyway, back to WDF and I’ve moved the QueryInterface into the deviceadd
function, where I then store the interface in the device extension. Now
the ioctl handler in the control device grabs the filter handle from the
collection and then the interface from the device extension. I can now
happily read pci config information from the ICH6 - yah! I’m yet to try
reading the actual byte that I need, and likewise write it, but I suspect
there won’t be any further drama.

As an aside, I find writing these drivers particularly challenging because
it’s not my full-time job - I do hardware, firmware and all manner of
software, so I only visit windows drivers occasionally. So these tasks
usually start with many days of google and msdn, reading walt oney,
looking at ddk source and asking questions. A year later, and I’ve
forgotten it all again. :frowning: However, slowly I’m building a library of my
own reference code… and in within the next few months I have a (fake)
HID driver and a touchscreen driver to write… oh joy! :wink:

On the bright side, I’ve learnt some useful stuff in getting this latest
driver going!

Many thanks, as usual, go to Doron!

Regards,


Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>