Detaching Serial Filter Driver

Hi,

I am writing a serial port monitor for W2K which uses an upper filter driver
for the serial port. The driver is dynamically loaded from within the
monitor application by means of the Service Control Manager and is attached
to and detached from the required serial port by means of special IOCTL
calls sent via the DeviceIoControl() function.

Once the driver has attached I dereference the file object so the port can
be used by other applications (i.e. Hyperterminal) and this works fine, I
can open and close the port from Hyperterminal and see read and write data
in the driver.

The problem is that when I finish monitoring and the monitor application
detaches the driver from the stack the port is no longer available to other
applications and I have to restart the machine.

To attach the driver I use:

IoGetDeviceObjectPointer() to get pointers to fileobject and deviceobject.
IoAttachDeviceToDeviceStack() to attach to the target device.
ObDereferenceObject() to free the file object.

To detach the driver I use:
IoDetachDevice() with the pointer to the target device.

Any help would be gratefully received.

Thanks

Alasdair

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

You must not dettach from a device stack prior to receiving
IRP_MN_REMOVE_DEVICE.
You also must not attach to a device stack after it received
IRP_MN_START_DEVICE.

Attach to the device stack before it is started and detach only when it’s
removed.
Use the special IOCTL to control whether you simply pass down the IRPs or do
your special monitor operations.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detaching Serial Filter Driver

Hi,

I am writing a serial port monitor for W2K which uses an upper filter driver
for the serial port. The driver is dynamically loaded from within the
monitor application by means of the Service Control Manager and is attached
to and detached from the required serial port by means of special IOCTL
calls sent via the DeviceIoControl() function.

Once the driver has attached I dereference the file object so the port can
be used by other applications (i.e. Hyperterminal) and this works fine, I
can open and close the port from Hyperterminal and see read and write data
in the driver.

The problem is that when I finish monitoring and the monitor application
detaches the driver from the stack the port is no longer available to other
applications and I have to restart the machine.

To attach the driver I use:

IoGetDeviceObjectPointer() to get pointers to fileobject and deviceobject.
IoAttachDeviceToDeviceStack() to attach to the target device.
ObDereferenceObject() to free the file object.

To detach the driver I use:
IoDetachDevice() with the pointer to the target device.

Any help would be gratefully received.

Thanks

Alasdair


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

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

Hi Shahar,

Thanks for your reply.

Where do these IRPs come from then?

I am attaching my driver to the top of the stack when the user initiates the
start of a monitoring session from in my monitor application (Like Mark
Russinovich’s “Port Monitor” program and others) and detaching it when the
user ends the monitoring session.

My driver is not loaded when the system starts or when a device is plugged
in to the machine as would normally be the case.

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 11:39
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

You must not dettach from a device stack prior to receiving
IRP_MN_REMOVE_DEVICE.
You also must not attach to a device stack after it received
IRP_MN_START_DEVICE.

Attach to the device stack before it is started and detach only when it’s
removed.
Use the special IOCTL to control whether you simply pass down the IRPs or do
your special monitor operations.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detaching Serial Filter Driver

Hi,

I am writing a serial port monitor for W2K which uses an upper filter driver
for the serial port. The driver is dynamically loaded from within the
monitor application by means of the Service Control Manager and is attached
to and detached from the required serial port by means of special IOCTL
calls sent via the DeviceIoControl() function.

Once the driver has attached I dereference the file object so the port can
be used by other applications (i.e. Hyperterminal) and this works fine, I
can open and close the port from Hyperterminal and see read and write data
in the driver.

The problem is that when I finish monitoring and the monitor application
detaches the driver from the stack the port is no longer available to other
applications and I have to restart the machine.

To attach the driver I use:

IoGetDeviceObjectPointer() to get pointers to fileobject and deviceobject.
IoAttachDeviceToDeviceStack() to attach to the target device.
ObDereferenceObject() to free the file object.

To detach the driver I use:
IoDetachDevice() with the pointer to the target device.

Any help would be gratefully received.

Thanks

Alasdair


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

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

If you’ll register as an upper filter for the serial ports, the PnP Manager
will load your driver itself and will call your AddDevice rutine (where you
should attach to the stack) when the port is started. You should read some
chapters from Walter Oney’s “Programming WDM” before getting to implement
this.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

Hi Shahar,

Thanks for your reply.

Where do these IRPs come from then?

I am attaching my driver to the top of the stack when the user initiates the
start of a monitoring session from in my monitor application (Like Mark
Russinovich’s “Port Monitor” program and others) and detaching it when the
user ends the monitoring session.

My driver is not loaded when the system starts or when a device is plugged
in to the machine as would normally be the case.

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 11:39
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

You must not dettach from a device stack prior to receiving
IRP_MN_REMOVE_DEVICE.
You also must not attach to a device stack after it received
IRP_MN_START_DEVICE.

Attach to the device stack before it is started and detach only when it’s
removed.
Use the special IOCTL to control whether you simply pass down the IRPs or do
your special monitor operations.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detaching Serial Filter Driver

Hi,

I am writing a serial port monitor for W2K which uses an upper filter driver
for the serial port. The driver is dynamically loaded from within the
monitor application by means of the Service Control Manager and is attached
to and detached from the required serial port by means of special IOCTL
calls sent via the DeviceIoControl() function.

Once the driver has attached I dereference the file object so the port can
be used by other applications (i.e. Hyperterminal) and this works fine, I
can open and close the port from Hyperterminal and see read and write data
in the driver.

The problem is that when I finish monitoring and the monitor application
detaches the driver from the stack the port is no longer available to other
applications and I have to restart the machine.

To attach the driver I use:

IoGetDeviceObjectPointer() to get pointers to fileobject and deviceobject.
IoAttachDeviceToDeviceStack() to attach to the target device.
ObDereferenceObject() to free the file object.

To detach the driver I use:
IoDetachDevice() with the pointer to the target device.

Any help would be gratefully received.

Thanks

Alasdair


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

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

Hi Shahar,

So what you are saying is that:

  1. I must not attach my driver in response to my own “start” IOCTL but
    instead cause my “start” IOCTL to register my driver as a PnP device and
    allow the PnP manager to call my AddDevice() function. Currently I am
    calling AddDevice() in my DriverEntry() function.

  2. I must not detach my device in my “stop” IOCTL but instead in my “stop”
    IOCTL I must deregister my driver and then detach it in response to
    IRP_MN_REMOVE_DEVICE which the PnP Manager will send me.

I do have Walter’s book and I have been looking at his PNPMON sample as it
is dynamically loaded which is what I want, but as this example was
primarily intended to show PNP IRPs I thought the register/deregister code
in it was for that purpose and not a mandatory requirement for dynamic
attaching and detaching of a driver.

Normally I think my driver will never see these two IRPs anyway as it is for
in-house engineering use only and we can set our own conditions for it’s
use. It is never going to be installed at system-start time or in resposne
to an installer or when a device is plugged in.

Thanks

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 12:08
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

If you’ll register as an upper filter for the serial ports, the PnP Manager
will load your driver itself and will call your AddDevice rutine (where you
should attach to the stack) when the port is started. You should read some
chapters from Walter Oney’s “Programming WDM” before getting to implement
this.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

Hi Shahar,

Thanks for your reply.

Where do these IRPs come from then?

I am attaching my driver to the top of the stack when the user initiates the
start of a monitoring session from in my monitor application (Like Mark
Russinovich’s “Port Monitor” program and others) and detaching it when the
user ends the monitoring session.

My driver is not loaded when the system starts or when a device is plugged
in to the machine as would normally be the case.

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 11:39
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

You must not dettach from a device stack prior to receiving
IRP_MN_REMOVE_DEVICE.
You also must not attach to a device stack after it received
IRP_MN_START_DEVICE.

Attach to the device stack before it is started and detach only when it’s
removed.
Use the special IOCTL to control whether you simply pass down the IRPs or do
your special monitor operations.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detaching Serial Filter Driver

Hi,

I am writing a serial port monitor for W2K which uses an upper filter driver
for the serial port. The driver is dynamically loaded from within the
monitor application by means of the Service Control Manager and is attached
to and detached from the required serial port by means of special IOCTL
calls sent via the DeviceIoControl() function.

Once the driver has attached I dereference the file object so the port can
be used by other applications (i.e. Hyperterminal) and this works fine, I
can open and close the port from Hyperterminal and see read and write data
in the driver.

The problem is that when I finish monitoring and the monitor application
detaches the driver from the stack the port is no longer available to other
applications and I have to restart the machine.

To attach the driver I use:

IoGetDeviceObjectPointer() to get pointers to fileobject and deviceobject.
IoAttachDeviceToDeviceStack() to attach to the target device.
ObDereferenceObject() to free the file object.

To detach the driver I use:
IoDetachDevice() with the pointer to the target device.

Any help would be gratefully received.

Thanks

Alasdair


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

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

  1. Correct.
  2. Correct.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 1:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

Hi Shahar,

So what you are saying is that:

  1. I must not attach my driver in response to my own “start” IOCTL but
    instead cause my “start” IOCTL to register my driver as a PnP device and
    allow the PnP manager to call my AddDevice() function. Currently I am
    calling AddDevice() in my DriverEntry() function.

  2. I must not detach my device in my “stop” IOCTL but instead in my “stop”
    IOCTL I must deregister my driver and then detach it in response to
    IRP_MN_REMOVE_DEVICE which the PnP Manager will send me.

I do have Walter’s book and I have been looking at his PNPMON sample as it
is dynamically loaded which is what I want, but as this example was
primarily intended to show PNP IRPs I thought the register/deregister code
in it was for that purpose and not a mandatory requirement for dynamic
attaching and detaching of a driver.

Normally I think my driver will never see these two IRPs anyway as it is for
in-house engineering use only and we can set our own conditions for it’s
use. It is never going to be installed at system-start time or in resposne
to an installer or when a device is plugged in.

Thanks

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 12:08
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

If you’ll register as an upper filter for the serial ports, the PnP Manager
will load your driver itself and will call your AddDevice rutine (where you
should attach to the stack) when the port is started. You should read some
chapters from Walter Oney’s “Programming WDM” before getting to implement
this.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

Hi Shahar,

Thanks for your reply.

Where do these IRPs come from then?

I am attaching my driver to the top of the stack when the user initiates the
start of a monitoring session from in my monitor application (Like Mark
Russinovich’s “Port Monitor” program and others) and detaching it when the
user ends the monitoring session.

My driver is not loaded when the system starts or when a device is plugged
in to the machine as would normally be the case.

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 11:39
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

You must not dettach from a device stack prior to receiving
IRP_MN_REMOVE_DEVICE.
You also must not attach to a device stack after it received
IRP_MN_START_DEVICE.

Attach to the device stack before it is started and detach only when it’s
removed.
Use the special IOCTL to control whether you simply pass down the IRPs or do
your special monitor operations.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detaching Serial Filter Driver

Hi,

I am writing a serial port monitor for W2K which uses an upper filter driver
for the serial port. The driver is dynamically loaded from within the
monitor application by means of the Service Control Manager and is attached
to and detached from the required serial port by means of special IOCTL
calls sent via the DeviceIoControl() function.

Once the driver has attached I dereference the file object so the port can
be used by other applications (i.e. Hyperterminal) and this works fine, I
can open and close the port from Hyperterminal and see read and write data
in the driver.

The problem is that when I finish monitoring and the monitor application
detaches the driver from the stack the port is no longer available to other
applications and I have to restart the machine.

To attach the driver I use:

IoGetDeviceObjectPointer() to get pointers to fileobject and deviceobject.
IoAttachDeviceToDeviceStack() to attach to the target device.
ObDereferenceObject() to free the file object.

To detach the driver I use:
IoDetachDevice() with the pointer to the target device.

Any help would be gratefully received.

Thanks

Alasdair


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

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

Hi Shahar,

Thanks for this - I am going to paste in some code from Walt Oney’s PNPMON
sample now and see what happens.

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 14:14
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

  1. Correct.
  2. Correct.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 1:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

Hi Shahar,

So what you are saying is that:

  1. I must not attach my driver in response to my own “start” IOCTL but
    instead cause my “start” IOCTL to register my driver as a PnP device and
    allow the PnP manager to call my AddDevice() function. Currently I am
    calling AddDevice() in my DriverEntry() function.

  2. I must not detach my device in my “stop” IOCTL but instead in my “stop”
    IOCTL I must deregister my driver and then detach it in response to
    IRP_MN_REMOVE_DEVICE which the PnP Manager will send me.

I do have Walter’s book and I have been looking at his PNPMON sample as it
is dynamically loaded which is what I want, but as this example was
primarily intended to show PNP IRPs I thought the register/deregister code
in it was for that purpose and not a mandatory requirement for dynamic
attaching and detaching of a driver.

Normally I think my driver will never see these two IRPs anyway as it is for
in-house engineering use only and we can set our own conditions for it’s
use. It is never going to be installed at system-start time or in resposne
to an installer or when a device is plugged in.

Thanks

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 12:08
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

If you’ll register as an upper filter for the serial ports, the PnP Manager
will load your driver itself and will call your AddDevice rutine (where you
should attach to the stack) when the port is started. You should read some
chapters from Walter Oney’s “Programming WDM” before getting to implement
this.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

Hi Shahar,

Thanks for your reply.

Where do these IRPs come from then?

I am attaching my driver to the top of the stack when the user initiates the
start of a monitoring session from in my monitor application (Like Mark
Russinovich’s “Port Monitor” program and others) and detaching it when the
user ends the monitoring session.

My driver is not loaded when the system starts or when a device is plugged
in to the machine as would normally be the case.

Alasdair

-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: 28 September 2004 11:39
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Detaching Serial Filter Driver

You must not dettach from a device stack prior to receiving
IRP_MN_REMOVE_DEVICE.
You also must not attach to a device stack after it received
IRP_MN_START_DEVICE.

Attach to the device stack before it is started and detach only when it’s
removed.
Use the special IOCTL to control whether you simply pass down the IRPs or do
your special monitor operations.

Shahar


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Tuesday, September 28, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detaching Serial Filter Driver

Hi,

I am writing a serial port monitor for W2K which uses an upper filter driver
for the serial port. The driver is dynamically loaded from within the
monitor application by means of the Service Control Manager and is attached
to and detached from the required serial port by means of special IOCTL
calls sent via the DeviceIoControl() function.

Once the driver has attached I dereference the file object so the port can
be used by other applications (i.e. Hyperterminal) and this works fine, I
can open and close the port from Hyperterminal and see read and write data
in the driver.

The problem is that when I finish monitoring and the monitor application
detaches the driver from the stack the port is no longer available to other
applications and I have to restart the machine.

To attach the driver I use:

IoGetDeviceObjectPointer() to get pointers to fileobject and deviceobject.
IoAttachDeviceToDeviceStack() to attach to the target device.
ObDereferenceObject() to free the file object.

To detach the driver I use:
IoDetachDevice() with the pointer to the target device.

Any help would be gratefully received.

Thanks

Alasdair


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

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:

This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.


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

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

Message>driver is dynamically loaded from within the monitor application by
means of the Service

Control Manager and is attached to and detached from the required serial port
by means of
special IOCTL calls sent via the DeviceIoControl() function.

Not so good an approach. The correct approach is to register the driver as
UpperFilter for Serial class, so it will be always loaded and attached by PnP.

The driver will sit as a stupid passthru, until your app will activate it. No
attach/detach except the ual PnP one.

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