When there are no open handles to your device, your device moves
directly from the surprise remove state to the removed state and then
another instance is brought up. Only when there is an application with
a handle open does the first instance remain in the surprise removed
state after the 2nd instance has been enumerated.
The application having a file open does not have any affect on your
device falling off the bus during hibernation. The application having a
file open just demonstrates that there is a device problem.
Is there a way to close all open handles in the device driver
before entering hibernation state?
No, the app owns the handles
And how do I recreate those handles after resuming from hibernation?
You don’t. the application does that by registering for pnp
notifications on the opened file handle itself and the device interface
and then closes the handle in response to the message indicating the
device backing the file handle has been surprise removed and opening a
new handle when the device interface shows up again.
Hyperterm is obviously not doing that which is why you can’t get it to
work after hibernate. You can’t enforce this semantic upon hyperterm
from your driver, the application has to play nicely as well.
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 11:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver
If what you say is true, then why is my device working if I close all
virtual COM ports before entering hibernation? If I were to close all
applications (hyperterminal inclusive) that are holding on to the
virtual
COM ports before entering hibernation state, my driver will reenumerate
properly when the system resumes from hibernation. All applications will
work normally under this condition.
My device will only go crazy if some applications are using it (or
holding
on to it) when it loses power? If that is the case, what could be the
solution? Is there a way to close all open handles in the device driver
before entering hibernation state? And how do I recreate those handles
after resuming from hibernation?
“Doron Holan”
icrosoft.com>
To
Sent by: “Windows System Software Devs
bounce-215910-258 Interest List”
xxxxx@lists.osr.com
cc
08/03/2005 02:10
Subject
PM RE: [ntdev] Hibernation problem
with Virtual COM port driver
Please respond to
“Windows System
Software Devs
Interest List”
com>
To reinforce this, a normal USB device does no fall off the bus upon
resuming from hibernate. Your device is either losing its brains when
it loses power (and enumerates as a separate device perhaps) or your
device has a firmware bug that you need to fix.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Tuesday, August 02, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver
I don’t think the problem is in hyperterm. The problem is that your
device is failing to enumerate on return from hibernation. That’s what
you need to figure out.
-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 6:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hibernation problem with Virtual COM port driver
Hi,
I’m just very amazed by capabilities of the driver of the Digi Edgeport
USB-to-serial converter (see URL).
http://www.digi.com/products/usb/edgeport.jsp
If I open a Windows Hyperterminal for one of the virtual COM ports
created
by the Digi Edgeport driver and go into Windows hibernation mode; the
Hyperterminal will continue to function normally (send and receive data)
using the same connection when the system resumes from hibernation mode.
Does anyone know how this capability can be achieved without modifying
Windows Hyperterminal?
Best Regards
Linus
“Peter Wieland”
.microsoft.com>
To
Sent by: “Windows System Software Devs
bounce-215817-258 Interest List”
xxxxx@lists.osr.com
cc
08/03/2005 12:44
Subject
AM RE: [ntdev] Hibernation problem
with Virtual COM port driver
Please respond to
“Windows System
Software Devs
Interest List”
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
—
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@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
—
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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com