Gosh… I’m really sorry, this shouldn’t be sent to the list but directly to
Peter. I copied his address from mail to the list and Outlook somewhat
managed address is displayed as his but if I hover mouse over it, the real
address is list one. Bummer. I really mean mail address not display name…
I apologize to everybody and mainly Anton.
Michal
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-660281- xxxxx@lists.osr.com] On Behalf Of xxxxx@centrum.cz
Sent: Friday, August 24, 2018 9:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF filter driver questions
Hi Peter,
> For the nine thousandth time… Anton: Sit down and shut the fuck up.
Poor Anton. For me it just a fun now but if he is doing this all the
time…
I guess he deserves it
> Mr. Vodicka, a long established and respected Windows driver developer,
> returns to our midst after years of wandering in the wilderness
That’s the most funny part. You know, what is my hobby? Mountains,
wilderness, so I really do what you said. I’m even co-moderating a
discussion group related to outdoor activities and discuss there too much.
We even have a guy similar to Anton there, maybe every list/forum has its
Anton
Michal
NTDEV is sponsored by OSR
Visit the list online at: http: > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at > http:</http:></http:></http:>
Do you think requests within one UMDF drivers block (upper UMDF filter -> UMDF driver -> lower UMDF filter) are going directly from driver to driver and not through kernel redirector?
I don’t know that, but I suspect that’s the way it is. We have the
source, I suppose we could look it up.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I don’t know that, but I suspect that’s the way it is. We have the
> source, I suppose we could look it up.
WDF sources are public now? Or you mean MVP source access? I don’t have it since MVP for kernel was finished and marketing took over the MVP program.
That’s great Only UMDF 2 is there but still a nice surprise.
However, I’m not sure if we could find out how UMDF to UMDF communication works. From FAQ: Source for UMDF v1 or for infrastructure components like the UMDF redirector are not included.
The limitation comes from how we tied UMDF into the device stack. The UMDF redirector driver adds a device object into the stack wherever you include WUDFRD in the list of drivers (upper filter, lower filter, service, etc…) and most IO that comes into it is redirected to a UMDF host process and it targets a UMDF device node in that host.
That device node in the host can have any (more or less) number of UMDF drivers attached to it. IO comes into the top driver, remains in the host as it travels through other UMDF drivers, and at the bottom UMDF has a dispatcher that can take the IO back down to the driver underneath WUDFRD (or some more esoteric options).
The limitation that all UMDF drivers have be together in a single block comes from the part where the redirector sends I/O to a specific stack. We didn’t put in a way to send it to a specific place in the stack.
I don’t remember where the rule for mixing UMDF 1 and UMDF 2 ended up (after I’d moved on).
Welcome back Michal.
-p
-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@probo.com Sent: Friday, August 24, 2018 1:06 PM To: Windows System Software Devs Interest List Subject: Re: [ntdev] UMDF filter driver questions
xxxxx@centrum.cz wrote: > Do you think requests within one UMDF drivers block (upper UMDF filter -> UMDF driver -> lower UMDF filter) are going directly from driver to driver and not through kernel redirector?
I don’t know that, but I suspect that’s the way it is. We have the source, I suppose we could look it up.
– Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
Makes sense and looks as reasonable and efficient architecture. Good to know adding UMDF filter(s) for UMDF driver doesn’t add big performance penalty.
I can imagine reasons for versions rule but it is a bit unfortunate. Here it forces me to use UMDF 1 for filter(s) and if class driver is rewritten to UMDF 2 in some OS update, filter(s) would have to be rewritten, too. And the device will stop work after such update. Also, I wanted to try UMDF 2
Michal
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-660325- xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com
Sent: Saturday, August 25, 2018 10:04 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF filter driver questions
I happened to notice a question I can answer.
The limitation comes from how we tied UMDF into the device stack. The
UMDF redirector driver adds a device object into the stack wherever you
include WUDFRD in the list of drivers (upper filter, lower filter, service, etc…)
and most IO that comes into it is redirected to a UMDF host process and it
targets a UMDF device node in that host.
That device node in the host can have any (more or less) number of UMDF
drivers attached to it. IO comes into the top driver, remains in the host as it
travels through other UMDF drivers, and at the bottom UMDF has a
dispatcher that can take the IO back down to the driver underneath WUDFRD
(or some more esoteric options).
The limitation that all UMDF drivers have be together in a single block comes
from the part where the redirector sends I/O to a specific stack. We didn’t
put in a way to send it to a specific place in the stack.
I don’t remember where the rule for mixing UMDF 1 and UMDF 2 ended up
(after I’d moved on).
Welcome back Michal.
-p
-----Original Message-----
From: xxxxx@lists.osr.com > xxxxx@lists.osr.com> On Behalf Of xxxxx@probo.com > Sent: Friday, August 24, 2018 1:06 PM > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] UMDF filter driver questions > > xxxxx@centrum.cz wrote: > > Do you think requests within one UMDF drivers block (upper UMDF filter -> > UMDF driver -> lower UMDF filter) are going directly from driver to driver > and not through kernel redirector? > > I don’t know that, but I suspect that’s the way it is. We have the source, I > suppose we could look it up. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > Visit the list online at: > https:> osronline.com%2Fshowlists.cfm%3Flist%3Dntdev&data=02%7C01%7Cp > eterwie%40microsoft.com%7Cadb3437bc96d46f6d75d08d609fd02f2%7C72f9 > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636707379613696382&sd > ata=xdwrLpo3RvikI7wfxmUzhs3cTteG0CN3IO%2BPJxgLDuE%3D&reserv > ed=0> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at > https:> osr.com%2Fseminars&data=02%7C01%7Cpeterwie%40microsoft.com% > 7Cadb3437bc96d46f6d75d08d609fd02f2%7C72f988bf86f141af91ab2d7cd011d > b47%7C1%7C0%7C636707379613696382&sdata=VDnBPakJYVX7BMkoK3 > ySJTgsWFCcmWnrYB1bDGLNjuk%3D&reserved=0> > > To unsubscribe, visit the List Server section of OSR Online at > https:> osronline.com%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7 > Cpeterwie%40microsoft.com%7Cadb3437bc96d46f6d75d08d609fd02f2%7C72 > f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636707379613696382& > sdata=SfVwrzs%2FBIS5KNekKuXbpjMKagPf8GXGmc%2BVnNT%2B25I%3D&a > mp;reserved=0> > > — > NTDEV is sponsored by OSR > > Visit the list online at: > http: > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at > http:</http:></http:></http:></https:></https:></https:>
It does my heart good to see you back here Michal.
mm
On Sat, Aug 25, 2018, 9:22 PM xxxxx@centrum.cz wrote:
> Thanks, Peter > > Makes sense and looks as reasonable and efficient architecture. Good to > know adding UMDF filter(s) for UMDF driver doesn’t add big performance > penalty. > > I can imagine reasons for versions rule but it is a bit unfortunate. Here > it forces me to use UMDF 1 for filter(s) and if class driver is rewritten > to UMDF 2 in some OS update, filter(s) would have to be rewritten, too. And > the device will stop work after such update. Also, I wanted to try UMDF 2 > > > Michal > > > -----Original Message----- > > From: xxxxx@lists.osr.com [mailto:bounce-660325- > > xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com > > Sent: Saturday, August 25, 2018 10:04 AM > > To: Windows System Software Devs Interest List > > Subject: RE: [ntdev] UMDF filter driver questions > > > > I happened to notice a question I can answer. > > > > The limitation comes from how we tied UMDF into the device stack. The > > UMDF redirector driver adds a device object into the stack wherever you > > include WUDFRD in the list of drivers (upper filter, lower filter, > service, etc…) > > and most IO that comes into it is redirected to a UMDF host process and > it > > targets a UMDF device node in that host. > > > > That device node in the host can have any (more or less) number of UMDF > > drivers attached to it. IO comes into the top driver, remains in the > host as it > > travels through other UMDF drivers, and at the bottom UMDF has a > > dispatcher that can take the IO back down to the driver underneath WUDFRD > > (or some more esoteric options). > > > > The limitation that all UMDF drivers have be together in a single block > comes > > from the part where the redirector sends I/O to a specific stack. We > didn’t > > put in a way to send it to a specific place in the stack. > > > > I don’t remember where the rule for mixing UMDF 1 and UMDF 2 ended up > > (after I’d moved on). > > > > Welcome back Michal. > > > > -p > > > > -----Original Message----- > > From: xxxxx@lists.osr.com > > xxxxx@lists.osr.com> On Behalf Of xxxxx@probo.com > > Sent: Friday, August 24, 2018 1:06 PM > > To: Windows System Software Devs Interest List > > Subject: Re: [ntdev] UMDF filter driver questions > > > > xxxxx@centrum.cz wrote: > > > Do you think requests within one UMDF drivers block (upper UMDF filter > -> > > UMDF driver -> lower UMDF filter) are going directly from driver to > driver > > and not through kernel redirector? > > > > I don’t know that, but I suspect that’s the way it is. We have the > source, I > > suppose we could look it up. > > > > – > > Tim Roberts, xxxxx@probo.com > > Providenza & Boekelheide, Inc. > > > > > > — > > NTDEV is sponsored by OSR > > > > Visit the list online at: > > https:> > osronline.com%2Fshowlists.cfm%3Flist%3Dntdev&data=02%7C01%7Cp > > eterwie%40microsoft.com%7Cadb3437bc96d46f6d75d08d609fd02f2%7C72f9 > > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636707379613696382&sd > > ata=xdwrLpo3RvikI7wfxmUzhs3cTteG0CN3IO%2BPJxgLDuE%3D&reserv > > ed=0> > > > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > > software drivers! > > Details at > > https:> > osr.com%2Fseminars&data=02%7C01%7Cpeterwie%40microsoft.com% > > 7Cadb3437bc96d46f6d75d08d609fd02f2%7C72f988bf86f141af91ab2d7cd011d > > b47%7C1%7C0%7C636707379613696382&sdata=VDnBPakJYVX7BMkoK3 > > ySJTgsWFCcmWnrYB1bDGLNjuk%3D&reserved=0> > > > > To unsubscribe, visit the List Server section of OSR Online at > > https:> > osronline.com%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7 > > Cpeterwie%40microsoft.com%7Cadb3437bc96d46f6d75d08d609fd02f2%7C72 > > f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636707379613696382& > > sdata=SfVwrzs%2FBIS5KNekKuXbpjMKagPf8GXGmc%2BVnNT%2B25I%3D&a > > mp;reserved=0> > > > > — > > NTDEV is sponsored by OSR > > > > Visit the list online at: > > http: > > > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > > software drivers! > > Details at http: > > > > To unsubscribe, visit the List Server section of OSR Online at > > http: > > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:></http:></http:></http:></https:></https:></https:>
It does my heart good to see you back here Michal.
mm
On Sat, Aug 25, 2018, 9:22 PM xxxxx@centrum.cz wrote:
Thanks, Peter
Makes sense and looks as reasonable and efficient architecture. Good to know adding UMDF filter(s) for UMDF driver doesn’t add big performance penalty.
I can imagine reasons for versions rule but it is a bit unfortunate. Here it forces me to use UMDF 1 for filter(s) and if class driver is rewritten to UMDF 2 in some OS update, filter(s) would have to be rewritten, too. And the device will stop work after such update. Also, I wanted to try UMDF 2
Michal
> -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-660325- > xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com > Sent: Saturday, August 25, 2018 10:04 AM > To: Windows System Software Devs Interest List > Subject: RE: [ntdev] UMDF filter driver questions > > I happened to notice a question I can answer. > > The limitation comes from how we tied UMDF into the device stack. The > UMDF redirector driver adds a device object into the stack wherever you > include WUDFRD in the list of drivers (upper filter, lower filter, service, etc…) > and most IO that comes into it is redirected to a UMDF host process and it > targets a UMDF device node in that host. > > That device node in the host can have any (more or less) number of UMDF > drivers attached to it. IO comes into the top driver, remains in the host as it > travels through other UMDF drivers, and at the bottom UMDF has a > dispatcher that can take the IO back down to the driver underneath WUDFRD > (or some more esoteric options). > > The limitation that all UMDF drivers have be together in a single block comes > from the part where the redirector sends I/O to a specific stack. We didn’t > put in a way to send it to a specific place in the stack. > > I don’t remember where the rule for mixing UMDF 1 and UMDF 2 ended up > (after I’d moved on). > > Welcome back Michal. > > -p > > -----Original Message----- > From: xxxxx@lists.osr.com > xxxxx@lists.osr.com> On Behalf Of xxxxx@probo.com > Sent: Friday, August 24, 2018 1:06 PM > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] UMDF filter driver questions > > xxxxx@centrum.cz wrote: > > Do you think requests within one UMDF drivers block (upper UMDF filter -> > UMDF driver -> lower UMDF filter) are going directly from driver to driver > and not through kernel redirector? > > I don’t know that, but I suspect that’s the way it is. We have the source, I > suppose we could look it up. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > Visit the list online at: > https:> osronline.com%2Fshowlists.cfm%3Flist%3Dntdev&data=02%7C01%7Cp > eterwie%40microsoft.com%7Cadb3437bc96d46f6d75d08d609fd02f2%7C72f9 > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636707379613696382&sd > ata=xdwrLpo3RvikI7wfxmUzhs3cTteG0CN3IO%2BPJxgLDuE%3D&reserv > ed=0> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at > https:> osr.com%2Fseminars&data=02%7C01%7Cpeterwie%40microsoft.com% > 7Cadb3437bc96d46f6d75d08d609fd02f2%7C72f988bf86f141af91ab2d7cd011d > b47%7C1%7C0%7C636707379613696382&sdata=VDnBPakJYVX7BMkoK3 > ySJTgsWFCcmWnrYB1bDGLNjuk%3D&reserved=0> > > To unsubscribe, visit the List Server section of OSR Online at > https:> osronline.com%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7 > Cpeterwie%40microsoft.com%7Cadb3437bc96d46f6d75d08d609fd02f2%7C72 > f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636707379613696382& > sdata=SfVwrzs%2FBIS5KNekKuXbpjMKagPf8GXGmc%2BVnNT%2B25I%3D&a > mp;reserved=0> > > — > NTDEV is sponsored by OSR > > Visit the list online at: > http: > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at > http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></http:></http:></http:></https:></https:></https:>
Only UMDF 2 is there but still a nice surprise.