Driver Export Function Problem

[jeff_jiang]

If I want to export Funciton , must I compile the source code (include export Funcitons) with driver together at the same time? Can I compile them separately?

For example,The functions need exported is in “api.c” in directory “API” and the driver is in “driver.c” in directory “driver”:

-------API
| api.c
|
|------Driver
driver.c
Can I compile the “api.c” as DRIVER_LIBRARY to generat “api.lib” first, then compile the driver as “EXPORT_DRIVER” to generat “driver.lib” with “api.lib”? My test was failed.

[anshul_makkar-3]

I believe separate compilation should work…

On Wed, May 12, 2010 at 11:48 AM, wrote:

> If I want to export Funciton , must I compile the source code (include
> export Funcitons) with driver together at the same time? Can I compile them
> separately?
>
> For example,The functions need exported is in “api.c” in directory “API”
> and the driver is in “driver.c” in directory “driver”:
>
> -------API
> | api.c
> |
> |------Driver
> driver.c
> Can I compile the “api.c” as DRIVER_LIBRARY to generat “api.lib” first,
> then compile the driver as “EXPORT_DRIVER” to generat “driver.lib” with
> “api.lib”? My test was failed.
>
>
> —
> 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
>

–
Thanks
Anshul Makkar
www.justkernel.com
xxxxx@justkernel.com

[Doron_Holan]

Show us the sources file for the Driver directory. What failed? Failure to link? Failure to list the export in the EAT?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com.cn
Sent: Tuesday, May 11, 2010 11:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Export Function Problem

If I want to export Funciton , must I compile the source code (include export Funcitons) with driver together at the same time? Can I compile them separately?

For example,The functions need exported is in “api.c” in directory “API” and the driver is in “driver.c” in directory “driver”:

-------API
| api.c
|
|------Driver
driver.c
Can I compile the “api.c” as DRIVER_LIBRARY to generat “api.lib” first, then compile the driver as “EXPORT_DRIVER” to generat “driver.lib” with “api.lib”? My test was failed.

---

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

[jeff_jiang]

The error is if another driver call the export function will failed,the informations as blow:

f:\code\dre_ex_raw_asyn_cmp_km.obj : error LNK2019: unresolved external symbol xxxxx@0 referenced in function _DRE_rawAsynCmp@0

The export function in ‘api.c’:
/****************************************************************/
__declspec(dllexport)
int function_test(void)
{
…
}
/****************************************************************/

The source for api.c:

/****************************************************************/
TARGETNAME=api
TARGETTYPE=DRIVER_LIBRARY
TARGETPATH=…....\lib$(BUILD_ALT_DIR)

KMDF_VERSION_MAJOR=1

NTTARGETFILES=

TARGETLIBS=$(TARGETLIBS) \
$(DDK_LIB_PATH)\ntstrsafe.lib

INCLUDES=$(INCLUDES);…....\h;

C_DEFINES = $(C_DEFINES)

SOURCES=api.c

Generate WPP tracing code

$(SOURCES) – run software preprocessor on files listed in SOURCES

-km – use kernel mode

-func – define function we’ll use for tracing

This would map all TraceEvents calls to

DoTraceMessage.

RUN_WPP= $(SOURCES) \
-km \
-func:TraceEvents(LEVEL,FLAGS,MSG,…) \
-gen:{km-WdfDefault.tpl}*.tmh

TARGET_DESTINATION=wdf

Temporarily excuse usage of serviceability impairing macros in code…

ALLOW_DATE_TIME=1
/****************************************************************/

The source for driver.c:
/****************************************************************/
TARGETNAME=dre_panther_ctrl
TARGETTYPE=EXPORT_DRIVER
TARGETPATH=…..\drivers_bin$(BUILD_ALT_DIR)

KMDF_VERSION_MAJOR=1

INF_NAME=dre_panther_ctrl
NTTARGETFILE0=$(OBJ_PATH)$(O)$(INF_NAME).inf
PASS0_BINPLACE=$(NTTARGETFILE0)

TARGETLIBS=$(TARGETLIBS) \
$(DDK_LIB_PATH)\ntstrsafe.lib \
…..\lib$(BUILD_ALT_DIR)*\api.lib \

INCLUDES=$(INCLUDES);

C_DEFINES = $(C_DEFINES)

SOURCES=driver.c

DLLDEF=driver.def

Generate WPP tracing code

$(SOURCES) – run software preprocessor on files listed in SOURCES

-km – use kernel mode

-func – define function we’ll use for tracing

This would map all TraceEvents calls to

DoTraceMessage.

RUN_WPP= $(SOURCES) \
-km \
-func:TraceEvents(LEVEL,FLAGS,MSG,…) \
-gen:{km-WdfDefault.tpl}*.tmh

TARGET_DESTINATION=wdf

Temporarily excuse usage of serviceability impairing macros in code…

ALLOW_DATE_TIME=1
/****************************************************************/

The driver.def:
/****************************************************************/
NAME driver.sys

EXPORTS
DllInitialize PRIVATE
DllUnload PRIVATE
function_test
/****************************************************************/

[Doron_Holan]

>KMDF_VERSION_MAJOR=1
You cannot create a KMDF based export driver, drop this line

TARGETLIBS=$(TARGETLIBS) \
$(DDK_LIB_PATH)\ntstrsafe.lib \
…..\lib$(BUILD_ALT_DIR)*\api.lib \

Instead I would have $(OBJ_PATH)....\LIB$(O)\API.LIB. are you sure…..\lib$(BUILD_ALT_DIR)*\api.lib resolves to what you want and actually contains the export?

__declspec(dllexport)
You don’t need this since you have a .def file

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com.cn
Sent: Wednesday, May 12, 2010 12:45 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver Export Function Problem

The error is if another driver call the export function will failed,the informations as blow:

f:\code\dre_ex_raw_asyn_cmp_km.obj : error LNK2019: unresolved external symbol xxxxx@0 referenced in function _DRE_rawAsynCmp@0

The export function in ‘api.c’:
/****************************************************************/
__declspec(dllexport)
int function_test(void)
{
…
}
/****************************************************************/

The source for api.c:

/****************************************************************/
TARGETNAME=api
TARGETTYPE=DRIVER_LIBRARY
TARGETPATH=…....\lib$(BUILD_ALT_DIR)

KMDF_VERSION_MAJOR=1

NTTARGETFILES=

TARGETLIBS=$(TARGETLIBS) \
$(DDK_LIB_PATH)\ntstrsafe.lib

INCLUDES=$(INCLUDES);…....\h;

C_DEFINES = $(C_DEFINES)

SOURCES=api.c

Generate WPP tracing code

$(SOURCES) – run software preprocessor on files listed in SOURCES

-km – use kernel mode

-func – define function we’ll use for tracing

This would map all TraceEvents calls to

DoTraceMessage.

RUN_WPP= $(SOURCES) \
-km \
-func:TraceEvents(LEVEL,FLAGS,MSG,…) \
-gen:{km-WdfDefault.tpl}*.tmh

TARGET_DESTINATION=wdf

Temporarily excuse usage of serviceability impairing macros in code…

ALLOW_DATE_TIME=1
/****************************************************************/

The source for driver.c:
/****************************************************************/
TARGETNAME=dre_panther_ctrl
TARGETTYPE=EXPORT_DRIVER
TARGETPATH=…..\drivers_bin$(BUILD_ALT_DIR)

KMDF_VERSION_MAJOR=1

INF_NAME=dre_panther_ctrl
NTTARGETFILE0=$(OBJ_PATH)$(O)$(INF_NAME).inf
PASS0_BINPLACE=$(NTTARGETFILE0)

TARGETLIBS=$(TARGETLIBS) \
$(DDK_LIB_PATH)\ntstrsafe.lib \
…..\lib$(BUILD_ALT_DIR)*\api.lib \

INCLUDES=$(INCLUDES);

C_DEFINES = $(C_DEFINES)

SOURCES=driver.c

DLLDEF=driver.def

Generate WPP tracing code

$(SOURCES) – run software preprocessor on files listed in SOURCES

-km – use kernel mode

-func – define function we’ll use for tracing

This would map all TraceEvents calls to

DoTraceMessage.

RUN_WPP= $(SOURCES) \
-km \
-func:TraceEvents(LEVEL,FLAGS,MSG,…) \
-gen:{km-WdfDefault.tpl}*.tmh

TARGET_DESTINATION=wdf

Temporarily excuse usage of serviceability impairing macros in code…

ALLOW_DATE_TIME=1
/****************************************************************/

The driver.def:
/****************************************************************/
NAME driver.sys

EXPORTS
DllInitialize PRIVATE
DllUnload PRIVATE
function_test
/****************************************************************/

---

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

[Pavel_A1]

wrote in message news:xxxxx@ntdev…
> The error is if another driver call the export function will failed,the
> informations as blow:
>
> f:\code\dre_ex_raw_asyn_cmp_km.obj : error LNK2019: unresolved external
> symbol xxxxx@0 referenced in function _DRE_rawAsynCmp@0

Have you the provided the .lib file of your driver, when linking the other
driver?
–pa

> The export function in ‘api.c’:
> //
> __declspec(dllexport)
> int function_test(void)
> {
> …
> }
> //
>
>
>
>
>
> The source for api.c:
>
> //
> TARGETNAME=api
> TARGETTYPE=DRIVER_LIBRARY
> TARGETPATH=…....\lib$(BUILD_ALT_DIR)
>
>
> KMDF_VERSION_MAJOR=1
>
>
> NTTARGETFILES=
>
> TARGETLIBS=$(TARGETLIBS) <br>> $(DDK_LIB_PATH)\ntstrsafe.lib
>
> INCLUDES=$(INCLUDES);…....\h;
>
>
> C_DEFINES = $(C_DEFINES)
>
> SOURCES=api.c
>
> #
> # Generate WPP tracing code
> # $(SOURCES) – run software preprocessor on files listed in SOURCES
> # -km – use kernel mode
> # -func – define function we’ll use for tracing
> # This would map all TraceEvents calls to
> # DoTraceMessage.
> #
> RUN_WPP= $(SOURCES) <br>> -km <br>> -func:TraceEvents(LEVEL,FLAGS,MSG,…) <br>> -gen:{km-WdfDefault.tpl}.tmh
>
> TARGET_DESTINATION=wdf
>
> # Temporarily excuse usage of serviceability impairing macros in code…
> ALLOW_DATE_TIME=1
> //
>
>
>
>
>
>
> The source for driver.c:
> //
> TARGETNAME=dre_panther_ctrl
> TARGETTYPE=EXPORT_DRIVER
> TARGETPATH=…..\drivers_bin$(BUILD_ALT_DIR)
>
>
> KMDF_VERSION_MAJOR=1
>
> INF_NAME=dre_panther_ctrl
> NTTARGETFILE0=$(OBJ_PATH)$(O)$(INF_NAME).inf
> PASS0_BINPLACE=$(NTTARGETFILE0)
>
> TARGETLIBS=$(TARGETLIBS) <br>> $(DDK_LIB_PATH)\ntstrsafe.lib <br>> …..\lib$(BUILD_ALT_DIR)*\api.lib <br>>
>
> INCLUDES=$(INCLUDES);
>
>
>
> C_DEFINES = $(C_DEFINES)
>
> SOURCES=driver.c
>
> DLLDEF=driver.def
>
> #
> # Generate WPP tracing code
> # $(SOURCES) – run software preprocessor on files listed in SOURCES
> # -km – use kernel mode
> # -func – define function we’ll use for tracing
> # This would map all TraceEvents calls to
> # DoTraceMessage.
> #
> RUN_WPP= $(SOURCES) <br>> -km <br>> -func:TraceEvents(LEVEL,FLAGS,MSG,…) <br>> -gen:{km-WdfDefault.tpl}.tmh
>
> TARGET_DESTINATION=wdf
>
> # Temporarily excuse usage of serviceability impairing macros in code…
> ALLOW_DATE_TIME=1
> /**/
>
>
>
> The driver.def:
> / /
> NAME driver.sys
>
> EXPORTS
> DllInitialize PRIVATE
> DllUnload PRIVATE
> function_test
> / /
>

[jeff_jiang]

Hi,Pavel A
I have provided the driver.lib file to other driver.

The other driver calling the export function was failed if I did separate compilation with driver.c and api.c;

But if I compile the driver.c and api.c at the same time, the export function will be used well by other driver

[Tim_Roberts]

xxxxx@yahoo.com.cn wrote:

The error is if another driver call the export function will failed,the informations as blow:

f:\code\dre_ex_raw_asyn_cmp_km.obj : error LNK2019: unresolved external symbol xxxxx@0 referenced in function _DRE_rawAsynCmp@0

…
The driver.def:
/****************************************************************/
NAME driver.sys

EXPORTS
DllInitialize PRIVATE
DllUnload PRIVATE
function_test
/****************************************************************/

That should go in api.def, not driver.def. Driver.sys is the CONSUMER
of the interface, not the PRODUCER. It is the PRODUCER that has to
declare what it exports.

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

[OSR_Community_User]

5 years later…

Thanks for your “DLLs in Kernel Mode” article, Tim Roberts.

I am experiencing the same issue as the original poster. I have a DRIVER_LIBRARY which will be linked into an EXPORT_DRIVER, and I wish to export functions found in the DRIVER_LIBRARY. It would seem that with WINDDK 6001.18001, an EXPORTS in the .DEF file makes no difference for a DRIVER_LIBRARY, as evidenced by

dumpbin /exports foo.lib

I’d really appreciate any assistance.

[Tim_Roberts]

xxxxx@YRDSB.Edu.On.Ca wrote:

5 years later…

Thanks for your “DLLs in Kernel Mode” article, Tim Roberts.

I am experiencing the same issue as the original poster. I have a DRIVER_LIBRARY which will be linked into an EXPORT_DRIVER, and I wish to export functions found in the DRIVER_LIBRARY. It would seem that with WINDDK 6001.18001, an EXPORTS in the .DEF file makes no difference for a DRIVER_LIBRARY, as evidenced by

dumpbin /exports foo.lib

I’d really appreciate any assistance.

Correct. A DRIVER_LIBRARY is a statically linked library. Exports are
only used in dynamic linking. You need the .DEF file in the project
that builds the EXPORT_DRIVER. If that’s what you are doing, then you
need to do “dumpbin /exports foo.dll”, not “foo.lib”.

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

[OSR_Community_User]

Thanks, Tim. It seems that you’re telling me that if I have:

A: DRIVER
B: EXPORT_DRIVER
C: DRIVER_LIBRARY providing foo()

that I cannot link the object code from C into B and export it in
.DLL-fashion to A.

It’s fine for me to export from wherever it needs to be exported from,
but I’m getting the sense that it’s a limitation of the common build.exe
process. For example, I have tried several different combinations…
I’ve tried putting the EXPORTS in B, but get unresolved references
reported, even though B does get C linked in.

In summary, it seems to me that one cannot export a function from an
EXPORT_DRIVER, where the function originates from a static library
that’s linked into the EXPORT_DRIVER.

Has this really not been encountered that often by folks? I have a
directory structure in which I’d like to produce static .LIBs for each
of the product features, then link them all together into an
EXPORT_DRIVER which exports some of the functions to a dependent driver.

• Shao Miller

[Tim_Roberts]

Miller, Shao wrote:

Thanks, Tim. It seems that you’re telling me that if I have:

A: DRIVER
B: EXPORT_DRIVER
C: DRIVER_LIBRARY providing foo()

that I cannot link the object code from C into B and export it in
.DLL-fashion to A.

Not at all. You’d build C, then build B linking with the library from
C. B has the .DEF file with the exports.

It’s fine for me to export from wherever it needs to be exported from,
but I’m getting the sense that it’s a limitation of the common build.exe
process. For example, I have tried several different combinations…
I’ve tried putting the EXPORTS in B, but get unresolved references
reported, even though B does get C linked in.

Hmm. Can you see in the /MAP that the specific entry points you want to
export are being loaded from C? There are linker options to force a
particular entry point to be loaded (/INCLUDE), although just referring
to them from B (even if not called) should be enough.

Has this really not been encountered that often by folks? I have a
directory structure in which I’d like to produce static .LIBs for each
of the product features, then link them all together into an
EXPORT_DRIVER which exports some of the functions to a dependent driver.

EXPORT_DRIVERs are very rare. Many people use static libs as you
describe and then build up a normal driver, but I don’t know about your
specific question. I’ll have to set up a test case.

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

[OSR_Community_User]

For the record, the combinations I have tried include at least the
following two:

Scenario #1:

A:
sources
TARGETTYPE=DRIVER
TARGETLIBS=path\b.lib

B:
sources
TARGETTYPE=EXPORT_DRIVER
TARGETLIBS=path\feature1.lib path\feature2.lib
b.def
EXPORTS
c_foo

C:
sources
TARGETTYPE=DRIVER_LIBRARY
c.def
(empty)

and Scenario #2:

A:
sources
TARGETTYPE=DRIVER
TARGETLIBS=path\b.lib

B:
sources
TARGETTYPE=EXPORT_DRIVER
TARGETLIBS=path\feature1.lib path\feature2.lib
b.def
(empty)

C:
sources
TARGETTYPE=DRIVER_LIBRARY
c.def
EXPORTS
c_foo

In scenario #1, building C yields: error LNK2001: unresolved external
symbol c_foo. In scenario #2, building C is successful, but

dumpbin /exports b.lib

yields no exports (as might be expected for a static library), and

dumpbin /exports c.lib

does not yield c_foo.

I will find out about the /MAP business you’ve suggested. Thanks again.

• Shao Miller

[OSR_Community_User]

With apologies, I made an error in the previous e-mail’s details.
Instead of:

In scenario #1, building C yields: error LNK2001: unresolved external
symbol c_foo. In scenario #2, building C is successful, but

I instead meant:

In scenario #1, building B yields: error LNK2001: unresolved external
symbol c_foo. In scenario #2, building B is successful, but

• Shao Miller

[Doron_Holan]

Libs do not have exports (there is no EAT), PE binaries have exports. Have you tried running dumpbin on the resulting DLL/sys?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Miller, Shao
Sent: Monday, May 17, 2010 12:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Driver Export Function Problem

With apologies, I made an error in the previous e-mail’s details.
Instead of:

In scenario #1, building C yields: error LNK2001: unresolved external symbol c_foo. In scenario #2, building C is successful, but

I instead meant:

In scenario #1, building B yields: error LNK2001: unresolved external symbol c_foo. In scenario #2, building B is successful, but

• Shao Miller

---

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

[OSR_Community_User]

For the EXPORT_DRIVER (B), both

dumpbin /exports b.lib
dumpbin /exports b.sys

show exports that are native to the .c files for the EXPORT_DRIVER (B).
Those exports do not contain functions which were linked in from the
DRIVER_LIBRARY (C).

For the DRIVER_LIBRARY (C), there is no .SYS file. It is a static lib,
as you mention. I can link c_foo() into the EXPORT_DRIVER, that driver
even calls c_foo(), but I can’t figure out how to then export c_foo() to
a dependent driver (A).

Another error in a previous e-mail neglected to describe that C is a
“feature” library and was one of the TARGETLIBS for the EXPORT_DRIVER
(B).

Thanks, Doron.

• Shao Miller

[Doron_Holan]

I don’t know what you are doing wrong, this works if setup properly. This is how we build KMDF for instance

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Miller, Shao
Sent: Monday, May 17, 2010 1:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Driver Export Function Problem

For the EXPORT_DRIVER (B), both

dumpbin /exports b.lib
dumpbin /exports b.sys

show exports that are native to the .c files for the EXPORT_DRIVER (B).
Those exports do not contain functions which were linked in from the DRIVER_LIBRARY (C).

For the DRIVER_LIBRARY (C), there is no .SYS file. It is a static lib, as you mention. I can link c_foo() into the EXPORT_DRIVER, that driver even calls c_foo(), but I can’t figure out how to then export c_foo() to a dependent driver (A).

Another error in a previous e-mail neglected to describe that C is a “feature” library and was one of the TARGETLIBS for the EXPORT_DRIVER (B).

Thanks, Doron.

• Shao Miller

---

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

[OSR_Community_User]

So Doron, you assemble a bunch of static libs together and .DLL-export
functions found in those static libs from the assembled EXPORT_DRIVER?
If so, where are your exports defined as exports? In the assembly’s
.DEF file or in the .DEF file for each static lib (which I would not
expect, but am unsure of, since neither are working for me). - Shao

[Doron_Holan]

Static libs do not have def files (and if they did, they are useless). The sources file which links together all of the libs and creates the export sys file has the def file

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Miller, Shao
Sent: Monday, May 17, 2010 1:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Driver Export Function Problem

So Doron, you assemble a bunch of static libs together and .DLL-export functions found in those static libs from the assembled EXPORT_DRIVER?
If so, where are your exports defined as exports? In the assembly’s .DEF file or in the .DEF file for each static lib (which I would not expect, but am unsure of, since neither are working for me). - Shao

---

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

[OSR_Community_User]

Doron: Agreed. .DEFs would not make much sense to me for static libs.
I had to try it out, though, since it’s not working.

I’ve just consulted the .log files (a little late) and I see that the
linker’s pass 1 uses the EXPORT_DRIVER (B)'s .DEF file, whereas the
static .LIBs (various DRIVER_LIBRARY product “features”) are linked in
pass 2. Thus the EXPORTS in the .DEF are too soon for pass 1 to
succeed. While this explains the behaviour, does anyone know of a
work-around short of wrapping every function I’d like to export from the
static .LIBs?

• Shao Miller