IoGetDeviceObjectPointer on serial driver !!

Hi

The first time I call IoGetDeviceObjectPointer on \Device\Serial0 the
function call do not fail.
Any attempts to open the COM port from user mode app. fails, which is fine.

But when I stop the driver i stil can't open the COM port from a user mode
app. ??
In my DriverUnload function I do call ObDereferenceObject() on the
fileobject returned by IoGetDeviceObjectPointer.

Any further attempts to call IoGetDeviceObjectPointer on \Device\Serial0
fails, (with error code 3221225506) which according to the DDK help files,
can't be returned ?

Isn't IoGetDeviceObjectPointer a combination of ZwCreateFile,
ObReferenceObjectByHandle, IoGetRelatedDeviceObject, ZwClose ??
So why can't I reopen the COM port ??

Thomas

Gary
Thu Aug 19 07:10:47 CDT 2004

Deref the device object that you get back as well.

--
The personal opinion of
Gary G. Little

"Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
news:%23b$mp2chEHA.2544@TK2MSFTNGP10.phx.gbl...
> Hi
>
> The first time I call IoGetDeviceObjectPointer on \Device\Serial0 the
> function call do not fail.
> Any attempts to open the COM port from user mode app. fails, which is
fine.
>
> But when I stop the driver i stil can't open the COM port from a user mode
> app. ??
> In my DriverUnload function I do call ObDereferenceObject() on the
> fileobject returned by IoGetDeviceObjectPointer.
>
> Any further attempts to call IoGetDeviceObjectPointer on \Device\Serial0
> fails, (with error code 3221225506) which according to the DDK help files,
> can't be returned ?
>
> Isn't IoGetDeviceObjectPointer a combination of ZwCreateFile,
> ObReferenceObjectByHandle, IoGetRelatedDeviceObject, ZwClose ??
> So why can't I reopen the COM port ??
>
> Thomas
>
>

Walter
Thu Aug 19 07:53:29 CDT 2004

Thomas Johansen wrote:
> But when I stop the driver i stil can't open the COM port from a user mode
> app. ??
> In my DriverUnload function I do call ObDereferenceObject() on the
> fileobject returned by IoGetDeviceObjectPointer.

Are you sure DriverUnload is being called? Are you sure you've got the
right FileObject pointer? Given that you're handling this operation in
DriverUnload, you must be using a static variable to hold the pointer.
That's not a very good idea, since each instance of your device should
have its own unique value.

> Any further attempts to call IoGetDeviceObjectPointer on \Device\Serial0
> fails, (with error code 3221225506) which according to the DDK help files,
> can't be returned ?

Shame on you for not translating this to hex -- C0000022 --
STATUS_ACCESS_DENIED, which is exactly what you'd expect if SERIAL
thought a handle was still open.

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Alexander
Thu Aug 19 08:34:58 CDT 2004

No, you should NOT dereference the devobj. You only need to dereference the
file object. The file object itself keeps a reference to the devobj.

"Gary G. Little" <gglittle.nospam@sbcglobal.net> wrote in message
news:bN0Vc.8832$uZ5.3705@newssvr22.news.prodigy.com...
> Deref the device object that you get back as well.
>
> --
> The personal opinion of
> Gary G. Little
>
> "Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
> news:%23b$mp2chEHA.2544@TK2MSFTNGP10.phx.gbl...
> > Hi
> >
> > The first time I call IoGetDeviceObjectPointer on \Device\Serial0 the
> > function call do not fail.
> > Any attempts to open the COM port from user mode app. fails, which is
> fine.
> >
> > But when I stop the driver i stil can't open the COM port from a user
mode
> > app. ??
> > In my DriverUnload function I do call ObDereferenceObject() on the
> > fileobject returned by IoGetDeviceObjectPointer.
> >
> > Any further attempts to call IoGetDeviceObjectPointer on
\Device\Serial0
> > fails, (with error code 3221225506) which according to the DDK help
files,
> > can't be returned ?
> >
> > Isn't IoGetDeviceObjectPointer a combination of ZwCreateFile,
> > ObReferenceObjectByHandle, IoGetRelatedDeviceObject, ZwClose ??
> > So why can't I reopen the COM port ??
> >
> > Thomas
> >
> >
>
>

Gary
Thu Aug 19 09:50:21 CDT 2004

Really? Then why is it that I have to use ObDereferenceObject on the
DeviceObject passed back to me from IoGetDeviceObjectPointer, to get that
device to close? Decrementing the reference count on the file object alone
does not do it.

--
The personal opinion of
Gary G. Little.

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%230eaUFfhEHA.1644@tk2msftngp13.phx.gbl...
> No, you should NOT dereference the devobj. You only need to dereference
the
> file object. The file object itself keeps a reference to the devobj.
>
> "Gary G. Little" <gglittle.nospam@sbcglobal.net> wrote in message
> news:bN0Vc.8832$uZ5.3705@newssvr22.news.prodigy.com...
> > Deref the device object that you get back as well.
> >
> > --
> > The personal opinion of
> > Gary G. Little
> >
> > "Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
> > news:%23b$mp2chEHA.2544@TK2MSFTNGP10.phx.gbl...
> > > Hi
> > >
> > > The first time I call IoGetDeviceObjectPointer on \Device\Serial0 the
> > > function call do not fail.
> > > Any attempts to open the COM port from user mode app. fails, which is
> > fine.
> > >
> > > But when I stop the driver i stil can't open the COM port from a user
> mode
> > > app. ??
> > > In my DriverUnload function I do call ObDereferenceObject() on the
> > > fileobject returned by IoGetDeviceObjectPointer.
> > >
> > > Any further attempts to call IoGetDeviceObjectPointer on
> \Device\Serial0
> > > fails, (with error code 3221225506) which according to the DDK help
> files,
> > > can't be returned ?
> > >
> > > Isn't IoGetDeviceObjectPointer a combination of ZwCreateFile,
> > > ObReferenceObjectByHandle, IoGetRelatedDeviceObject, ZwClose ??
> > > So why can't I reopen the COM port ??
> > >
> > > Thomas
> > >
> > >
> >
> >
>
>

Spiro
Thu Aug 19 13:51:15 CDT 2004

Hello,

Gary G. Little <gglittle.nospam@sbcglobal.net> wrote:

> Really? Then why is it that I have to use ObDereferenceObject on the
> DeviceObject passed back to me from IoGetDeviceObjectPointer, to get that
> device to close? Decrementing the reference count on the file object alone
> does not do it.

According to Walter Oney's book and the DDK documentation, you have to
dereference the file object only. Are you sure you do not call
ObReferenceObject() on the device object yourself?

Kind regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Gary
Thu Aug 19 14:28:26 CDT 2004

I was incorrect. I've been testing this for a problem for the past few days
and did not have things set up the way I "thought" I had them when I made
the post. I have indeed been passing the FileObject to ObReferenceObject and
not the DriverObject.

--
The personal opinion of
Gary G. Little

"Spiro Trikaliotis" <news+200406@trikaliotis.net> wrote in message
news:slrnci9tl3.q93.news+200406@news.trikaliotis.net...
> Hello,
>
> Gary G. Little <gglittle.nospam@sbcglobal.net> wrote:
>
> > Really? Then why is it that I have to use ObDereferenceObject on the
> > DeviceObject passed back to me from IoGetDeviceObjectPointer, to get
that
> > device to close? Decrementing the reference count on the file object
alone
> > does not do it.
>
> According to Walter Oney's book and the DDK documentation, you have to
> dereference the file object only. Are you sure you do not call
> ObReferenceObject() on the device object yourself?
>
> Kind regards,
> Spiro.
>
> --
> Spiro R. Trikaliotis
> http://www.trikaliotis.net/

Thomas
Mon Aug 23 01:18:12 CDT 2004

> No, you should NOT dereference the devobj. You only need to dereference
the
> file object. The file object itself keeps a reference to the devobj.
>

Yes. I do that, but still my COM port isn't released and I have to reboot
!!!

This is what I do in my opne COM function:

status = IoGetDeviceObjectPointer(&wstrComPort, FILE_ALL_ACCESS,
&FileObject, &DeviceObject);

KeInitializeEvent(&evt, NotificationEvent, FALSE);
pIrp = IoBuildDeviceIoControlRequest(IOCTL_SERIAL_SET_BAUD_RATE,
AttachedDeviceObject, (PUCHAR)&br, sizeof(br), NULL, 0, FALSE, &evt, &ios);

if (pIrp != NULL)
{
status = IoCallDriver(AttachedDeviceObject, pIrp);
if (status == STATUS_PENDING)
{
KeWaitForSingleObject(&evt, Executive, KernelMode, FALSE, NULL);
status = ios.Status;
}
}

This code seems to work.
In my XXXUnload function i do this:

if(FileObject != NULL)
{
KdPrint(("Closing the COM port.\r\n"));
ObDereferenceObject(FileObject);
}

But after this the COM port isn't released ?

Am I doing something wrong here ?

Thomas

Thomas
Mon Aug 23 07:04:48 CDT 2004

And in my system log I get the following error message:

"The system cannot find the file specified" Error 7000


"Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
news:eOsJ5jNiEHA.1512@TK2MSFTNGP10.phx.gbl...
> > No, you should NOT dereference the devobj. You only need to dereference
> the
> > file object. The file object itself keeps a reference to the devobj.
> >
>
> Yes. I do that, but still my COM port isn't released and I have to reboot
> !!!
>
> This is what I do in my opne COM function:
>
> status = IoGetDeviceObjectPointer(&wstrComPort, FILE_ALL_ACCESS,
> &FileObject, &DeviceObject);
>
> KeInitializeEvent(&evt, NotificationEvent, FALSE);
> pIrp = IoBuildDeviceIoControlRequest(IOCTL_SERIAL_SET_BAUD_RATE,
> AttachedDeviceObject, (PUCHAR)&br, sizeof(br), NULL, 0, FALSE, &evt,
&ios);
>
> if (pIrp != NULL)
> {
> status = IoCallDriver(AttachedDeviceObject, pIrp);
> if (status == STATUS_PENDING)
> {
> KeWaitForSingleObject(&evt, Executive, KernelMode, FALSE, NULL);
> status = ios.Status;
> }
> }
>
> This code seems to work.
> In my XXXUnload function i do this:
>
> if(FileObject != NULL)
> {
> KdPrint(("Closing the COM port.\r\n"));
> ObDereferenceObject(FileObject);
> }
>
> But after this the COM port isn't released ?
>
> Am I doing something wrong here ?
>
> Thomas
>
>

Thomas
Mon Aug 23 07:04:48 CDT 2004

And in my system log I get the following error message:

"The system cannot find the file specified" Error 7000


"Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
news:eOsJ5jNiEHA.1512@TK2MSFTNGP10.phx.gbl...
> > No, you should NOT dereference the devobj. You only need to dereference
> the
> > file object. The file object itself keeps a reference to the devobj.
> >
>
> Yes. I do that, but still my COM port isn't released and I have to reboot
> !!!
>
> This is what I do in my opne COM function:
>
> status = IoGetDeviceObjectPointer(&wstrComPort, FILE_ALL_ACCESS,
> &FileObject, &DeviceObject);
>
> KeInitializeEvent(&evt, NotificationEvent, FALSE);
> pIrp = IoBuildDeviceIoControlRequest(IOCTL_SERIAL_SET_BAUD_RATE,
> AttachedDeviceObject, (PUCHAR)&br, sizeof(br), NULL, 0, FALSE, &evt,
&ios);
>
> if (pIrp != NULL)
> {
> status = IoCallDriver(AttachedDeviceObject, pIrp);
> if (status == STATUS_PENDING)
> {
> KeWaitForSingleObject(&evt, Executive, KernelMode, FALSE, NULL);
> status = ios.Status;
> }
> }
>
> This code seems to work.
> In my XXXUnload function i do this:
>
> if(FileObject != NULL)
> {
> KdPrint(("Closing the COM port.\r\n"));
> ObDereferenceObject(FileObject);
> }
>
> But after this the COM port isn't released ?
>
> Am I doing something wrong here ?
>
> Thomas
>
>

Alexander
Mon Aug 23 09:15:04 CDT 2004

What is AttachedDeviceObject and how it corresponds to DeviceObject?

"Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
news:eOsJ5jNiEHA.1512@TK2MSFTNGP10.phx.gbl...
> > No, you should NOT dereference the devobj. You only need to dereference
> the
> > file object. The file object itself keeps a reference to the devobj.
> >
>
> Yes. I do that, but still my COM port isn't released and I have to reboot
> !!!
>
> This is what I do in my opne COM function:
>
> status = IoGetDeviceObjectPointer(&wstrComPort, FILE_ALL_ACCESS,
> &FileObject, &DeviceObject);
>
> KeInitializeEvent(&evt, NotificationEvent, FALSE);
> pIrp = IoBuildDeviceIoControlRequest(IOCTL_SERIAL_SET_BAUD_RATE,
> AttachedDeviceObject, (PUCHAR)&br, sizeof(br), NULL, 0, FALSE, &evt,
&ios);
>
> if (pIrp != NULL)
> {
> status = IoCallDriver(AttachedDeviceObject, pIrp);
> if (status == STATUS_PENDING)
> {
> KeWaitForSingleObject(&evt, Executive, KernelMode, FALSE, NULL);
> status = ios.Status;
> }
> }
>
> This code seems to work.
> In my XXXUnload function i do this:
>
> if(FileObject != NULL)
> {
> KdPrint(("Closing the COM port.\r\n"));
> ObDereferenceObject(FileObject);
> }
>
> But after this the COM port isn't released ?
>
> Am I doing something wrong here ?
>
> Thomas
>
>

Thomas
Tue Aug 24 09:10:16 CDT 2004

Hey again.

From my COM open function:

PFILE_OBJECT FileObject = NULL;
PDEVICE_OBJECT DeviceObject = NULL;
PDEVICE_OBJECT AttachedDeviceObject = NULL;


// Get device object pointer
status = IoGetDeviceObjectPointer(&wstrComPort, FILE_ALL_ACCESS,
&FileObject, &DeviceObject);

// Check status
if (NT_SUCCESS (status))
{
// Create unknown device
status = IoCreateDevice(DriverObject,
0,
NULL,
FILE_DEVICE_UNKNOWN ,
0,
FALSE,
&pDeviceObject );

if(NT_SUCCESS (status))
{
// Attach the next lower to this stack
AttachedDeviceObject = IoAttachDeviceToDeviceStack(pDeviceObject,
DeviceObject);

if(NULL != AttachedDeviceObject)
{
// initialize the baudrtate structure baudrate
RtlZeroMemory(&baudRate, sizeof(baudRate));
baudRate.BaudRate = nBaudRate;

// Initialize the event
KeInitializeEvent(&evt, NotificationEvent, FALSE);

// Build the IRP
pIrp = IoBuildDeviceIoControlRequest(IOCTL_SERIAL_SET_BAUD_RATE,

AttachedDeviceObject,

(PUCHAR)&baudRate,

sizeof(baudRate),

NULL,
0,

FALSE,

&evt,

&IoStatusBlock);

if (pIrp != NULL)
{
// Set the baud rate
status = IoCallDriver(AttachedDeviceObject, pIrp);

// If pending wait for completion
if (status == STATUS_PENDING)
{
KeWaitForSingleObject(&evt, Executive, KernelMode, FALSE,
NULL);
status = IoStatusBlock.Status;
}
}
else
{
KdPrint(("IoBuildDeviceIoControlRequest failed.
STATUS_INSUFFICIENT_RESOURCES\n"));
status = STATUS_INSUFFICIENT_RESOURCES;
}
}
}

I do this in my Unload function:

//Close the COM port.
IoDetachDevice(DeviceObject);
ObDereferenceObject(FileObject);

Hope this helps... By the way. All serial port operation works fine. Exept
that the port is released for the system again..

Thomas

Alexander
Tue Aug 24 09:15:38 CDT 2004

1. You don't need to attach your device object.
2. You're detaching wrong device object.

"Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
news:uj0NWQeiEHA.4020@TK2MSFTNGP10.phx.gbl...
> Hey again.
>
> From my COM open function:
>
> PFILE_OBJECT FileObject = NULL;
> PDEVICE_OBJECT DeviceObject = NULL;
> PDEVICE_OBJECT AttachedDeviceObject = NULL;
>
>
> // Get device object pointer
> status = IoGetDeviceObjectPointer(&wstrComPort, FILE_ALL_ACCESS,
> &FileObject, &DeviceObject);
>
> // Check status
> if (NT_SUCCESS (status))
> {
> // Create unknown device
> status = IoCreateDevice(DriverObject,
> 0,
> NULL,
> FILE_DEVICE_UNKNOWN ,
> 0,
> FALSE,
> &pDeviceObject );
>
> if(NT_SUCCESS (status))
> {
> // Attach the next lower to this stack
> AttachedDeviceObject =
IoAttachDeviceToDeviceStack(pDeviceObject,
> DeviceObject);
>
> if(NULL != AttachedDeviceObject)
> {
> // initialize the baudrtate structure baudrate
> RtlZeroMemory(&baudRate, sizeof(baudRate));
> baudRate.BaudRate = nBaudRate;
>
> // Initialize the event
> KeInitializeEvent(&evt, NotificationEvent, FALSE);
>
> // Build the IRP
> pIrp =
IoBuildDeviceIoControlRequest(IOCTL_SERIAL_SET_BAUD_RATE,
>
> AttachedDeviceObject,
>
> (PUCHAR)&baudRate,
>
> sizeof(baudRate),
>
> NULL,
> 0,
>
> FALSE,
>
> &evt,
>
> &IoStatusBlock);
>
> if (pIrp != NULL)
> {
> // Set the baud rate
> status = IoCallDriver(AttachedDeviceObject, pIrp);
>
> // If pending wait for completion
> if (status == STATUS_PENDING)
> {
> KeWaitForSingleObject(&evt, Executive, KernelMode,
FALSE,
> NULL);
> status = IoStatusBlock.Status;
> }
> }
> else
> {
> KdPrint(("IoBuildDeviceIoControlRequest failed.
> STATUS_INSUFFICIENT_RESOURCES\n"));
> status = STATUS_INSUFFICIENT_RESOURCES;
> }
> }
> }
>
> I do this in my Unload function:
>
> //Close the COM port.
> IoDetachDevice(DeviceObject);
> ObDereferenceObject(FileObject);
>
> Hope this helps... By the way. All serial port operation works fine. Exept
> that the port is released for the system again..
>
> Thomas
>
>

Thomas
Wed Aug 25 03:25:41 CDT 2004

Hi Alexander

>1. You don't need to attach your device object.

You where completly right !!! Thanks

> 2. You're detaching wrong device object.

Schould I use IoDetachDevice(..) on the Device object from
IoGetDeviceObjectPointer call ?
I have tried. Doesn't work

In the DDK help the IoDetachDevice schould be used on devices returned from
IoAttachDevice or IoAttachDeviceToDeviceStack ?
As in number 1, I don't need to attach the device ??

So I still can't find out, how to close the COM port !!!! :-)


Thomas

Thomas
Wed Aug 25 03:37:47 CDT 2004

Hi again

I got my self a big cup of coffee and firgured it out myself..

Thanks for the time and help

Thomas

Gary
Wed Aug 25 07:26:34 CDT 2004

Long time ago this came up and I boloxed up the answer. Are you doing an
ObDereferenceObject on the file object pointer you get back from the call to
IoGetDeviceObjectPointer?

--
The personal opinion of
Gary G. Little

"Thomas Johansen" <thrawn[NO SPAM]@hest.com___KÆP> wrote in message
news:%23m7rd0niEHA.140@TK2MSFTNGP12.phx.gbl...
> Hi Alexander
>
> >1. You don't need to attach your device object.
>
> You where completly right !!! Thanks
>
> > 2. You're detaching wrong device object.
>
> Schould I use IoDetachDevice(..) on the Device object from
> IoGetDeviceObjectPointer call ?
> I have tried. Doesn't work
>
> In the DDK help the IoDetachDevice schould be used on devices returned
from
> IoAttachDevice or IoAttachDeviceToDeviceStack ?
> As in number 1, I don't need to attach the device ??
>
> So I still can't find out, how to close the COM port !!!! :-)
>
>
> Thomas
>
>