Hibernation problem with a Virtual HID Minidriver

All,

I am working on a Win7 KMDF HID Minidriver that controls a serial port
device. The serial port is actually an FTDI emulation port. The mini driver
is a root-enumerated virtual device. It accesses the serial port by creating
a remote IO target. The device has been designed to require an “enable”
command to make the device talk. This presents a problem coming out of
hibernation. The mini driver detects when the system comes out of
hibernation and then re-issue the enable command. The problem we’re having
however is that when the driver re-issues the enable command, the remote IO
target returns a status of STATUS_DELETE_PENDING.

Below are the details:

At startup:

  1. At AddDevice time we register for Pnp Device Notification
    (IoRegisterPlugPlayNotifcation) whose callback is invoked when the com port
    is detected by the OS.
  2. From within the callback, we create a remote IO target using the symbolic
    link name and then issue the device enable command.

At Hibernation:
As the system shuts down it calls our EvtDeviceDOExit routine. This routine
closes the remote IO target. During the close, I see all of the pending IO
requests get canceled.

As the system comes out of hibernation:

  1. The system calls our EvtDeviceDOEntry routine. This routine detected that
    we are returning from hibernations and then does the following:
  2. Re-opens the Remote IO target (using the
    WDF_IO_TARGET_OPEN_PARMS_INIT_REOPEN).
  3. Issue the request to enable the device. The call returns with
    STATUS_DELETE_PENDING. The driver issues this request with
    WDF_REQUEST_SEND_OPTION_IGNORE_TARGET_STATE.

It looks as if the io target never got closed but I dump the state of the io
target (!wdfdk.wdfiotarget) I see that the device is in the started state
and there are no pending IO requests.

Any ideas?

TIA!

Turnon kmdf verbose logging and see what !wdfkd.wdflogdump (your driver name) says. What if you create and open a new target on resume?

d

-----Original Message-----
From: JimmyJ
Sent: Thursday, December 10, 2009 7:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with a Virtual HID Minidriver

All,

I am working on a Win7 KMDF HID Minidriver that controls a serial port
device. The serial port is actually an FTDI emulation port. The mini driver
is a root-enumerated virtual device. It accesses the serial port by creating
a remote IO target. The device has been designed to require an “enable”
command to make the device talk. This presents a problem coming out of
hibernation. The mini driver detects when the system comes out of
hibernation and then re-issue the enable command. The problem we’re having
however is that when the driver re-issues the enable command, the remote IO
target returns a status of STATUS_DELETE_PENDING.

Below are the details:

At startup:
1. At AddDevice time we register for Pnp Device Notification
(IoRegisterPlugPlayNotifcation) whose callback is invoked when the com port
is detected by the OS.
2. From within the callback, we create a remote IO target using the symbolic
link name and then issue the device enable command.

At Hibernation:
As the system shuts down it calls our EvtDeviceDOExit routine. This routine
closes the remote IO target. During the close, I see all of the pending IO
requests get canceled.

As the system comes out of hibernation:
1. The system calls our EvtDeviceDOEntry routine. This routine detected that
we are returning from hibernations and then does the following:
2. Re-opens the Remote IO target (using the
WDF_IO_TARGET_OPEN_PARMS_INIT_REOPEN).
3. Issue the request to enable the device. The call returns with
STATUS_DELETE_PENDING. The driver issues this request with
WDF_REQUEST_SEND_OPTION_IGNORE_TARGET_STATE.

It looks as if the io target never got closed but I dump the state of the io
target (!wdfdk.wdfiotarget) I see that the device is in the started state
and there are no pending IO requests.

Any ideas?

TIA!


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi Doron,

I tried creating/opening a new io target on resume and had the same probem.

I’ll give !wdfkd.wdflogdump a try and get back to you.

Thanks,
Dale

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Turnon kmdf verbose logging and see what !wdfkd.wdflogdump (your driver
name) says. What if you create and open a new target on resume?

d

-----Original Message-----
From: JimmyJ
Sent: Thursday, December 10, 2009 7:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with a Virtual HID Minidriver

All,

I am working on a Win7 KMDF HID Minidriver that controls a serial port
device. The serial port is actually an FTDI emulation port. The mini driver
is a root-enumerated virtual device. It accesses the serial port by creating
a remote IO target. The device has been designed to require an “enable”
command to make the device talk. This presents a problem coming out of
hibernation. The mini driver detects when the system comes out of
hibernation and then re-issue the enable command. The problem we’re having
however is that when the driver re-issues the enable command, the remote IO
target returns a status of STATUS_DELETE_PENDING.

Below are the details:

At startup:
1. At AddDevice time we register for Pnp Device Notification
(IoRegisterPlugPlayNotifcation) whose callback is invoked when the com port
is detected by the OS.
2. From within the callback, we create a remote IO target using the symbolic
link name and then issue the device enable command.

At Hibernation:
As the system shuts down it calls our EvtDeviceDOExit routine. This routine
closes the remote IO target. During the close, I see all of the pending IO
requests get canceled.

As the system comes out of hibernation:
1. The system calls our EvtDeviceDOEntry routine. This routine detected that
we are returning from hibernations and then does the following:
2. Re-opens the Remote IO target (using the
WDF_IO_TARGET_OPEN_PARMS_INIT_REOPEN).
3. Issue the request to enable the device. The call returns with
STATUS_DELETE_PENDING. The driver issues this request with
WDF_REQUEST_SEND_OPTION_IGNORE_TARGET_STATE.

It looks as if the io target never got closed but I dump the state of the io
target (!wdfdk.wdfiotarget) I see that the device is in the started state
and there are no pending IO requests.

Any ideas?

TIA!


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Well if you are opening a new io target, I doubt that this is a problem with the iotarget b/c we have removed the variable of closing and reopening the same target. Perhaps the ftdi driver is not ready to be communicated with

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of JimmyJ
Sent: Thursday, December 10, 2009 7:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hibernation problem with a Virtual HID Minidriver

Hi Doron,

I tried creating/opening a new io target on resume and had the same probem.

I’ll give !wdfkd.wdflogdump a try and get back to you.

Thanks,
Dale

“Doron Holan” wrote in message news:xxxxx@ntdev…
Turnon kmdf verbose logging and see what !wdfkd.wdflogdump (your driver
name) says. What if you create and open a new target on resume?

d

-----Original Message-----
From: JimmyJ
Sent: Thursday, December 10, 2009 7:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with a Virtual HID Minidriver

All,

I am working on a Win7 KMDF HID Minidriver that controls a serial port
device. The serial port is actually an FTDI emulation port. The mini driver
is a root-enumerated virtual device. It accesses the serial port by creating
a remote IO target. The device has been designed to require an “enable”
command to make the device talk. This presents a problem coming out of
hibernation. The mini driver detects when the system comes out of
hibernation and then re-issue the enable command. The problem we’re having
however is that when the driver re-issues the enable command, the remote IO
target returns a status of STATUS_DELETE_PENDING.

Below are the details:

At startup:
1. At AddDevice time we register for Pnp Device Notification
(IoRegisterPlugPlayNotifcation) whose callback is invoked when the com port
is detected by the OS.
2. From within the callback, we create a remote IO target using the symbolic
link name and then issue the device enable command.

At Hibernation:
As the system shuts down it calls our EvtDeviceDOExit routine. This routine
closes the remote IO target. During the close, I see all of the pending IO
requests get canceled.

As the system comes out of hibernation:
1. The system calls our EvtDeviceDOEntry routine. This routine detected that
we are returning from hibernations and then does the following:
2. Re-opens the Remote IO target (using the
WDF_IO_TARGET_OPEN_PARMS_INIT_REOPEN).
3. Issue the request to enable the device. The call returns with
STATUS_DELETE_PENDING. The driver issues this request with
WDF_REQUEST_SEND_OPTION_IGNORE_TARGET_STATE.

It looks as if the io target never got closed but I dump the state of the io
target (!wdfdk.wdfiotarget) I see that the device is in the started state
and there are no pending IO requests.

Any ideas?

TIA!


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

I wonder what variable you are talking about? I’m building with the
6001.18001 tools. Could this be a change in the new in the Win7 tools?

Yes it could be the FTDI driver.

Another weird things about this:
After sending/failing the device enable request, I can no longer remove the
mini-driver via the Device Manager – EvtReleaseHardware never gets called.
It looks like someone has a reference open somewhere but I don’t see any
when looking at the io target.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Well if you are opening a new io target, I doubt that this is a problem with
the iotarget b/c we have removed the variable of closing and reopening the
same target. Perhaps the ftdi driver is not ready to be communicated with

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of JimmyJ
Sent: Thursday, December 10, 2009 7:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hibernation problem with a Virtual HID Minidriver

Hi Doron,

I tried creating/opening a new io target on resume and had the same probem.

I’ll give !wdfkd.wdflogdump a try and get back to you.

Thanks,
Dale

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Turnon kmdf verbose logging and see what !wdfkd.wdflogdump (your driver
name) says. What if you create and open a new target on resume?

d

-----Original Message-----
From: JimmyJ
Sent: Thursday, December 10, 2009 7:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with a Virtual HID Minidriver

All,

I am working on a Win7 KMDF HID Minidriver that controls a serial port
device. The serial port is actually an FTDI emulation port. The mini driver
is a root-enumerated virtual device. It accesses the serial port by creating
a remote IO target. The device has been designed to require an “enable”
command to make the device talk. This presents a problem coming out of
hibernation. The mini driver detects when the system comes out of
hibernation and then re-issue the enable command. The problem we’re having
however is that when the driver re-issues the enable command, the remote IO
target returns a status of STATUS_DELETE_PENDING.

Below are the details:

At startup:
1. At AddDevice time we register for Pnp Device Notification
(IoRegisterPlugPlayNotifcation) whose callback is invoked when the com port
is detected by the OS.
2. From within the callback, we create a remote IO target using the symbolic
link name and then issue the device enable command.

At Hibernation:
As the system shuts down it calls our EvtDeviceDOExit routine. This routine
closes the remote IO target. During the close, I see all of the pending IO
requests get canceled.

As the system comes out of hibernation:
1. The system calls our EvtDeviceDOEntry routine. This routine detected that
we are returning from hibernations and then does the following:
2. Re-opens the Remote IO target (using the
WDF_IO_TARGET_OPEN_PARMS_INIT_REOPEN).
3. Issue the request to enable the device. The call returns with
STATUS_DELETE_PENDING. The driver issues this request with
WDF_REQUEST_SEND_OPTION_IGNORE_TARGET_STATE.

It looks as if the io target never got closed but I dump the state of the io
target (!wdfdk.wdfiotarget) I see that the device is in the started state
and there are no pending IO requests.

Any ideas?

TIA!


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Variable as in something that can change from underneath you that you have no control over its state or change. By reusing the same target on close and reopen, you introduce a variable (the reopen) which could affect state that you have no control of. Now, by creating a new io target you remove the variable of the reopen and still encounter the error, which means the iotarget reopen is not the root cause of the problem.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of JimmyJ
Sent: Thursday, December 10, 2009 8:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Hibernation problem with a Virtual HID Minidriver

I wonder what variable you are talking about? I’m building with the
6001.18001 tools. Could this be a change in the new in the Win7 tools?

Yes it could be the FTDI driver.

Another weird things about this:
After sending/failing the device enable request, I can no longer remove the mini-driver via the Device Manager – EvtReleaseHardware never gets called.
It looks like someone has a reference open somewhere but I don’t see any when looking at the io target.

“Doron Holan” wrote in message news:xxxxx@ntdev…
Well if you are opening a new io target, I doubt that this is a problem with the iotarget b/c we have removed the variable of closing and reopening the same target. Perhaps the ftdi driver is not ready to be communicated with

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of JimmyJ
Sent: Thursday, December 10, 2009 7:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hibernation problem with a Virtual HID Minidriver

Hi Doron,

I tried creating/opening a new io target on resume and had the same probem.

I’ll give !wdfkd.wdflogdump a try and get back to you.

Thanks,
Dale

“Doron Holan” wrote in message news:xxxxx@ntdev…
Turnon kmdf verbose logging and see what !wdfkd.wdflogdump (your driver
name) says. What if you create and open a new target on resume?

d

-----Original Message-----
From: JimmyJ
Sent: Thursday, December 10, 2009 7:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernation problem with a Virtual HID Minidriver

All,

I am working on a Win7 KMDF HID Minidriver that controls a serial port device. The serial port is actually an FTDI emulation port. The mini driver is a root-enumerated virtual device. It accesses the serial port by creating a remote IO target. The device has been designed to require an “enable”
command to make the device talk. This presents a problem coming out of hibernation. The mini driver detects when the system comes out of hibernation and then re-issue the enable command. The problem we’re having however is that when the driver re-issues the enable command, the remote IO target returns a status of STATUS_DELETE_PENDING.

Below are the details:

At startup:
1. At AddDevice time we register for Pnp Device Notification
(IoRegisterPlugPlayNotifcation) whose callback is invoked when the com port is detected by the OS.
2. From within the callback, we create a remote IO target using the symbolic link name and then issue the device enable command.

At Hibernation:
As the system shuts down it calls our EvtDeviceDOExit routine. This routine closes the remote IO target. During the close, I see all of the pending IO requests get canceled.

As the system comes out of hibernation:
1. The system calls our EvtDeviceDOEntry routine. This routine detected that we are returning from hibernations and then does the following:
2. Re-opens the Remote IO target (using the WDF_IO_TARGET_OPEN_PARMS_INIT_REOPEN).
3. Issue the request to enable the device. The call returns with STATUS_DELETE_PENDING. The driver issues this request with WDF_REQUEST_SEND_OPTION_IGNORE_TARGET_STATE.

It looks as if the io target never got closed but I dump the state of the io target (!wdfdk.wdfiotarget) I see that the device is in the started state and there are no pending IO requests.

Any ideas?

TIA!


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer