Linking problems: ntdll.lib and FltLib.lib

Dear all.

I'm creating a DLL library for communicating with my kernel space
minifilter driver. The idea is to use a single DLL in an final (user)
code.

I'm experiencing two problems described below.

I would like to implement and expose both filter communication functions
and some Win Native API functions from my DLL using my wrappers.
I'm able to compile and link the minifilter communication code alone.
I'm also able to compile and link native API code alone too. The problem
arrise when I merge the code in a single library and add both
'ntdll.lib' and 'FltLib.lib' libraries to the Addition Dependencies
list. I need to link both files as I use symbols from those libraries.
When I try to create a DLL Debug library as described above, I get the
following error:

MSVCRTD.lib(chkstk.obj) : error LNK2005: __chkstk already defined in
ntdll.lib(ntdll.dll)
MSVCRTD.lib(chkstk.obj) : warning LNK4006: __chkstk already defined in
ntdll.lib(ntdll.dll); second definition ignored
Creating library out/mylib.lib and object out/mylib.exp
out/mylib.dll : fatal error LNK1169: one or more multiply defined
symbols found

The second problem arrise when I try to build a release build. When
doing so, I get the following error:

myfile_native.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) unsigned short const private: static unsigned short const \* __cdecl std::basic_string<unsigned short>std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt;::_Nullstr(void)'::2'::_C"
( imp?C@?1??Nullstr@?$basic_string@GU?$xxxxx@xxxxx@std@@V?$allocat
or@G@2@@std@@xxxxx@4GB
<mailto:
imp
>allocator@G@2@@std@@xxxxx@4GB> )
myfile_flt.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) unsigned short const private: static unsigned<br>short const *__cdecl std::basic_string<unsigned short>std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt;::_Nullstr(void)'::2'::_C"
( imp?C@?1??Nullstr@?$basic_string@GU?$xxxxx@xxxxx@std@@V?$allocat
or@G@2@@std@@xxxxx@4GB
<mailto:
imp
>allocator@G@2@@std@@xxxxx@4GB> )
out/mylib.dll : fatal error LNK1120: 1 unresolved externals
----

Please give me advices how to fix the problem.

Thanks and best regards,
Dezo
_______________________
Damir Dezeljin</mailto:
imp
></mailto:_imp>

>I would like to implement and expose both filter communication functions

and some Win Native API functions from my DLL using my wrappers.

What is the need in Native API in such a DLL? IIRC CreateFile and
DeviceIoControl are not native API calls, and they are nearly all you need.

The ability of using STL in native apps is doubtful, I have major doubts NTDLL
has STL support in it, and MSVCRT cannot be used in native apps.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Hi.

What is the need in Native API in such a DLL? IIRC CreateFile and
DeviceIoControl are not native API calls, and they are nearly all
you need.
Well ... I need some Native API functionality that isn't available in
Win32 API. Those functionality is not directly related to the filter
driver I'm working on. However I would like to create a single C++ DLL
API file I can use in higher program layers.

I get rid of the __chkstk problem by making a dummy ntdll.dll as
described by Gabriel:

browse_thread/thread/a4a18b473b804649/430fd1d1de1b6ac2?lnk=st&rnum=1&hl=
en#msg_337cba5af1ed31c4

Unfortunately I still have problems making a release build. A Debug
build finish without any warning / error (VS.NET 2003 Warning Level 3),
however the link step of the Release build outputs the following error:

MyFilter.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) unsigned short const private: static unsigned short const \* __cdecl std::basic_string<unsigned short>std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt;::_Nullstr(void)'::2'::_C"
(_imp?_C@?1??_Nullstr@?$basic_string@GU?$xxxxx@xxxxx@std@@V?$allocat
or@G@2@@std@@xxxxx@4GB)
MyObject.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) unsigned short const private: static unsigned<br>short const * __cdecl std::basic_string<unsigned short>std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt;::_Nullstr(void)'::2'::_C"
(_imp?_C@?1??_Nullstr@?$basic_string@GU?$xxxxx@xxxxx@std@@V?$allocat
or@G@2@@std@@xxxxx@4GB)
MyScan.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) unsigned short const private: static unsigned<br>short const *__cdecl std::basic_string<unsigned short>std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt;::_Nullstr(void)'::2'::_C"
(_imp?_C@?1??_Nullstr@?$basic_string@GU?$xxxxx@xxxxx@std@@V?$allocat
or@G@2@@std@@xxxxx@4GB)
out/myHsmlib.dll : fatal error LNK1120: 1 unresolved externals
----

I don't have a clue what the above problem is even if I already sent lot
of hours looking into it.

Best regards,
Dezo

Damir Dezeljin wrote:

Unfortunately I still have problems making a release build. A Debug
build finish without any warning / error (VS.NET 2003 Warning Level 3),
however the link step of the Release build outputs the following error:

MyFilter.obj : error LNK2001: unresolved external symbol
“__declspec(dllimport) unsigned short const private: static unsigned short const \* __cdecl std::basic_string<unsigned short>&gt;std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt; <br>&gt;<br>&gt;&gt;::_Nullstr(void)'::2’::_C”
>>
>>

You’re seeing problems caused by mixing include files from different
compiler generations. The version of STL in the DDK, which is actually
an antique relic copied from Visual Studio 98 (!), makes reference to a
global object called _Nullstr(). In VS98, this is provided by one of
the run-time library DLLs.

The version of STL in VS2003 and VS2005 no longer use this global
object, so the run-time library DLLs do not provide it.

None of your courses of action are particularly pleasing. You can copy
pieces of the VS2005 STL into the DDK directory. You can delete the DDK
STL files altogether and fall back to the compiler. Or you can
eliminate the use of STL.

It’s too bad this hasn’t received more attention. The VS2005 STL has a
#define which disables the use of exceptions. By copying one include
file from VS98 (xstddef), I was able to build a kernel driver using STL
that actually loads and runs. Now I understand that the location of
generated template code is not deterministic, so I would not release
this to a client, but the productivity of the tried and tested STL
containers and algorithms is too great to ignore.


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

The WDK has the latest STL IIRC

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, June 26, 2006 9:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Linking problems: ntdll.lib and FltLib.lib

Damir Dezeljin wrote:

Unfortunately I still have problems making a release build. A Debug
build finish without any warning / error (VS.NET 2003 Warning Level 3),

however the link step of the Release build outputs the following error:

MyFilter.obj : error LNK2001: unresolved external symbol
“__declspec(dllimport) unsigned short const private: static unsigned short const \* __cdecl std::basic_string<unsigned short>&gt;std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt; <br>&gt;<br>&gt;&gt;::_Nullstr(void)'::2’::_C”
>>
>>

You’re seeing problems caused by mixing include files from different
compiler generations. The version of STL in the DDK, which is actually
an antique relic copied from Visual Studio 98 (!), makes reference to a
global object called _Nullstr(). In VS98, this is provided by one of
the run-time library DLLs.

The version of STL in VS2003 and VS2005 no longer use this global
object, so the run-time library DLLs do not provide it.

None of your courses of action are particularly pleasing. You can copy
pieces of the VS2005 STL into the DDK directory. You can delete the DDK
STL files altogether and fall back to the compiler. Or you can
eliminate the use of STL.

It’s too bad this hasn’t received more attention. The VS2005 STL has a
#define which disables the use of exceptions. By copying one include
file from VS98 (xstddef), I was able to build a kernel driver using STL
that actually loads and runs. Now I understand that the location of
generated template code is not deterministic, so I would not release
this to a client, but the productivity of the tried and tested STL
containers and algorithms is too great to ignore.


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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Doron Holan wrote:

The WDK has the latest STL IIRC

It is certainly much newer, although it doesn’t actually match either
VS2003 or VS2005. It appears to be the VS2003 version with some of the
CLR hacks included.

In any case, it no longer requires _Nullstr().


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

DAMIR/TIM:

For whatever it is worth, I’ve done the same (use VS2005 STL in kernel)
and have had the same results, with the same caveats.

MM

>> xxxxx@probo.com 2006-06-26 12:54 >>>
Damir Dezeljin wrote:

Unfortunately I still have problems making a release build. A Debug
build finish without any warning / error (VS.NET 2003 Warning Level
3),
however the link step of the Release build outputs the following
error:

MyFilter.obj : error LNK2001: unresolved external symbol
“__declspec(dllimport) unsigned short const private: static unsigned short const \* __cdecl std::basic_string<unsigned short>&gt;std::char_traits<unsigned short>,class std::allocator<unsigned short><br>&gt; <br>&gt;<br>&gt;&gt;::_Nullstr(void)'::2’::_C”
>>
>>

You’re seeing problems caused by mixing include files from different
compiler generations. The version of STL in the DDK, which is
actually
an antique relic copied from Visual Studio 98 (!), makes reference to
a
global object called _Nullstr(). In VS98, this is provided by one of
the run-time library DLLs.

The version of STL in VS2003 and VS2005 no longer use this global
object, so the run-time library DLLs do not provide it.

None of your courses of action are particularly pleasing. You can
copy
pieces of the VS2005 STL into the DDK directory. You can delete the
DDK
STL files altogether and fall back to the compiler. Or you can
eliminate the use of STL.

It’s too bad this hasn’t received more attention. The VS2005 STL has
a
#define which disables the use of exceptions. By copying one include
file from VS98 (xstddef), I was able to build a kernel driver using
STL
that actually loads and runs. Now I understand that the location of
generated template code is not deterministic, so I would not release
this to a client, but the productivity of the tried and tested STL
containers and algorithms is too great to ignore.


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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Hi.

I solved the problem by moving the DDK and Win Native API code to a
separate static library project where I don’t use the STL. Afterwards
I’m using / linking against the mentioned project.

Thanks for your help and best regards,
Dezo