DRIVER_LIBRARY and KMDF

NTDEV
1

Hello,

I searched the archives, but could not find an answer to my question.
So here goes.

I have a driverset which is always deployed as a group (for now). These
drivers are all KMDF based, except one, as it is an audio miniport. Now
having read the archives, I understand that having a EXPORT_DRIVER with
KMDF is impossible, and that in general the recommended approach for
sharing code would be a DRIVER_LIBRARY. My driver library has some KMDF
based helper functions, and some WDM based helper functions. This works
fine for my KMDF drivers, but my WDM driver has link errors:

error LNK2001: unresolved external symbol _WdfFunctions
error LNK2001: unresolved external symbol _WdfDriverGlobals

However, when I put in “KMDF_VERSION_MAJOR=1” in my WDM sources’ file,
there are no link errors, but not surprisingly, I am now dependent on
wdfldr.sys:

WDFLDR.SYS
2D01C Import Address Table
350D8 Import Name Table
0 time date stamp
0 Index of first forwarder reference

8 WdfVersionUnbind
7 WdfVersionBindClass
9 WdfVersionUnbindClass
6 WdfVersionBind

It seems that the framework is now calling me in driverentry:

8dda9690 829a9b3a 94b694f8 81e1b000 c000035f
MYDRVNAME!FxDriverEntry+0x7f
[d:\win7beta\minkernel\wdf\framework\kmdf\src\dynamic\stub\stub.cpp @
267]
8dda9874 829cfe6f 00000000 00000000 8dda989c nt!IopLoadDriver+0x7ed
8dda9920 82a0c238 96a5f778 00000001 96a5f764
nt!PipCallDriverAddDeviceQueryRoutine+0x35d
8dda9958 82a0c56a 00000001 8dda9a50 c0000034
nt!RtlpCallQueryRegistryRoutine+0x2cd
8dda99c4 829cf1ab 40000000 80000868 8dda99f8
nt!RtlQueryRegistryValues+0x31d
8dda9aa0 829d6573 007f5008 00000000 8da95140
nt!PipCallDriverAddDevice+0x369
8dda9c9c 829d97e6 8a197a60 8da95140 8dda9cc8
nt!PipProcessDevNodeTree+0x15d
8dda9cd0 8281993f 82977da0 849264c0 829486bc
nt!PiProcessReenumeration+0x74
8dda9cfc 8289d440 00000000 00000000 849264c0
nt!PnpDeviceActionWorker+0x22b
8dda9d4c 82a03aad 00000001 da7380aa 00000000 nt!ExpWorkerThread+0x10d
8dda9d90 8284c535 8289d333 00000001 00000000
nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

Now if within my WDM driver I do not include any WDF include files at
all, nor do I call any KMDF DDIs. What side effects would occur in this
situation with respect to a standard WDM driver which does not depend on
wdfldr? Is it safe? Or is there a better way to share code among these
drivers?

Thank you for any input.

Philip Lukidis

2

Binding to wdfldr and not initializing kmdf should work. The client stub just replaces driverentry() and unload and can handle the situation where the framework is not loaded.

Can you split your driver lib into 2 parts? basically kmdf and wdm pieces and then selectively link agains the right one.

…alternatively you could define the missing symbols in your pure wdm drivers and forgo the kmdf infrastructure entirely. You have to make sure that you never call a kmdf function though b/c it will blow up

hth
d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Philip Lukidis
Sent: Tuesday, January 27, 2009 2:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] DRIVER_LIBRARY and KMDF

Hello,

I searched the archives, but could not find an answer to my question.
So here goes.

I have a driverset which is always deployed as a group (for now). These
drivers are all KMDF based, except one, as it is an audio miniport. Now
having read the archives, I understand that having a EXPORT_DRIVER with
KMDF is impossible, and that in general the recommended approach for
sharing code would be a DRIVER_LIBRARY. My driver library has some KMDF
based helper functions, and some WDM based helper functions. This works
fine for my KMDF drivers, but my WDM driver has link errors:

error LNK2001: unresolved external symbol _WdfFunctions
error LNK2001: unresolved external symbol _WdfDriverGlobals

However, when I put in “KMDF_VERSION_MAJOR=1” in my WDM sources’ file,
there are no link errors, but not surprisingly, I am now dependent on
wdfldr.sys:

WDFLDR.SYS
2D01C Import Address Table
350D8 Import Name Table
0 time date stamp
0 Index of first forwarder reference

8 WdfVersionUnbind
7 WdfVersionBindClass
9 WdfVersionUnbindClass
6 WdfVersionBind

It seems that the framework is now calling me in driverentry:

8dda9690 829a9b3a 94b694f8 81e1b000 c000035f
MYDRVNAME!FxDriverEntry+0x7f
[d:\win7beta\minkernel\wdf\framework\kmdf\src\dynamic\stub\stub.cpp @
267]
8dda9874 829cfe6f 00000000 00000000 8dda989c nt!IopLoadDriver+0x7ed
8dda9920 82a0c238 96a5f778 00000001 96a5f764
nt!PipCallDriverAddDeviceQueryRoutine+0x35d
8dda9958 82a0c56a 00000001 8dda9a50 c0000034
nt!RtlpCallQueryRegistryRoutine+0x2cd
8dda99c4 829cf1ab 40000000 80000868 8dda99f8
nt!RtlQueryRegistryValues+0x31d
8dda9aa0 829d6573 007f5008 00000000 8da95140
nt!PipCallDriverAddDevice+0x369
8dda9c9c 829d97e6 8a197a60 8da95140 8dda9cc8
nt!PipProcessDevNodeTree+0x15d
8dda9cd0 8281993f 82977da0 849264c0 829486bc
nt!PiProcessReenumeration+0x74
8dda9cfc 8289d440 00000000 00000000 849264c0
nt!PnpDeviceActionWorker+0x22b
8dda9d4c 82a03aad 00000001 da7380aa 00000000 nt!ExpWorkerThread+0x10d
8dda9d90 8284c535 8289d333 00000001 00000000
nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

Now if within my WDM driver I do not include any WDF include files at
all, nor do I call any KMDF DDIs. What side effects would occur in this
situation with respect to a standard WDM driver which does not depend on
wdfldr? Is it safe? Or is there a better way to share code among these
drivers?

Thank you for any input.

Philip Lukidis

—
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

3

Thank you for your reply, Doron. I’ll have to check to be sure, but I
do not believe there are any problems with splitting the library code,
so maybe that is safest.