Hibernation problem with Virtual COM port driver

Hi All,

I have developed a WDM USB to serial (virtual COM port) driver. It it
working fine during power on/off, reboot, suspend and resume. The problem
arises when the system goes into the S4 (hibernation) state when an
application such as Windows hyperterminal is holding on to a virtual COM
port. When the system resumes from hibernation, the driver is unable to
load properly during the renumeration process (a yellow exclaimation mark
is seen in the device manager window). Can someone please advise me what I
can do to solve the problem. What are the IRPs that are responsible for
entering and resuming from hibernation state? How should I handle them?

Thanks and Best Regards
Linus


The information contained in this email and any attachments (the “message”)
is intended solely for the persons or the entity to whom it is addressed
and is confidential. If you receive this message by mistake please promptly
inform the sender by reply email and then delete the message and destroy
any printed copy. You must not disclose or use in any way the information
in the message. There is no warranty that this message is error or virus
free and has not been tempered with. It may be a private communication, and
if so, does not represent the view of the company. All the contents of this
message are subject to copyright.


The information contained in this email and any attachments (the “message”)
is intended solely for the persons or the entity to whom it is addressed
and is confidential. If you receive this message by mistake please promptly
inform the sender by reply email and then delete the message and destroy
any printed copy. You must not disclose or use in any way the information
in the message. There is no warranty that this message is error or virus
free and has not been tempered with. It may be a private communication, and
if so, does not represent the view of the company. All the contents of this
message are subject to copyright.

Can we get rid of that DUMB stuff at the end. Sure don’t need it and it
obligates no one to not disclose in any way they choose, except for others
in your company.

“Linus Fones Kwok Huan” wrote in message
news:xxxxx@ntdev…
> Hi All,
>
> I have developed a WDM USB to serial (virtual COM port) driver. It it
> working fine during power on/off, reboot, suspend and resume. The problem
> arises when the system goes into the S4 (hibernation) state when an
> application such as Windows hyperterminal is holding on to a virtual COM
> port. When the system resumes from hibernation, the driver is unable to
> load properly during the renumeration process (a yellow exclaimation mark
> is seen in the device manager window). Can someone please advise me what I
> can do to solve the problem. What are the IRPs that are responsible for
> entering and resuming from hibernation state? How should I handle them?
>
> Thanks and Best Regards
> Linus
>
> ------------------------------------------------------------------------------------------------------------------
>
> The information contained in this email and any attachments (the
> “message”)
> is intended solely for the persons or the entity to whom it is addressed
> and is confidential. If you receive this message by mistake please
> promptly
> inform the sender by reply email and then delete the message and destroy
> any printed copy. You must not disclose or use in any way the information
> in the message. There is no warranty that this message is error or virus
> free and has not been tempered with. It may be a private communication,
> and
> if so, does not represent the view of the company. All the contents of
> this
> message are subject to copyright.
>
>
>
> ------------------------------------------------------------------------------------------------------------------
>
> The information contained in this email and any attachments (the
> “message”)
> is intended solely for the persons or the entity to whom it is addressed
> and is confidential. If you receive this message by mistake please
> promptly
> inform the sender by reply email and then delete the message and destroy
> any printed copy. You must not disclose or use in any way the information
> in the message. There is no warranty that this message is error or virus
> free and has not been tempered with. It may be a private communication,
> and
> if so, does not represent the view of the company. All the contents of
> this
> message are subject to copyright.
>
>

Hi All,

This is a repost of a previous message. I have got rid of the copyright
messages that is annoying some of you.
I have developed a WDM USB to serial (virtual COM port) driver. It it
working fine during power on/off, reboot, suspend and resume. The problem
arises when the system goes into the S4 (hibernation) state when an
application such as Windows hyperterminal is holding on to a virtual COM
port. When the system resumes from hibernation, the driver is unable to
load properly during the renumeration process (a yellow exclaimation mark
is seen in the device manager window). Can someone please advise me what I
can do to solve the problem. What are the IRPs that are responsible for
entering and resuming from hibernation state? How should I handle them?

Thanks and Best Regards
Linus

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate? If so, is it trying to create the same
symbolic link name for your new device object?

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
Huan
Sent: Monday, August 01, 2005 11:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with Virtual COM port driver

Hi All,

This is a repost of a previous message. I have got rid of the copyright
messages that is annoying some of you.
I have developed a WDM USB to serial (virtual COM port) driver. It it
working fine during power on/off, reboot, suspend and resume. The
problem
arises when the system goes into the S4 (hibernation) state when an
application such as Windows hyperterminal is holding on to a virtual COM
port. When the system resumes from hibernation, the driver is unable to
load properly during the renumeration process (a yellow exclaimation
mark
is seen in the device manager window). Can someone please advise me what
I
can do to solve the problem. What are the IRPs that are responsible for
entering and resuming from hibernation state? How should I handle them?

Thanks and Best Regards
Linus


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

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

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate?
Yes

If so, is it trying to create the same
symbolic link name for your new device object?
Yes

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.
Yes, I have deleted the symbolic link name in my surprise remove code.
My driver is able to reenumerate (when resuming from hibernation) without
any problem if there are no File Handles open (e.g. Hyperterminal holding
on to a virtual COM port). The problem only arises when a File Handle to
one of the virtual COM ports remains open during hibernation. The driver
will fail to load and the application will not be able resume normal
operation after resuming from hibernation.

“Doron Holan”
icrosoft.com> To
Sent by: “Windows System Software Devs
bounce-215751-258 Interest List”
xxxxx@lists.osr.com
cc

08/02/2005 03:27 Subject
PM RE: [ntdev] Hibernation problem
with Virtual COM port driver

Please respond to
“Windows System
Software Devs
Interest List”
com>

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate? If so, is it trying to create the same
symbolic link name for your new device object?

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
Huan
Sent: Monday, August 01, 2005 11:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with Virtual COM port driver

Hi All,

This is a repost of a previous message. I have got rid of the copyright
messages that is annoying some of you.
I have developed a WDM USB to serial (virtual COM port) driver. It it
working fine during power on/off, reboot, suspend and resume. The
problem
arises when the system goes into the S4 (hibernation) state when an
application such as Windows hyperterminal is holding on to a virtual COM
port. When the system resumes from hibernation, the driver is unable to
load properly during the renumeration process (a yellow exclaimation
mark
is seen in the device manager window). Can someone please advise me what
I
can do to solve the problem. What are the IRPs that are responsible for
entering and resuming from hibernation state? How should I handle them?

Thanks and Best Regards
Linus

I have my doubts about it being a driver load problem b/c the app still
has a handle open to your device. When your device is surprise removed
from the system with an open handle, the device stays in the surprise
remove state until the application closes the handle. If your device is
reinserted, there will be 2 instances of the device in the system, the
2nd instance will not cause your driver to be reloaded b/c it is still
resident in the system.

I would do this:

  1. hook up a debugger (preferably windbg :wink: )
  2. set a breakpoint on your AddDevice routine
  3. set a breakpoint on the code/routine that handles
    IRP_MN_START_DEVICE

Repro the problem, stepping through these routines to see what is
failing.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
Huan
Sent: Tuesday, August 02, 2005 3:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate?
Yes

If so, is it trying to create the same
symbolic link name for your new device object?
Yes

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.
Yes, I have deleted the symbolic link name in my surprise remove code.
My driver is able to reenumerate (when resuming from hibernation)
without
any problem if there are no File Handles open (e.g. Hyperterminal
holding
on to a virtual COM port). The problem only arises when a File Handle to
one of the virtual COM ports remains open during hibernation. The driver
will fail to load and the application will not be able resume normal
operation after resuming from hibernation.

“Doron Holan”


icrosoft.com>
To
Sent by: “Windows System Software Devs

bounce-215751-258 Interest List”

xxxxx@lists.osr.com

cc

08/02/2005 03:27
Subject
PM RE: [ntdev] Hibernation problem

with Virtual COM port driver

Please respond to

“Windows System

Software Devs

Interest List”


com>

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate? If so, is it trying to create the same
symbolic link name for your new device object?

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
Huan
Sent: Monday, August 01, 2005 11:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with Virtual COM port driver

Hi All,

This is a repost of a previous message. I have got rid of the copyright
messages that is annoying some of you.
I have developed a WDM USB to serial (virtual COM port) driver. It it
working fine during power on/off, reboot, suspend and resume. The
problem
arises when the system goes into the S4 (hibernation) state when an
application such as Windows hyperterminal is holding on to a virtual COM
port. When the system resumes from hibernation, the driver is unable to
load properly during the renumeration process (a yellow exclaimation
mark
is seen in the device manager window). Can someone please advise me what
I
can do to solve the problem. What are the IRPs that are responsible for
entering and resuming from hibernation state? How should I handle them?

Thanks and Best Regards
Linus


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

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

I’m assuming that by “normal operation” you want the application to be
able to continue using the handle it has open to the device. This isn’t
possible if your device gets surprise removed during
resume-from-hibernation.

The application has an open handle to device object “A”. When your
device disappears, device object “A” is surprise-removed and that handle
is no longer useful.

When your device is re-enumerated it will get a new device-object: “B”.
In order to continue to use your device, the application needs to close
its handle to “A” and open a handle to “B”.

It doesn’t matter that the device is the same. It doesn’t matter if you
make symlinks to “B” that look exactly like the symlinks to “A”. Once
CreateFile is complete, the handle is bound to a particular object and
not a particular name or a physical device, and you can’t change that
without opening and closing it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
Huan
Sent: Tuesday, August 02, 2005 3:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate?
Yes

If so, is it trying to create the same
symbolic link name for your new device object?
Yes

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.
Yes, I have deleted the symbolic link name in my surprise remove code.
My driver is able to reenumerate (when resuming from hibernation)
without
any problem if there are no File Handles open (e.g. Hyperterminal
holding
on to a virtual COM port). The problem only arises when a File Handle to
one of the virtual COM ports remains open during hibernation. The driver
will fail to load and the application will not be able resume normal
operation after resuming from hibernation.

“Doron Holan”


icrosoft.com>
To
Sent by: “Windows System Software Devs

bounce-215751-258 Interest List”

xxxxx@lists.osr.com

cc

08/02/2005 03:27
Subject
PM RE: [ntdev] Hibernation problem

with Virtual COM port driver

Please respond to

“Windows System

Software Devs

Interest List”


com>

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate? If so, is it trying to create the same
symbolic link name for your new device object?

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
Huan
Sent: Monday, August 01, 2005 11:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with Virtual COM port driver

Hi All,

This is a repost of a previous message. I have got rid of the copyright
messages that is annoying some of you.
I have developed a WDM USB to serial (virtual COM port) driver. It it
working fine during power on/off, reboot, suspend and resume. The
problem
arises when the system goes into the S4 (hibernation) state when an
application such as Windows hyperterminal is holding on to a virtual COM
port. When the system resumes from hibernation, the driver is unable to
load properly during the renumeration process (a yellow exclaimation
mark
is seen in the device manager window). Can someone please advise me what
I
can do to solve the problem. What are the IRPs that are responsible for
entering and resuming from hibernation state? How should I handle them?

Thanks and Best Regards
Linus


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

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

Exactly. Application can process some windows messages to be informed about necessity to reopen handle but I’m affraid it isn’t possible without a window. Next possibility is to get this info from the driver. I have a custom IOCTL for this purpose which sends event handles to the driver which in turn sets them according to some power events (suspend, resume). It is only possible with own app; I’m affraid with Hyperterminal it is necessary to reopen port manually.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, August 02, 2005 6:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver

I’m assuming that by “normal operation” you want the application to be
able to continue using the handle it has open to the device. This isn’t
possible if your device gets surprise removed during
resume-from-hibernation.

The application has an open handle to device object “A”. When your
device disappears, device object “A” is surprise-removed and that handle
is no longer useful.

When your device is re-enumerated it will get a new device-object: “B”.
In order to continue to use your device, the application needs to close
its handle to “A” and open a handle to “B”.

It doesn’t matter that the device is the same. It doesn’t matter if you
make symlinks to “B” that look exactly like the symlinks to “A”. Once
CreateFile is complete, the handle is bound to a particular object and
not a particular name or a physical device, and you can’t change that
without opening and closing it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
Huan
Sent: Tuesday, August 02, 2005 3:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver

Does your USB device fall off the bus and require reenumeration when
resuming from hibernate?
Yes

If so, is it trying to create the same
symbolic link name for your new device object?
Yes

My guess is that your device fell off the bus, you got a surprise remove
on the first instance and then a 2nd instance was enumerated. In your
surprise remove code, do you delete the symbolic link name you created
during AddDevice? If not, then I would guess that when you try to
create the symbolic link name for the 2nd instance of the same device,
it fails and you returning that error from AddDevice or
IRP_MN_START_DEVICE processing.
Yes, I have deleted the symbolic link name in my surprise remove code.
My driver is able to reenumerate (when resuming from hibernation)
without
any problem if there are no File Handles open (e.g. Hyperterminal
holding
on to a virtual COM port). The problem only arises when a File Handle to
one of the virtual COM ports remains open during hibernation. The driver
will fail to load and the application will not be able resume normal
operation after resuming from hibernation.

“Doron Holan”

>
> icrosoft.com>
> To
> Sent by: “Windows System Software Devs
>
> bounce-215751-258 Interest List”
>
> xxxxx@lists.osr.com
>
>
> cc
>
>
> 08/02/2005 03:27
> Subject
> PM RE: [ntdev] Hibernation problem
>
> with Virtual COM port driver
>
>
>
> Please respond to>
>
> “Windows System
>
> Software Devs
>
> Interest List”
>
> >
> com>
>
>
>
>
>
>
>
>
>
> Does your USB device fall off the bus and require reenumeration when
> resuming from hibernate? If so, is it trying to create the same
> symbolic link name for your new device object?
>
> My guess is that your device fell off the bus, you got a surprise remove
> on the first instance and then a 2nd instance was enumerated. In your
> surprise remove code, do you delete the symbolic link name you created
> during AddDevice? If not, then I would guess that when you try to
> create the symbolic link name for the 2nd instance of the same device,
> it fails and you returning that error from AddDevice or
> IRP_MN_START_DEVICE processing.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
> Huan
> Sent: Monday, August 01, 2005 11:47 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Hibernation problem with Virtual COM port driver
>
> Hi All,
>
> This is a repost of a previous message. I have got rid of the copyright
> messages that is annoying some of you.
> I have developed a WDM USB to serial (virtual COM port) driver. It it
> working fine during power on/off, reboot, suspend and resume. The
> problem
> arises when the system goes into the S4 (hibernation) state when an
> application such as Windows hyperterminal is holding on to a virtual COM
> port. When the system resumes from hibernation, the driver is unable to
> load properly during the renumeration process (a yellow exclaimation
> mark
> is seen in the device manager window). Can someone please advise me what
> I
> can do to solve the problem. What are the IRPs that are responsible for
> entering and resuming from hibernation state? How should I handle them?
>
> Thanks and Best Regards
> Linus
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> 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
>

Open file handle blocks the REMOVE path and it is not executed, so the old
devnode is still in place.

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

----- Original Message -----
From: “Linus Fones Kwok Huan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, August 02, 2005 2:11 PM
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver

> Does your USB device fall off the bus and require reenumeration when
> resuming from hibernate?
> Yes
>
> If so, is it trying to create the same
> symbolic link name for your new device object?
> Yes
>
> My guess is that your device fell off the bus, you got a surprise remove
> on the first instance and then a 2nd instance was enumerated. In your
> surprise remove code, do you delete the symbolic link name you created
> during AddDevice? If not, then I would guess that when you try to
> create the symbolic link name for the 2nd instance of the same device,
> it fails and you returning that error from AddDevice or
> IRP_MN_START_DEVICE processing.
> Yes, I have deleted the symbolic link name in my surprise remove code.
> My driver is able to reenumerate (when resuming from hibernation) without
> any problem if there are no File Handles open (e.g. Hyperterminal holding
> on to a virtual COM port). The problem only arises when a File Handle to
> one of the virtual COM ports remains open during hibernation. The driver
> will fail to load and the application will not be able resume normal
> operation after resuming from hibernation.
>
>
>
>
>
> “Doron Holan”
> > icrosoft.com> To
> Sent by: “Windows System Software Devs
> bounce-215751-258 Interest List”
> xxxxx@lists.osr.com
> cc
>
> 08/02/2005 03:27 Subject
> PM RE: [ntdev] Hibernation problem
> with Virtual COM port driver
>
> Please respond to
> “Windows System
> Software Devs
> Interest List”
> > com>
>
>
>
>
>
>
> Does your USB device fall off the bus and require reenumeration when
> resuming from hibernate? If so, is it trying to create the same
> symbolic link name for your new device object?
>
> My guess is that your device fell off the bus, you got a surprise remove
> on the first instance and then a 2nd instance was enumerated. In your
> surprise remove code, do you delete the symbolic link name you created
> during AddDevice? If not, then I would guess that when you try to
> create the symbolic link name for the 2nd instance of the same device,
> it fails and you returning that error from AddDevice or
> IRP_MN_START_DEVICE processing.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Linus Fones Kwok
> Huan
> Sent: Monday, August 01, 2005 11:47 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Hibernation problem with Virtual COM port driver
>
> Hi All,
>
> This is a repost of a previous message. I have got rid of the copyright
> messages that is annoying some of you.
> I have developed a WDM USB to serial (virtual COM port) driver. It it
> working fine during power on/off, reboot, suspend and resume. The
> problem
> arises when the system goes into the S4 (hibernation) state when an
> application such as Windows hyperterminal is holding on to a virtual COM
> port. When the system resumes from hibernation, the driver is unable to
> load properly during the renumeration process (a yellow exclaimation
> mark
> is seen in the device manager window). Can someone please advise me what
> I
> can do to solve the problem. What are the IRPs that are responsible for
> entering and resuming from hibernation state? How should I handle them?
>
> Thanks and Best Regards
> Linus
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

>Exactly. Application can process some windows messages to be informed

about necessity to reopen handle but I’m affraid it isn’t possible without a
window.

Hidden window is enough.

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