When certain event occurs, I want to restart another device in the system (driver is either written by MSFT or by my company) from my driver.
I couldn’t come across any mechanism to do it from kernel code, but I could do it only from user mode (using devcon sample).
I was wondering if IRP_MN_SURPRISE_REMOVAL could be triggered (simulation) to target device and the driver would be removed, then the rescan (or add device trigger if possible) will load the driver again.
How can this IRP or surprise removal event could be triggered (from BIOS or from my driver)?
–
++Sathya
Not a good idea. You can simulate surprise removal from a bus filter driver,
but it generally doesn’t work well. You have worked yourself into a rather
peculiar design problem. How exactly did you arrive at the conclusion that
removing some other device is the best approach to whatever it is you are
trying to do?
On Wed, Jun 25, 2008 at 4:12 AM, wrote:
> When certain event occurs, I want to restart another device in the system
> (driver is either written by MSFT or by my company) from my driver.
>
> I couldn’t come across any mechanism to do it from kernel code, but I could
> do it only from user mode (using devcon sample).
>
> I was wondering if IRP_MN_SURPRISE_REMOVAL could be triggered (simulation)
> to target device and the driver would be removed, then the rescan (or add
> device trigger if possible) will load the driver again.
>
> How can this IRP or surprise removal event could be triggered (from BIOS or
> from my driver)?
>
> –
> ++Sathya
>
> —
> 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
>
–
Mark Roddy
Actually it was a workaround I am trying to do. When specific event occurs, MSFT inbox driver for a device has to be restarted to make it detect certain changes (unfortunately, the driver detects changes *only* during driver init). It’ll be same case with drivers written by OEMs as well.
So, in my driver, when the situation is encountered, I want to restart the other device (MSFT or OEM driver) - but I’m unable to do it from kernel mode.
This is why I was checking options to simulate surprise removal & rescan to achieve restart of the device.
xxxxx@yahoo.com wrote:
Actually it was a workaround I am trying to do. When specific event occurs, MSFT inbox driver for a device has to be restarted to make it detect certain changes (unfortunately, the driver detects changes *only* during driver init). It’ll be same case with drivers written by OEMs as well.
Why are people so afraid to share their details? Be SPECIFIC. Which
driver, and what event? Is this a continuation of the PCI hot-plug
discussion we had a while ago?
If you tell us what the problem really is, we can suggest solutions that
might actually work. You have fallen into a very common trap: you have
a problem, you have focused in on one very narrow possible solution to
the problem, and are asking how to achieve that very narrow solution.
Instead, if you asked about the overall PROBLEM, we might be able to
direct you into a more productive line of thinking.
This is why I was checking options to simulate surprise removal & rescan to achieve restart of the device.
Sending an IRP_MN_SURPRISE_REMOVAL is not going to help. That tells the
driver that it’s device has been removed, but it’s only one small part
of a much larger PnP dance that goes on when a device is removed. Plus,
the bus driver below won’t have any idea that the device was removed.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Here are more details about the problem. HDMI audio controller (or even audio device) driver written by MSFT (or by OEMs) scans for topology only during init. I don’t have more info about why.
Consider this situation: when audio is being played in one HDMI port and other port is currently not connected with any device. NOW, a HDMI device is connected to other port, then HDMI audio controller *should* be restarted to scan both ports. This will disturb existing port stream & also has end-user impact.
But looks like (according to MSFT), restart of HDMI controller device is only possible solution. Now, I’m figuring out how best to restart it (existing stream disturbance can’t be avoided) from my display driver when I detect new HDMI device is connected.
The solution is to signal a user mode helper service which will do the disable/enable for you.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Wednesday, June 25, 2008 9:39 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to trigger IRP_MN_SURPRISE_REMOVAL?
Here are more details about the problem. HDMI audio controller (or even audio device) driver written by MSFT (or by OEMs) scans for topology only during init. I don’t have more info about why.
Consider this situation: when audio is being played in one HDMI port and other port is currently not connected with any device. NOW, a HDMI device is connected to other port, then HDMI audio controller *should* be restarted to scan both ports. This will disturb existing port stream & also has end-user impact.
But looks like (according to MSFT), restart of HDMI controller device is only possible solution. Now, I’m figuring out how best to restart it (existing stream disturbance can’t be avoided) from my display driver when I detect new HDMI device is connected.
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