Developing Virtual WDDM Driver

Hi AlL,

I am developing virtual WDDM driver for extended display on usb device.

I would like to know how to load my secondary virtual miniport. (at run time or at boot time.)

My question is, If i am loading my virtual miniport driver as primary and actual vendor primary driver will not be loading then how to interact with graphic card and how rendering will be done.???

Or how can i increase one vidpn target in existing graphic driver and handle calls for that at run time. Is it possible to laod filter miniport driver at run time??

Hi,

How can i load filter wddm driver over existing wddm driver??

Regards,
Fenil

As far as I know “WDDM filters” are not supported. There was a
discussion here a while back involving one party that was clearly
indicating that they knew how to do such a thing, but they were not in
a particularly transparent mode regarding the how of doing it.

Mark Roddy

On Fri, Sep 9, 2011 at 8:19 AM, wrote:
> Hi,
>
> How can i load filter wddm driver over existing wddm driver??
>
> Regards,
> Fenil
>
> —
> 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
>

Various posts already answered all this. However, questions still seem to continue. Trying to repeat, summarize and emphasize a bit more:

  • No discussion here indicated any WDDM Filter (Hook) driver knowledge.
    Except one single, very recent short question (I answered it).
  • WDDM Filter (Hook) drivers are not supported.
  • Microsoft strongly discourages such “Worrysome Practices” (see WinHEC 2008 graphics slides).
  • Asking how to write a WDDM Filter is a bit like “How do I hack the Pentagon computer?”
  • It can be done, but no single and simple “how to” (it can even change every day).
  • It is hacking, reverse engineering and research on a moving target.
  • It requires hooking of DXG DDI APIs which are not designed for hooking.
  • It requires massive exploration and reverse engineering of hooked drivers.
  • It requires adapter specific code for each hooked driver version.
  • It could break with every new Service Pack, version of Windows or hooked driver.
  • It is actually a war against Microsoft- and GPU-Vendor-Technologies.
  • It takes years of an intense fight with multiple enemies:
  1. dxgkrnl.sys (who can become very angry, when lied to).
  2. WDDM User Mode Driver and DirectX runtime (who need to be cheated as well).
  3. Hooked drivers (whose unknown inner workings deliver nasty surprises).
  • Some USB-Display and Extension-Display vendors did it indeed
    (some with huge effort, others with huge problems).
  • We did it for one of our customers only after we could not discourage them.
  • We had: A group of dedicated WDDM developers with years of previous WDDM experience.
  • We needed: More than a year to come up with a first acceptable (not even good) solution.

Anybody starting this unsupported extreme adventure should at least know, what he is up against…

PS: Just to make sure nobody confuses things - Above I am ONLY talking about WDDM Filter (Hook) drivers. NOT talking about WDDM drivers in general. WDDM drivers are extremely difficult, but supported and even documented to a certain extend.

Marcel Ruedinger
datronicsoft

xxxxx@datronic.de wrote:

Various posts already answered all this. However, questions still seem to continue. Trying to repeat, summarize and emphasize a bit more:

  • No discussion here indicated any WDDM Filter (Hook) driver knowledge.

Right, because there is no such thing, officially. Other companies
(example: Datalink) have implemented such a thing, but they have only
done so through reverse engineering and hacking. They are extremely
unlikely to share their secrets in a public forum like this.

Anybody starting this unsupported extreme adventure should at least know, what he is up against…

I think you have produced an excellent and entirely accurate summary of
the situation. Unfortunate, given the demand, but accurate.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.