linking kmdf statically

NTDEV
1

Hi all,

I have a problem with upgrading wdf01000.sys on Vista to version 1.9 - it requires reboot, and our customer is not happy with that.

I searched in the forum and saw a lot of discussions about the issue. Some complained that it’s possible to link the driver with KMDF statically rather then using the coinstaller, but I didn’t figure how to do that.

Can I get some help with that?

Thanks a lot in advance,
S.

2

Nope. Since the end of the KMDF Beta some years ago, static linking is no longer allowed.

It is one of the most requested features by the community.

Peter
OSR

3

Hi Peter,

Since the end of the KMDF Beta some years ago, static linking is no longer allowed.
That means that I cannot use kmdf 1.9 for static linking. Does that mean that I cannot use kmdf 1.7 or kmdf 1.5? If it doesn’t, how could I do that?

Thanks,
S.

4

You cannot use any released version of kmdf as a static link object. We
asked. Repeatedly. Answer was/is “no”.

Mark Roddy

On Mon, Sep 13, 2010 at 11:13 AM, wrote:

> Hi Peter,
>
> > Since the end of the KMDF Beta some years ago, static linking is no
> longer allowed.
> That means that I cannot use kmdf 1.9 for static linking. Does that mean
> that I cannot use kmdf 1.7 or kmdf 1.5? If it doesn’t, how could I do that?
>
> Thanks,
> S.
>
> —
> 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
>

5

Is there a reason for that, or does “no” mean “because we don’t want to”?

----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”
Sent: Monday, September 13, 2010 10:09:49 AM
Subject: Re: [ntdev] linking kmdf statically

You cannot use any released version of kmdf as a static link object. We asked. Repeatedly. Answer was/is “no”.

Mark Roddy

On Mon, Sep 13, 2010 at 11:13 AM, < skaramush.gm @ gmail.com > wrote:

Hi Peter,

> Since the end of the KMDF Beta some years ago, static linking is no longer allowed.
That means that I cannot use kmdf 1.9 for static linking. Does that mean that I cannot use kmdf 1.7 or kmdf 1.5? If it doesn’t, how could I do that?

Thanks,
S.

—
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

6

The folks responsible for KMDF aren’t merely arbitrary… that, if nothing else, should be clear from reading their numerous replies to this list.

I’ll try to frame the positions as best as I can:

The Microsoft position is that they want to be able to fix any serious framework bugs that might be discovered in the field. This would not be possible of a static-link option were allowed. Their contention is that any driver should be upwardly-compatible across the range of KMDF revisions, within a specific major version.

The position of some members of the the community (including me) is that a static-linking option would be an asset, for a wide-variety of reasons. For example, with a statically-linked driver you’d have the opportunity to build and test your driver with a known, specific, defined, and not-to-be-changed version of the Framework. This would eliminate the risk and variability of rolling KMDF version upgrades.

The KMDF team at Microsoft appear to have heard this request from the community, and they appear to understand our position. Apparently, however, they do not feel that the benefit outweighs the potential cost of their not being able to do Framework upgrades for that subset of drivers that would choose to be statically linked.

They DO have a point, I have to admit. If there was a static linking option, I – personally – can’t think of ANY time I’d choose to dynamically link a commercial KMDF driver.

Peter
OSR

7

+1

I’d add that (IMO) dynamic linking itself presents a ‘better’ target for
attackers. That is, they could choose to target my driver that they’ve
never heard of, or they could target a known dll that impacts lots of
people, just like the case of the crt in user mode, so while it’s true that
you could get security updates via dll, you also (IMO) increase your attack
surface, not that being attacked is really all that big a concern (though
things changing out from under you is, IMO).

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, September 13, 2010 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] linking kmdf statically

The folks responsible for KMDF aren’t merely arbitrary… that, if nothing
else, should be clear from reading their numerous replies to this list.

I’ll try to frame the positions as best as I can:

The Microsoft position is that they want to be able to fix any serious
framework bugs that might be discovered in the field. This would not be
possible of a static-link option were allowed. Their contention is that any
driver should be upwardly-compatible across the range of KMDF revisions,
within a specific major version.

The position of some members of the the community (including me) is that a
static-linking option would be an asset, for a wide-variety of reasons. For
example, with a statically-linked driver you’d have the opportunity to build
and test your driver with a known, specific, defined, and not-to-be-changed
version of the Framework. This would eliminate the risk and variability of
rolling KMDF version upgrades.

The KMDF team at Microsoft appear to have heard this request from the
community, and they appear to understand our position. Apparently, however,
they do not feel that the benefit outweighs the potential cost of their not
being able to do Framework upgrades for that subset of drivers that would
choose to be statically linked.

They DO have a point, I have to admit. If there was a static linking
option, I – personally – can’t think of ANY time I’d choose to dynamically
link a commercial KMDF driver.

Peter
OSR

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

8

And the counterpoint to this is that if this does happen, we can fix WDF in one place at one point in time and address all of these vulnerable drivers in one shot. If you statically linked, each driver would need to be updated.

OP wrote:

That means that I cannot use kmdf 1.9 for static linking. Does that mean that I cannot use kmdf 1.7 or kmdf 1.5? If it doesn’t, how could I do that?

You can use v1.5 or v1.7 but you must use the WDK that shipped with those versions, not the windows 7 WDK.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Monday, September 13, 2010 9:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] linking kmdf statically

+1

I’d add that (IMO) dynamic linking itself presents a ‘better’ target for attackers. That is, they could choose to target my driver that they’ve never heard of, or they could target a known dll that impacts lots of people, just like the case of the crt in user mode, so while it’s true that you could get security updates via dll, you also (IMO) increase your attack surface, not that being attacked is really all that big a concern (though things changing out from under you is, IMO).

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, September 13, 2010 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] linking kmdf statically

The folks responsible for KMDF aren’t merely arbitrary… that, if nothing else, should be clear from reading their numerous replies to this list.

I’ll try to frame the positions as best as I can:

The Microsoft position is that they want to be able to fix any serious framework bugs that might be discovered in the field. This would not be possible of a static-link option were allowed. Their contention is that any driver should be upwardly-compatible across the range of KMDF revisions, within a specific major version.

The position of some members of the the community (including me) is that a static-linking option would be an asset, for a wide-variety of reasons. For example, with a statically-linked driver you’d have the opportunity to build and test your driver with a known, specific, defined, and not-to-be-changed version of the Framework. This would eliminate the risk and variability of rolling KMDF version upgrades.

The KMDF team at Microsoft appear to have heard this request from the community, and they appear to understand our position. Apparently, however, they do not feel that the benefit outweighs the potential cost of their not being able to do Framework upgrades for that subset of drivers that would choose to be statically linked.

They DO have a point, I have to admit. If there was a static linking option, I – personally – can’t think of ANY time I’d choose to dynamically link a commercial KMDF driver.

Peter
OSR

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

9

Getting back the the basic issue…

You have 2 choices, none of them being “statically linking”:

a) Build your driver with the KMDF V1.5 or V1.7 WDK, and specify the KMDF version in your INF file as that version. Redist the co-installer from the older KMDF version. That should let you use whatever the most recent version of KMDF that’s installed on the target machine.

JUST BE SURE TO TEST YOUR DRIVER with all the versions of KMDF that are newer than the version with which you’re shipping. IOW, if your driver’s gonna run on Win7 systems, be sure you test with KMDF V1.9.

b) Your client is going to have to decide to like it. Because that’s the way it is. If you ship with a newer version of KMDF, and there are other drivers on the system that use KMDF, there’ll need to be a reboot to upgrade ALL the drivers on the box to that newer version.

Peter
OSR

10

Only if they linked with the deviant version. If they didn’t, they’d be
fine, running the same code that they tested against when they released it.

Fixing WDF doesn’t mean that any particular 3rd party driver is going to
benefit out of the box, which is what is being assumed when no testing goes
on. If testing DOES go on, we have to do it - which is the way it should be

  • which means that we have to rerelease, which means that we could still
    statically link.

This entire conversation revolves around the premise that MSFT can fix their
code and we’ll be fine, without testing. While the KMDF team’s record is
excellent, most of MSFT’s is not, IMO.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, September 13, 2010 12:55 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] linking kmdf statically

And the counterpoint to this is that if this does happen, we can fix WDF in
one place at one point in time and address all of these vulnerable drivers
in one shot. If you statically linked, each driver would need to be
updated.

OP wrote:

That means that I cannot use kmdf 1.9 for static linking. Does that mean
that I cannot use kmdf 1.7 or kmdf 1.5? If it doesn’t, how could I do that?

You can use v1.5 or v1.7 but you must use the WDK that shipped with those
versions, not the windows 7 WDK.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Monday, September 13, 2010 9:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] linking kmdf statically

+1

I’d add that (IMO) dynamic linking itself presents a ‘better’ target for
attackers. That is, they could choose to target my driver that they’ve
never heard of, or they could target a known dll that impacts lots of
people, just like the case of the crt in user mode, so while it’s true that
you could get security updates via dll, you also (IMO) increase your attack
surface, not that being attacked is really all that big a concern (though
things changing out from under you is, IMO).

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, September 13, 2010 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] linking kmdf statically

The folks responsible for KMDF aren’t merely arbitrary… that, if nothing
else, should be clear from reading their numerous replies to this list.

I’ll try to frame the positions as best as I can:

The Microsoft position is that they want to be able to fix any serious
framework bugs that might be discovered in the field. This would not be
possible of a static-link option were allowed. Their contention is that any
driver should be upwardly-compatible across the range of KMDF revisions,
within a specific major version.

The position of some members of the the community (including me) is that a
static-linking option would be an asset, for a wide-variety of reasons. For
example, with a statically-linked driver you’d have the opportunity to build
and test your driver with a known, specific, defined, and not-to-be-changed
version of the Framework. This would eliminate the risk and variability of
rolling KMDF version upgrades.

The KMDF team at Microsoft appear to have heard this request from the
community, and they appear to understand our position. Apparently, however,
they do not feel that the benefit outweighs the potential cost of their not
being able to do Framework upgrades for that subset of drivers that would
choose to be statically linked.

They DO have a point, I have to admit. If there was a static linking
option, I – personally – can’t think of ANY time I’d choose to dynamically
link a commercial KMDF driver.

Peter
OSR

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

11

Doron,

You can use v1.5 or v1.7 but you must use the WDK that shipped with those
versions, not the windows 7 WDK.
I would be glad to try static linking with 1.7. Could I get any help/instructions how to do that.

Thanks,
S.

12

You can’t - there is no static linking of kmdf.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, September 13, 2010 1:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] linking kmdf statically

Doron,

You can use v1.5 or v1.7 but you must use the WDK that shipped with
those versions, not the windows 7 WDK.
I would be glad to try static linking with 1.7. Could I get any
help/instructions how to do that.

Thanks,
S.

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

13

Additional question: I guess that I cannot pass WHQL based on V1.5 for Vista Client, right? How can I resolve the issue for Vista w/o SP1 installed in that case?

Thanks,
S.

14

WHQL question? I have no idea. None. Zero.

Peter
OSR

15

WHQL testing on Vista client requires SP2.

Hope this helps,
Tim.

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com [xxxxx@gmail.com]
Sent: 13 September 2010 18:58
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] linking kmdf statically

Additional question: I guess that I cannot pass WHQL based on V1.5 for Vista Client, right? How can I resolve the issue for Vista w/o SP1 installed in that case?

Thanks,
S.

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

16

xxxxx@gmail.com wrote:

Additional question: I guess that I cannot pass WHQL based on V1.5 for Vista Client, right? How can I resolve the issue for Vista w/o SP1 installed in that case?

As far as I know, this is not a requirement. What class of device is this?

Vista without SP1 is practically unusable. Is that really a requirement
of your marketing department?

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

17

It seems like there is a WHQL certification requirement to ship only with
the latest KMDF version. The OP might want to verify if this is accurate, as
it might be a show stopper for shipping an older KMDF.

Jan

You have 2 choices, none of them being “statically linking”:

a) Build your driver with the KMDF V1.5 or V1.7 WDK, and specify the KMDF
version in your INF file as that version. Redist the co-installer from
the older
KMDF version. That should let you use whatever the most recent version of
KMDF that’s installed on the target machine.

18

I recall it being a requested future feature of the WDK to allow one to
build a driver (package) with a minimum version requirement that was
‘earlier’ than the most current co-installer and yet have the most current
co-installer be used to update the platform if the minimum version required
was not present.

I hope that this enhancement will eventually surface in a WDK…

Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, September 13, 2010 3:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] linking kmdf statically

It seems like there is a WHQL certification requirement to ship only with
the latest KMDF version. The OP might want to verify if this is accurate, as
it might be a show stopper for shipping an older KMDF.

Jan

You have 2 choices, none of them being “statically linking”:

a) Build your driver with the KMDF V1.5 or V1.7 WDK, and specify the KMDF
version in your INF file as that version. Redist the co-installer from
the older
KMDF version. That should let you use whatever the most recent version of
KMDF that’s installed on the target machine.

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

19

> I searched in the forum and saw a lot of discussions about the issue. Some complained that it’s

possible to link the driver with KMDF statically rather then using the coinstaller, but I didn’t figure how
to do that.

It is not possible.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

20

There is no WHQL requirement to ship only the latest KMDF version. The
requirement is that you can only ship released versions – you can’t ship the
KMDF from a beta WDK.

-------- Original Message --------
Subject: Re: [ntdev] linking kmdf statically
From: Jan Bottorff
To: xxxxx@lists.osr.com
Date: 9/13/2010 2:08 PM

> It seems like there is a WHQL certification requirement to ship only with
> the latest KMDF version. The OP might want to verify if this is accurate, as
> it might be a show stopper for shipping an older KMDF.