Weird behavior of the PnP Manager

Hi,

I am trying to design a process that can install and uninstall a filter
driver on a specific device without restarting the system.

So far what I came up with is this:

Installing a filter driver without restarting the system:

  1. Disable the device I would like to filter.
  2. Call CreateService() in order to register the driver.
  3. Define the driver as a filter for the device by writing to the
    UpperFilters registry key.
  4. Enable the device.

Uninstalling a filter driver without restarting the system:

  1. Disable the device I’m filtering
  2. Remove the driver from the UpperFilters registry key of the device.
  3. Call DeleteService() in order to un-register the driver.
  4. Enable the device.

This seems to be a rather straight forward implementation, but surprisingly
when testing it I got some unexpected behavior from the PnP manager:

When Installing the driver and right after that uninstalling the driver I
noticed that after the DeleteService() the device I was filtering no longer
appeared in the device manager.

I tried to change the order of operations in the hope to get past this weird
behavior, and defined these steps:

Installing a filter driver without restarting the system:

  1. Call CreateService() in order to register the driver.
  2. Disable the device I would like to filter.
  3. Define the driver as a filter for the device by writing to the
    UpperFilters registry key.
  4. Enable the device.

Uninstalling a filter driver without restarting the system:

  1. Disable the device I’m filtering
  2. Remove the driver from the UpperFilters registry key of the device.
  3. Enable the device.
  4. Call DeleteService() in order to un-register the driver.

Now when installing and uninstalling right after that the device still
appeared in the device manager but when trying to disable it in the device
manager I got a message box that said I must restart the system in order to
disable the device.

In an attempt to understand the source of this behavior I did one more test
and restarted the system between the install and uninstall.

When installing, restarting, and uninstalling everything seemed fine in the
device manager but DeleteService() only marked my driver for deletion and
didn’t really remove it.

Can some one explain the three behaviors?

  1. A disabled device that was previously filtered disappears from the
    device manager when the filter driver is deleted.
  2. An enabled device that was previously filtered cannot be disabled
    after the filter driver is deleted.
  3. A filter driver that unloaded is only marked for deletion and not
    actually deleted even though no one holds a handle to it.

Thank You,

Shahar

It’s all well-known.

Installing and uninstalling a PnP filter requires to stop and restart the devnode stack.

Some stacks (storage stack for SystemRoot and any volume with a pagefile, as also PS/2 stack) are not stoppable at all, and thus a reboot is necessary on filter install/uninstall.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: Shahar Talmi
To: Windows System Software Devs Interest List
Sent: Monday, August 23, 2004 12:59 PM
Subject: [ntdev] Weird behavior of the PnP Manager

Hi,

I am trying to design a process that can install and uninstall a filter driver on a specific device without restarting the system.

So far what I came up with is this:

Installing a filter driver without restarting the system:

1… Disable the device I would like to filter.
2… Call CreateService() in order to register the driver.
3… Define the driver as a filter for the device by writing to the UpperFilters registry key.
4… Enable the device.
Uninstalling a filter driver without restarting the system:

1… Disable the device I’m filtering
2… Remove the driver from the UpperFilters registry key of the device.
3… Call DeleteService() in order to un-register the driver.
4… Enable the device.

This seems to be a rather straight forward implementation, but surprisingly when testing it I got some unexpected behavior from the PnP manager:

When Installing the driver and right after that uninstalling the driver I noticed that after the DeleteService() the device I was filtering no longer appeared in the device manager.

I tried to change the order of operations in the hope to get past this weird behavior, and defined these steps:

Installing a filter driver without restarting the system:

1… Call CreateService() in order to register the driver.
2… Disable the device I would like to filter.
3… Define the driver as a filter for the device by writing to the UpperFilters registry key.
4… Enable the device.
Uninstalling a filter driver without restarting the system:

1… Disable the device I’m filtering
2… Remove the driver from the UpperFilters registry key of the device.
3… Enable the device.
4… Call DeleteService() in order to un-register the driver.

Now when installing and uninstalling right after that the device still appeared in the device manager but when trying to disable it in the device manager I got a message box that said I must restart the system in order to disable the device.

In an attempt to understand the source of this behavior I did one more test and restarted the system between the install and uninstall.

When installing, restarting, and uninstalling everything seemed fine in the device manager but DeleteService() only marked my driver for deletion and didn’t really remove it.

Can some one explain the three behaviors?

1… A disabled device that was previously filtered disappears from the device manager when the filter driver is deleted.
2… An enabled device that was previously filtered cannot be disabled after the filter driver is deleted.
3… A filter driver that unloaded is only marked for deletion and not actually deleted even though no one holds a handle to it.

Thank You,

Shahar


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Isn’t disabling and enabling the devices identical to stopping and
restarting the devnode stack?

I don’t see how what you just said explains the behavior I’ve seen.

The only thing that I can think of that will cause the behavior I’ve seen is
that the PDO is not destroyed during all this process

(The PDO will only be destroyed when the device is physically removed from
the bus or when the bus is stopped).

But if this all happens because the PnP holds some kind of information about
the stack even after the stack is stopped than this seems like a buggy
behavior.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, August 23, 2004 11:12 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Weird behavior of the PnP Manager

It’s all well-known.

Installing and uninstalling a PnP filter requires to stop and restart
the devnode stack.

Some stacks (storage stack for SystemRoot and any volume with a
pagefile, as also PS/2 stack) are not stoppable at all, and thus a reboot is
necessary on filter install/uninstall.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----

From: Shahar Talmi mailto:xxxxx

To: Windows System Software Devs Interest List mailto:xxxxx

Sent: Monday, August 23, 2004 12:59 PM

Subject: [ntdev] Weird behavior of the PnP Manager

Hi,

I am trying to design a process that can install and uninstall a filter
driver on a specific device without restarting the system.

So far what I came up with is this:

Installing a filter driver without restarting the system:

1. Disable the device I would like to filter.

2. Call CreateService() in order to register the driver.

3. Define the driver as a filter for the device by writing to the
UpperFilters registry key.

4. Enable the device.

Uninstalling a filter driver without restarting the system:

1. Disable the device I’m filtering

2. Remove the driver from the UpperFilters registry key of the device.

3. Call DeleteService() in order to un-register the driver.

4. Enable the device.

This seems to be a rather straight forward implementation, but surprisingly
when testing it I got some unexpected behavior from the PnP manager:

When Installing the driver and right after that uninstalling the driver I
noticed that after the DeleteService() the device I was filtering no longer
appeared in the device manager.

I tried to change the order of operations in the hope to get past this weird
behavior, and defined these steps:

Installing a filter driver without restarting the system:

1. Call CreateService() in order to register the driver.

2. Disable the device I would like to filter.

3. Define the driver as a filter for the device by writing to the
UpperFilters registry key.

4. Enable the device.

Uninstalling a filter driver without restarting the system:

1. Disable the device I’m filtering

2. Remove the driver from the UpperFilters registry key of the device.

3. Enable the device.

4. Call DeleteService() in order to un-register the driver.

Now when installing and uninstalling right after that the device still
appeared in the device manager but when trying to disable it in the device
manager I got a message box that said I must restart the system in order to
disable the device.

In an attempt to understand the source of this behavior I did one more test
and restarted the system between the install and uninstall.

When installing, restarting, and uninstalling everything seemed fine in the
device manager but DeleteService() only marked my driver for deletion and
didn’t really remove it.

Can some one explain the three behaviors?

1. A disabled device that was previously filtered disappears from the device
manager when the filter driver is deleted.

2. An enabled device that was previously filtered cannot be disabled after
the filter driver is deleted.

3. A filter driver that unloaded is only marked for deletion and not
actually deleted even though no one holds a handle to it.

Thank You,

Shahar


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>

>Isn’t disabling and enabling the devices identical to stopping and restarting
the devnode stack?

Yes.

The only thing that I can think of that will cause the behavior I’ve seen is
that the PDO is not
destroyed during all this process

This is a correct behaviour. PDO remains alive on devnode disabling, and then
re-used on enable.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

I know that this is correct behavior - This is exactly what I have said.
Still, I do not understand why the device would disappear from the device
manager after I have deleted the filter although the filter is not loaded
anymore.

I’m sorry, I think that you misunderstand what I ask and say because of my
English. I hope I was clearer this time.

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, August 23, 2004 12:49 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Weird behavior of the PnP Manager

Isn’t disabling and enabling the devices identical to stopping and
restarting
the devnode stack?

Yes.

The only thing that I can think of that will cause the behavior I’ve seen
is
that the PDO is not
destroyed during all this process

This is a correct behaviour. PDO remains alive on devnode disabling, and
then
re-used on enable.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

What type of device are you filtering?

It sounds like the stack is not being disabled properly once your filter is installed. I would be suspect of your filter.

You might try skipping the DeleteService() step when uninstalling the filter and use the pnp view of the DeviceTree utility from OSR to see if your filter is still in place in the stack upon re-enable. I suspect it will be. If so, you have a problem in your filter driver.

Are you using DriverVerifier on your filter driver?


Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.

“Shahar Talmi” wrote in message news:xxxxx@ntdev…
Hi,

I am trying to design a process that can install and uninstall a filter driver on a specific device without restarting the system.

So far what I came up with is this:

Installing a filter driver without restarting the system:

1… Disable the device I would like to filter.
2… Call CreateService() in order to register the driver.
3… Define the driver as a filter for the device by writing to the UpperFilters registry key.
4… Enable the device.
Uninstalling a filter driver without restarting the system:

1… Disable the device I’m filtering
2… Remove the driver from the UpperFilters registry key of the device.
3… Call DeleteService() in order to un-register the driver.
4… Enable the device.

This seems to be a rather straight forward implementation, but surprisingly when testing it I got some unexpected behavior from the PnP manager:

When Installing the driver and right after that uninstalling the driver I noticed that after the DeleteService() the device I was filtering no longer appeared in the device manager.

I tried to change the order of operations in the hope to get past this weird behavior, and defined these steps:

Installing a filter driver without restarting the system:

1… Call CreateService() in order to register the driver.
2… Disable the device I would like to filter.
3… Define the driver as a filter for the device by writing to the UpperFilters registry key.
4… Enable the device.
Uninstalling a filter driver without restarting the system:

1… Disable the device I’m filtering
2… Remove the driver from the UpperFilters registry key of the device.
3… Enable the device.
4… Call DeleteService() in order to un-register the driver.

Now when installing and uninstalling right after that the device still appeared in the device manager but when trying to disable it in the device manager I got a message box that said I must restart the system in order to disable the device.

In an attempt to understand the source of this behavior I did one more test and restarted the system between the install and uninstall.

When installing, restarting, and uninstalling everything seemed fine in the device manager but DeleteService() only marked my driver for deletion and didn’t really remove it.

Can some one explain the three behaviors?

1… A disabled device that was previously filtered disappears from the device manager when the filter driver is deleted.
2… An enabled device that was previously filtered cannot be disabled after the filter driver is deleted.
3… A filter driver that unloaded is only marked for deletion and not actually deleted even though no one holds a handle to it.

Thank You,

Shahar