filter driver for monitor
in [Device Drivers]
|
From: Vikash on 12 Jan 2010 04:06 Hi, I need to write a filter driver which should be the topmost driver on the device stack associated with the monitor. It is mostly going to be a pass through driver for present. Basically its purpose is to read all IRP destined for the monitor and log relevant info. It is not going to modify the IRP in any way. I have a generic code for a filter driver with me and I intend to use that for this purpose modifying it to suit my needs. But I do not know how to put it at the top of the device stack associated with the monitor device. Specifically I have 2 questions: 1. How do I figure out the device stack associated with the monitor? Is there any tool available which would show the different devices stacked on top of each other with the bottommost device being the pdo (physical device object ) associated with the monitor? 2. How do I install this generic driver such that when its DeviceAdd routine is called, it is called with the pdo (physical deivce object) being the monitor pdo? If this is possible, my approach would be to create a device in the DeviceAdd routine and then attach the device using IoAttachDeviceToDeviceStack. Please also guide me if my approach is correct. I am completely new to writing drivers and my approach is completely based on whatever materials I have been able to go through. Thanks, Vikash.
From: Ivan Brugiolo [MSFT] on 12 Jan 2010 04:57 Vikash, we understand that you have been trying to write a `VNC/TS-like` remoting solution without proper OS support, and, now you have dug yourself deep enough in a non sustainable path to complete your project. Last I recall, you were trying to `power-down` the monitor as a replacement for a proper window-station lock, and as a mitigation for people peeking at the artificially remoted session. The monitor stack (whose some detail you can visualize yourself down here) is non filterable, and, it does not have any mainstream filterable interface, even if it were. monitor.sys is the almost-bus-driver for the monitor. The children of monitor.sys are ad-hoc instantiated by a private enumeration contract of videoprt.sys and/or dxgkrnl.sys. Each port/miniport-model (for XPDM and WDDM) have a special mechanism to drive monitor.sys. For example, for WDDM, the VidPn-Targets drive monitor enumerations. Since enumeration of VidPn targets is heuristic and custom at best (there are heuristics in the hardware, to infer if a VGA connector build before 1997 is plugged-in, or if an EDID-less KVM switch is hooked-up, or if a monitor is really a LCD display reported in the ACPI table, and, if it has methods-events for being lid-opened/lid-closed, and the such) the callbacks and interactions between dxgkrnl.sys and monitor.sys are privates. Even if you could get down to some standard IRP_MJ_SYSTEM_CONTROL (for WMI methods), they will trigger other private calls with the power-manager in NtOsKrnl. For your original problem, the best and most sustainable solution is to PnP-stop the physical video-card of the machine while your virtual display-device is loaded. 1) tools available for device stack enumeration. The tools is `!devnode 1 0` followed by `!devstack`. The same view can be inferred by clever SetupAPI calls. DevNode 0xfffffa8001869890 for PDO 0xfffffa8001868a00 InstancePath is "ACPI\PNP0A03\2&daba3ff&1" ServiceName is "pci" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) DevNode 0xfffffa8002470010 for PDO 0xfffffa800186ba20 InstancePath is "PCI\VEN_8086&DEV_2770&SUBSYS_464C8086&REV_02\3&18d45aa6&0&00" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) DevNode 0xfffffa8002470d90 for PDO 0xfffffa8001870060 InstancePath is "PCI\VEN_8086&DEV_2772&SUBSYS_464C8086&REV_02\3&18d45aa6&0&10" ServiceName is "igfx" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) DevNode 0xfffffa8003bf1960 for PDO 0xfffffa8003bf8ab0 InstancePath is "DISPLAY\DEL4000\4&125fbeaa&0&UID16843008" ServiceName is "monitor" TargetDeviceNotify List - f 0xfffff8a000f4da80 b 0xfffff8a000f4da80 State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) 2: kd> !devstack 0xfffffa8003bf8ab0 !DevObj !DrvObj !DevExt ObjectName fffffa8003c418c0 \Driver\monitor fffffa8003bffd70 > fffffa8003bf8ab0 \Driver\igfx fffffa8003bf8c00 00000066 !DevNode fffffa8003bf1960 : DeviceInst is "DISPLAY\DEL4000\4&125fbeaa&0&UID16843008" ServiceName is "monitor" -- -- This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "Vikash" <vikashrungta76(a)gmail.com> wrote in message news:29abd10e-c548-43c3-9d0e-dc72509d6125(a)j24g2000yqa.googlegroups.com... > Hi, > I need to write a filter driver which should be the topmost driver > on the device stack associated with the monitor. It is mostly going to > be a pass through driver for present. Basically its purpose is to read > all IRP destined for the monitor and log relevant info. It is not > going to modify the IRP in any way. I have a generic code for a filter > driver with me and I intend to use that for this purpose modifying it > to suit my needs. But I do not know how to put it at the top of the > device stack associated with the monitor device. > > Specifically I have 2 questions: > > 1. How do I figure out the device stack associated with the monitor? > Is there any tool available which would show the different devices > stacked on top of each other with the bottommost device being the pdo > (physical device object ) associated with the monitor? > > 2. How do I install this generic driver such that when its DeviceAdd > routine is called, it is called with the pdo (physical deivce object) > being the monitor pdo? If this is possible, my approach would be to > create a device in the DeviceAdd routine and then attach the device > using IoAttachDeviceToDeviceStack. Please also guide me if my approach > is correct. > > I am completely new to writing drivers and my approach is completely > based on whatever materials I have been able to go through. > > Thanks, > Vikash. > > >
From: Vikash on 12 Jan 2010 06:10 On Jan 12, 2:57 pm, "Ivan Brugiolo [MSFT]" <ivanb...(a)online.microsoft.com> wrote: > Vikash, > we understand that you have been trying to write a `VNC/TS-like` remoting > solution > without proper OS support, and, now you have dug yourself deep enough in > a non sustainable path to complete your project. > Last I recall, you were trying to `power-down` the monitor as a replacement > for a proper window-station lock, and as a mitigation for people peeking at > the > artificially remoted session. > > The monitor stack (whose some detail you can visualize yourself down here) > is non filterable, and, it does not have any mainstream filterable > interface, even if it were. > monitor.sys is the almost-bus-driver for the monitor. > The children of monitor.sys are ad-hoc instantiated by a private enumeration > contract > of videoprt.sys and/or dxgkrnl.sys. Each port/miniport-model (for XPDM and > WDDM) > have a special mechanism to drive monitor.sys. > For example, for WDDM, the VidPn-Targets drive monitor enumerations. > Since enumeration of VidPn targets is heuristic and custom at best (there > are heuristics > in the hardware, to infer if a VGA connector build before 1997 is > plugged-in, or if > an EDID-less KVM switch is hooked-up, or if a monitor > is really a LCD display reported in the ACPI table, and, if it has > methods-events for > being lid-opened/lid-closed, and the such) the callbacks and interactions > between > dxgkrnl.sys and monitor.sys are privates. > Even if you could get down to some standard IRP_MJ_SYSTEM_CONTROL > (for WMI methods), they will trigger other private calls with the > power-manager in > NtOsKrnl. > > For your original problem, the best and most sustainable solution is to > PnP-stop the physical video-card of the machine while your virtual > display-device is loaded. > > 1) tools available for device stack enumeration. > The tools is `!devnode 1 0` followed by `!devstack`. > The same view can be inferred by clever SetupAPI calls. > > DevNode 0xfffffa8001869890 for PDO 0xfffffa8001868a00 > InstancePath is "ACPI\PNP0A03\2&daba3ff&1" > ServiceName is "pci" > State = DeviceNodeStarted (0x308) > Previous State = DeviceNodeEnumerateCompletion (0x30d) > DevNode 0xfffffa8002470010 for PDO 0xfffffa800186ba20 > InstancePath is > "PCI\VEN_8086&DEV_2770&SUBSYS_464C8086&REV_02\3&18d45aa6&0&00" > State = DeviceNodeStarted (0x308) > Previous State = DeviceNodeEnumerateCompletion (0x30d) > DevNode 0xfffffa8002470d90 for PDO 0xfffffa8001870060 > InstancePath is > "PCI\VEN_8086&DEV_2772&SUBSYS_464C8086&REV_02\3&18d45aa6&0&10" > ServiceName is "igfx" > State = DeviceNodeStarted (0x308) > Previous State = DeviceNodeEnumerateCompletion (0x30d) > DevNode 0xfffffa8003bf1960 for PDO 0xfffffa8003bf8ab0 > InstancePath is "DISPLAY\DEL4000\4&125fbeaa&0&UID16843008" > ServiceName is "monitor" > TargetDeviceNotify List - f 0xfffff8a000f4da80 b > 0xfffff8a000f4da80 > State = DeviceNodeStarted (0x308) > Previous State = DeviceNodeEnumerateCompletion (0x30d) > > 2: kd> !devstack 0xfffffa8003bf8ab0 > !DevObj !DrvObj !DevExt ObjectName > fffffa8003c418c0 \Driver\monitor fffffa8003bffd70> fffffa8003bf8ab0 \Driver\igfx fffffa8003bf8c00 00000066 > > !DevNode fffffa8003bf1960 : > DeviceInst is "DISPLAY\DEL4000\4&125fbeaa&0&UID16843008" > ServiceName is "monitor" > > -- > > -- > This posting is provided "AS IS" with no warranties, and confers no rights. > Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm > > "Vikash" <vikashrungt...(a)gmail.com> wrote in message > > news:29abd10e-c548-43c3-9d0e-dc72509d6125(a)j24g2000yqa.googlegroups.com... > > > Hi, > > I need to write a filter driver which should be the topmost driver > > on the device stack associated with the monitor. It is mostly going to > > be a pass through driver for present. Basically its purpose is to read > > all IRP destined for the monitor and log relevant info. It is not > > going to modify the IRP in any way. I have a generic code for a filter > > driver with me and I intend to use that for this purpose modifying it > > to suit my needs. But I do not know how to put it at the top of the > > device stack associated with the monitor device. > > > Specifically I have 2 questions: > > > 1. How do I figure out the device stack associated with the monitor? > > Is there any tool available which would show the different devices > > stacked on top of each other with the bottommost device being the pdo > > (physical device object ) associated with the monitor? > > > 2. How do I install this generic driver such that when its DeviceAdd > > routine is called, it is called with the pdo (physical deivce object) > > being the monitor pdo? If this is possible, my approach would be to > > create a device in the DeviceAdd routine and then attach the device > > using IoAttachDeviceToDeviceStack. Please also guide me if my approach > > is correct. > > > I am completely new to writing drivers and my approach is completely > > based on whatever materials I have been able to go through. > > > Thanks, > > Vikash. Hi Ivan, Thanks for the detailed information but I am still getting confused as to what do you mean by the statement that the monitor stack is non filterable. What stops us from writing a filter which first receives all IRPs destined for monitor.sys. What is the technical limitation? This is the way I am visualizing the situation (the device stack): =================MY FILTER DEVICE OBJECT========== | V ===== ===the previous topmost device object associated with the monitor device stack===== | V =========other lower devices like dxg etc maybe having private contract ============== My main objective is to log all IRPs passed to the monitor device stack. The reason I want to do this is to figure out the IOCTLs responsible for turning off/turning on a monitor. Later on for IOCTLs responsible for turning on a monitor, I would not allow them to pass through. Thanks, Vikash.
From: Ivan Brugiolo [MSFT] on 13 Jan 2010 16:49 > Thanks for the detailed information but I am still getting confused > as to what do you mean by the statement that the monitor stack is non > filterable. It is not filterable for 2 reasons: - it is not supported to do that - the IOCLT that your filter will see are not public. > My main objective is to log all IRPs passed to the monitor device > stack. The reason I want to do this is to figure out the IOCTLs > responsible for turning off/turning on a monitor. Later on for IOCTLs > responsible for turning on a monitor, I would not allow them to pass > through Not all monitor power actions are IOCLT. ACPI method calls for built-in LCDs would be one example. -- -- This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "Vikash" <vikashrungta76(a)gmail.com> wrote in message news:b0223877-bd31-4a83-b343-8169b7c11d26(a)m25g2000yqc.googlegroups.com... > On Jan 12, 2:57 pm, "Ivan Brugiolo [MSFT]" > <ivanb...(a)online.microsoft.com> wrote: >> Vikash, >> we understand that you have been trying to write a `VNC/TS-like` remoting >> solution >> without proper OS support, and, now you have dug yourself deep enough in >> a non sustainable path to complete your project. >> Last I recall, you were trying to `power-down` the monitor as a >> replacement >> for a proper window-station lock, and as a mitigation for people peeking >> at >> the >> artificially remoted session. >> >> The monitor stack (whose some detail you can visualize yourself down >> here) >> is non filterable, and, it does not have any mainstream filterable >> interface, even if it were. >> monitor.sys is the almost-bus-driver for the monitor. >> The children of monitor.sys are ad-hoc instantiated by a private >> enumeration >> contract >> of videoprt.sys and/or dxgkrnl.sys. Each port/miniport-model (for XPDM >> and >> WDDM) >> have a special mechanism to drive monitor.sys. >> For example, for WDDM, the VidPn-Targets drive monitor enumerations. >> Since enumeration of VidPn targets is heuristic and custom at best (there >> are heuristics >> in the hardware, to infer if a VGA connector build before 1997 is >> plugged-in, or if >> an EDID-less KVM switch is hooked-up, or if a monitor >> is really a LCD display reported in the ACPI table, and, if it has >> methods-events for >> being lid-opened/lid-closed, and the such) the callbacks and interactions >> between >> dxgkrnl.sys and monitor.sys are privates. >> Even if you could get down to some standard IRP_MJ_SYSTEM_CONTROL >> (for WMI methods), they will trigger other private calls with the >> power-manager in >> NtOsKrnl. >> >> For your original problem, the best and most sustainable solution is to >> PnP-stop the physical video-card of the machine while your virtual >> display-device is loaded. >> >> 1) tools available for device stack enumeration. >> The tools is `!devnode 1 0` followed by `!devstack`. >> The same view can be inferred by clever SetupAPI calls. >> >> DevNode 0xfffffa8001869890 for PDO 0xfffffa8001868a00 >> InstancePath is "ACPI\PNP0A03\2&daba3ff&1" >> ServiceName is "pci" >> State = DeviceNodeStarted (0x308) >> Previous State = DeviceNodeEnumerateCompletion (0x30d) >> DevNode 0xfffffa8002470010 for PDO 0xfffffa800186ba20 >> InstancePath is >> "PCI\VEN_8086&DEV_2770&SUBSYS_464C8086&REV_02\3&18d45aa6&0&00" >> State = DeviceNodeStarted (0x308) >> Previous State = DeviceNodeEnumerateCompletion (0x30d) >> DevNode 0xfffffa8002470d90 for PDO 0xfffffa8001870060 >> InstancePath is >> "PCI\VEN_8086&DEV_2772&SUBSYS_464C8086&REV_02\3&18d45aa6&0&10" >> ServiceName is "igfx" >> State = DeviceNodeStarted (0x308) >> Previous State = DeviceNodeEnumerateCompletion (0x30d) >> DevNode 0xfffffa8003bf1960 for PDO 0xfffffa8003bf8ab0 >> InstancePath is "DISPLAY\DEL4000\4&125fbeaa&0&UID16843008" >> ServiceName is "monitor" >> TargetDeviceNotify List - f 0xfffff8a000f4da80 b >> 0xfffff8a000f4da80 >> State = DeviceNodeStarted (0x308) >> Previous State = DeviceNodeEnumerateCompletion (0x30d) >> >> 2: kd> !devstack 0xfffffa8003bf8ab0 >> !DevObj !DrvObj !DevExt ObjectName >> fffffa8003c418c0 \Driver\monitor fffffa8003bffd70> fffffa8003bf8ab0 >> \Driver\igfx fffffa8003bf8c00 00000066 >> >> !DevNode fffffa8003bf1960 : >> DeviceInst is "DISPLAY\DEL4000\4&125fbeaa&0&UID16843008" >> ServiceName is "monitor" >> >> -- >> >> -- >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> Use of any included script samples are subject to the terms specified >> athttp://www.microsoft.com/info/cpyright.htm >> >> "Vikash" <vikashrungt...(a)gmail.com> wrote in message >> >> news:29abd10e-c548-43c3-9d0e-dc72509d6125(a)j24g2000yqa.googlegroups.com... >> >> > Hi, >> > I need to write a filter driver which should be the topmost driver >> > on the device stack associated with the monitor. It is mostly going to >> > be a pass through driver for present. Basically its purpose is to read >> > all IRP destined for the monitor and log relevant info. It is not >> > going to modify the IRP in any way. I have a generic code for a filter >> > driver with me and I intend to use that for this purpose modifying it >> > to suit my needs. But I do not know how to put it at the top of the >> > device stack associated with the monitor device. >> >> > Specifically I have 2 questions: >> >> > 1. How do I figure out the device stack associated with the monitor? >> > Is there any tool available which would show the different devices >> > stacked on top of each other with the bottommost device being the pdo >> > (physical device object ) associated with the monitor? >> >> > 2. How do I install this generic driver such that when its DeviceAdd >> > routine is called, it is called with the pdo (physical deivce object) >> > being the monitor pdo? If this is possible, my approach would be to >> > create a device in the DeviceAdd routine and then attach the device >> > using IoAttachDeviceToDeviceStack. Please also guide me if my approach >> > is correct. >> >> > I am completely new to writing drivers and my approach is completely >> > based on whatever materials I have been able to go through. >> >> > Thanks, >> > Vikash. > > Hi Ivan, > Thanks for the detailed information but I am still getting confused > as to what do you mean by the statement that the monitor stack is non > filterable. What stops us from writing a filter which first receives > all IRPs destined for monitor.sys. What is the technical limitation? > This is the way I am visualizing the situation (the device stack): > > =================MY FILTER DEVICE OBJECT========== > | > V > ===== ===the previous topmost device object associated with the > monitor device stack===== > | > V > =========other lower devices like dxg etc maybe having private > contract ============== > > My main objective is to log all IRPs passed to the monitor device > stack. The reason I want to do this is to figure out the IOCTLs > responsible for turning off/turning on a monitor. Later on for IOCTLs > responsible for turning on a monitor, I would not allow them to pass > through. > > Thanks, > Vikash.
From: Kalra on 14 Jan 2010 09:17 Hi Ivan, I am new to google groups and found interesting discussions going on here. This one is a relevant to what i am trying to do. Few queries regarding your post: - Is there a Wmi method/class which can be used to shut off a monitor. I have read only about setting brightness through Wmi? If you are referring to SetPowerState Method of the CIM_DesktopMonitor I don't think this method is provided by Wmi by default. Correct me if wrong? - When you say "PnP-stop the physical video-card of the machine while your virtual display-device is loaded" do you mean to say that stop your native display driver and let your virtual display driver (which might be a mirror driver)? By the way I was curious to know how does Control Panel--> Power Options--> Timer switch off the monitor and I took call stack to read that DispatchPower of monitor internally calls DispatchPower of dxgkrnl which would obviously end up in miniport. And miniport would be using its I2C interface to shutoff the monitor. -Autumn
|
Next
|
Last
Pages: 1 2 Prev: WS2003/XP/2000 Driver signing Next: WdfDriverCreate causes a bug check 0x7E? |