Hi there,
i have downloaded the beta version of Visual C++ .NET 8 and i am trying
to compile my driver.
I have imported *.dsw converted it in *.sln.
I get many linker errors.
error LNK2019: unresolved external symbol ___security_cookie referenced
in function “long __stdcall AddDevice(struct _DRIVER_OBJECT *,struct
_DEVICE_OBJECT *)” (?AddDevice@@YGJPAU_DRIVER_OBJECT@@PAU_DEVICE_OBJECT@@@Z)
Any ideas?
Well I don’t have much idea about the new .NET stuff, but I think this is
related to .NET security check code.
Try with Configuration Properties => C/C++ => Code Generation => Buffer
Security Check turned off
No idea though why this yields these linker errors. And no idea why enabling
this option doesn’t give these linker errors during a release build.
This also occurs when building a project in VC6 and linking to a library
built in VC7 with the Buffer Security Check turned on for the VC7 library.
This occurs in the release build (the only one I checked). It would
presummably also cause a linker error on the symbols ___security_cookie and
@xxxxx@4 in debug as well.
Bottom line: the only compiler you should be building a driver with is the
one from the DDK! Don’t try to use this approach you are just creating
crap.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Nikolas Stylianides” wrote in message news:xxxxx@ntdev…
> Hi there,
> i have downloaded the beta version of Visual C++ .NET 8 and i am trying to
> compile my driver.
> I have imported *.dsw converted it in *.sln.
> I get many linker errors.
>
> error LNK2019: unresolved external symbol _security_cookie referenced in
> function "long stdcall AddDevice(struct _DRIVER_OBJECT *,struct
> _DEVICE_OBJECT *)"
> (?AddDevice@@YGJPAU_DRIVER_OBJECT@@PAU_DEVICE_OBJECT@@@Z)
>
> Any ideas?
>
>
>
Don Burn wrote:
Bottom line: the only compiler you should be building a driver with is the
one from the DDK! Don’t try to use this approach you are just creating
crap.
when i use the build tool that comes along with the DDK i cannot compile
*.cpp files.
i created a project in VC++ 6.0 which was able to build a driver that works.
So i imagined that importing that in .NET should work just fine.
I know that the compiler i am using is cl.exe instead of build.exe.
How can i build drivers with C++ support?
what can i do?
The DDK will compile C++ perfectly fine, you have sometning wrong with your
environment. First are you using the latest DDK? Second did you either run
setenv.bat or use on the build environments setup on the start menu. Third,
does you environment build one the samples from the DDK correctly?
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Nikolas Stylianides” wrote in message news:xxxxx@ntdev…
> Don Burn wrote:
>
>>Bottom line: the only compiler you should be building a driver with is the
>>one from the DDK! Don’t try to use this approach you are just creating
>>crap.
>>
>>
>>
> when i use the build tool that comes along with the DDK i cannot compile
> *.cpp files.
> i created a project in VC++ 6.0 which was able to build a driver that
> works.
> So i imagined that importing that in .NET should work just fine.
>
> I know that the compiler i am using is cl.exe instead of build.exe.
> How can i build drivers with C++ support?
> what can i do?
>
>
Don Burn wrote:
The DDK will compile C++ perfectly fine, you have sometning wrong with your
environment. First are you using the latest DDK? Second did you either run
setenv.bat or use on the build environments setup on the start menu. Third,
does you environment build one the samples from the DDK correctly?
My build version is 4.03.2134
Yes it builds the some of the src’s
I think that the problem is with my SOURCES file.
Any idea where i can find a sample?
Use one of the many samples from the DDK, or post you sources file here for
comment.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Nikolas Stylianides” wrote in message news:xxxxx@ntdev…
> Don Burn wrote:
>
>>The DDK will compile C++ perfectly fine, you have sometning wrong with
>>your environment. First are you using the latest DDK? Second did you
>>either run setenv.bat or use on the build environments setup on the start
>>menu. Third, does you environment build one the samples from the DDK
>>correctly?
>>
>>
>>
> My build version is 4.03.2134
> Yes it builds the some of the src’s
> I think that the problem is with my SOURCES file.
> Any idea where i can find a sample?
>
>
Don Burn wrote:
Use one of the many samples from the DDK, or post you sources file here for
comment.
TARGETNAME=atm4plus
TARGETTYPE=DRIVER
TARGETPATH=obj
DRIVERTYPE=WDM
TARGETLIBS=$(BASEDIR)\libchk\i386\int64.lib
$(BASEDIR)\libchk\i386\hal.lib $(BASEDIR)\libchk\i386\ntoskrnl.lib
C_DEFINES= -DONLYONCE=extern -D_WDMDRIVER -Dnologo -D_WIN32_WINNT=0x500
USE_PDB=1
SOURCES=atm4plus.cpp\
mydbgprint.cpp\
unicode.cpp\
eventlog.cpp\
dispatchPNPhandling.cpp\
dispatchio.cpp\
ufilehandle.cpp\
channelclass.cpp\
eventlog.cpp\
MDeviceExtension.cpp\
marbiterclass.cpp\
isrhandling.cpp
MSC_WARNING_LEVEL=/WX /W3
I386_WARNING_LEVEL=/WX /W3
LINKER_FLAGS= -base:“0x10000” -entry:“DriverEntry”
Compiled but not linked.
link() : error LNK2001: unresolved external symbol _DriverEntry@8
atm4plus.obj() : error LNK2001: unresolved external symbol “void __cdecl
operator delete(void *)” (??xxxxx@YAXPAX@Z)
dispatchpnphandling.obj() : error LNK2001: unresolved external symbol
“void __cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
ufilehandle.obj() : error LNK2001: unresolved external symbol “void
__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
objchk\i386\atm4plus.sys() : error LNK1120: 2 unresolved externals
Thanks.
Are you using extern “C” on driver entry? This is required.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Nikolas Stylianides” wrote in message news:xxxxx@ntdev…
> Don Burn wrote:
>
>>Use one of the many samples from the DDK, or post you sources file here
>>for comment.
>>
>>
>>
> TARGETNAME=atm4plus
> TARGETTYPE=DRIVER
> TARGETPATH=obj
> DRIVERTYPE=WDM
> TARGETLIBS=$(BASEDIR)\libchk\i386\int64.lib $(BASEDIR)\libchk\i386\hal.lib
> $(BASEDIR)\libchk\i386\ntoskrnl.lib
>
> C_DEFINES= -DONLYONCE=extern -D_WDMDRIVER -Dnologo -D_WIN32_WINNT=0x500
>
> USE_PDB=1
>
> SOURCES=atm4plus.cpp<br>> mydbgprint.cpp<br>> unicode.cpp<br>> eventlog.cpp<br>> dispatchPNPhandling.cpp<br>> dispatchio.cpp<br>> ufilehandle.cpp<br>> channelclass.cpp<br>> eventlog.cpp<br>> MDeviceExtension.cpp<br>> marbiterclass.cpp<br>> isrhandling.cpp
>
> MSC_WARNING_LEVEL=/WX /W3
> I386_WARNING_LEVEL=/WX /W3
>
> LINKER_FLAGS= -base:“0x10000” -entry:“DriverEntry”
>
>
> Compiled but not linked.
>
>
> link() : error LNK2001: unresolved external symbol _DriverEntry@8
> atm4plus.obj() : error LNK2001: unresolved external symbol “void __cdecl
> operator delete(void *)” (??xxxxx@YAXPAX@Z)
> dispatchpnphandling.obj() : error LNK2001: unresolved external symbol
> “void__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
> ufilehandle.obj() : error LNK2001: unresolved external symbol “void
> __cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
> objchk\i386\atm4plus.sys() : error LNK1120: 2 unresolved externals
>
>
> Thanks.
>
>
Don Burn wrote:
Use one of the many samples from the DDK, or post you sources file here for
comment.
I just was able to compile and link OK.
Thanks Don.
I would like to ask a few questions more but i will leave it for monday.
Too much work to do now.
Nikolas Stylianides wrote:
Don Burn wrote:
> The DDK will compile C++ perfectly fine, you have sometning wrong
> with your environment. First are you using the latest DDK? Second
> did you either run setenv.bat or use on the build environments setup
> on the start menu. Third, does you environment build one the samples
> from the DDK correctly?
My build version is 4.03.2134
That’s from the Windows 2000 DDK, which is 6 years old, before they
started including the “guaranteed” compiler. You absolutely need to
move to the latest DDK (Windows 2003 SP1) and scan through a couple of
the samples.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Nikolas Stylianides wrote:
Don Burn wrote:
> Use one of the many samples from the DDK, or post you sources file
> here for comment.
TARGETNAME=atm4plus
TARGETTYPE=DRIVER
TARGETPATH=obj
DRIVERTYPE=WDM
TARGETLIBS=$(BASEDIR)\libchk\i386\int64.lib
$(BASEDIR)\libchk\i386\hal.lib $(BASEDIR)\libchk\i386\ntoskrnl.lib
C_DEFINES= -DONLYONCE=extern -D_WDMDRIVER -Dnologo -D_WIN32_WINNT=0x500
-Dnologo doesn’t do anything. You really just want -nologo, but the DDK
does that for you automatically.
USE_PDB=1
SOURCES=atm4plus.cpp\
mydbgprint.cpp\
unicode.cpp\
eventlog.cpp\
dispatchPNPhandling.cpp\
dispatchio.cpp\
ufilehandle.cpp\
channelclass.cpp\
eventlog.cpp\
MDeviceExtension.cpp\
marbiterclass.cpp\
isrhandling.cpp
MSC_WARNING_LEVEL=/WX /W3
I386_WARNING_LEVEL=/WX /W3
LINKER_FLAGS= -base:“0x10000” -entry:“DriverEntry”
Compiled but not linked.
link() : error LNK2001: unresolved external symbol _DriverEntry@8
What DO you call your DriverEntry? Do you have it declared extern “C”?
atm4plus.obj() : error LNK2001: unresolved external symbol “void
__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
dispatchpnphandling.obj() : error LNK2001: unresolved external symbol
“void __cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
ufilehandle.obj() : error LNK2001: unresolved external symbol “void
__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
objchk\i386\atm4plus.sys() : error LNK1120: 2 unresolved externals
Right. If you plan to use operator new and delete in a driver, you must
define them yourself so that they call ExAllocatePool and ExFreePool.
There are versions in <kcom.h>, if you need them.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</kcom.h>
I have experienced this error and a couple of others like under these
circumstances. I believe that this issue is that you are no linking
with BufferOverflowU.LIB with supplies some of the code that handles the
security checks inserted by -GS. If you wish to disable the checks, use
-GS- and you shouldn’t need the link with BufferOverflowU.LIB.
Another link error that I had when switching compilers is my use of the
Zc:wchar_t switch. It makes wchar_t a native type (not a unsigned
short), which changes the signature. I include this information as you
might exeperience it.
MM
>> xxxxx@gmail.com 09/16/05 6:42 AM >>>
Well I don’t have much idea about the new .NET stuff, but I think this
is
related to .NET security check code.
Try with Configuration Properties => C/C++ => Code Generation => Buffer
Security Check turned off
No idea though why this yields these linker errors. And no idea why
enabling
this option doesn’t give these linker errors during a release build.
This also occurs when building a project in VC6 and linking to a
library
built in VC7 with the Buffer Security Check turned on for the VC7
library.
This occurs in the release build (the only one I checked). It would
presummably also cause a linker error on the symbols ___security_cookie
and
@xxxxx@4 in debug as well.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com