Liking error - DriverEntry

NTDEV
1

Hi,

I have a simple “C++” based driver having only the DriverEntry function.
When the code is linked I get an error like this

BufferOverflowK.lib(gs_support.obj) : error LNK2019: unresolved external
symbol xxxxx@8 referenced in function _GsDriverEntry@8

If I change its (DriverEntry) linkage specification to “C” (extern “C”) the
code compiles and links correctly.

The documentation of DriverEntry in the following link indicates (to my
understanding) that it is a C++ function. Could there be anything I might
be doing wrong?

http://msdn.microsoft.com/en-in/library/windows/hardware/ff544113(v=vs.85).aspx

Thanks,
Lloyd

2

Bufferoverflowk.lib hijacks your PE image entry point (with GsDriverEntry) and then calls DriverEntry. Bufferoverflowk.lib is c code and thus needs to be extern C. Even if this hijacking didn’t occur, you still need extern C to stop c++ name mangling so the entry point name resolves

d

Bent from my phone

From: Lloydmailto:xxxxx
Sent: ?6/?4/?2014 2:18 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Liking error - DriverEntry

Hi,

I have a simple “C++” based driver having only the DriverEntry function. When the code is linked I get an error like this

BufferOverflowK.lib(gs_support.obj) : error LNK2019: unresolved external symbol xxxxx@8 referenced in function _GsDriverEntry@8

If I change its (DriverEntry) linkage specification to “C” (extern “C”) the code compiles and links correctly.

The documentation of DriverEntry in the following link indicates (to my understanding) that it is a C++ function. Could there be anything I might be doing wrong?

http://msdn.microsoft.com/en-in/library/windows/hardware/ff544113(v=vs.85).aspx

Thanks,
Lloyd

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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</mailto:xxxxx></mailto:xxxxx>

3

Lloyd wrote:

I have a simple “C++” based driver having only the DriverEntry
function. When the code is linked I get an error like this

BufferOverflowK.lib(gs_support.obj) : error LNK2019: unresolved
external symbol xxxxx@8 referenced in function _GsDriverEntry@8

If I change its (DriverEntry) linkage specification to “C” (extern
“C”) the code compiles and links correctly.

The documentation of DriverEntry in the following link indicates (to
my understanding) that it is a C++ function.

You’re reading too much into this. Remember that C++ was officially
taboo in the kernel until very recently. As a result, almost none of
the documentation pages describe the linkage requirements. As a rule,
anything that can be referenced from the outside must be declared extern
“C”. Also, any function that you plan to use with #pragma alloc_text
must be extern “C”.

Could there be anything I might be doing wrong?

http://msdn.microsoft.com/en-in/library/windows/hardware/ff544113(v=vs.85).aspx
http:

In the normal case, the name mangling of DriverEntry is irrelevant.
DriverEntry is the main entry point for your executable, so the virtual
address goes directly into the “entry point” field in the PE header.
The name doesn’t matter.

But, as Doron said, BufferOverflow changes that dynamic. It refers to
DriverEntry by name, so the name needs to have extern “C” linkage.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</http:>

4

Thank you Doron for the explanation, But that left some new questions in my
mind. Thank you Tim for your very detailed explanation. Your post has
answered those new questions.

Thanks a lot,
Lloyd

On Wed, Jun 4, 2014 at 11:22 PM, Tim Roberts wrote:

> Lloyd wrote:
> >
> > I have a simple “C++” based driver having only the DriverEntry
> > function. When the code is linked I get an error like this
> >
> > BufferOverflowK.lib(gs_support.obj) : error LNK2019: unresolved
> > external symbol xxxxx@8 referenced in function _GsDriverEntry@8
> >
> > If I change its (DriverEntry) linkage specification to “C” (extern
> > “C”) the code compiles and links correctly.
> >
> > The documentation of DriverEntry in the following link indicates (to
> > my understanding) that it is a C++ function.
>
> You’re reading too much into this. Remember that C++ was officially
> taboo in the kernel until very recently. As a result, almost none of
> the documentation pages describe the linkage requirements. As a rule,
> anything that can be referenced from the outside must be declared extern
> “C”. Also, any function that you plan to use with #pragma alloc_text
> must be extern “C”.
>
>
> > Could there be anything I might be doing wrong?
> >
> >
> http://msdn.microsoft.com/en-in/library/windows/hardware/ff544113(v=vs.85).aspx
> > <
> http://msdn.microsoft.com/en-in/library/windows/hardware/ff544113(v=vs.85).aspx
> >
>
> In the normal case, the name mangling of DriverEntry is irrelevant.
> DriverEntry is the main entry point for your executable, so the virtual
> address goes directly into the “entry point” field in the PE header.
> The name doesn’t matter.
>
> But, as Doron said, BufferOverflow changes that dynamic. It refers to
> DriverEntry by name, so the name needs to have extern “C” linkage.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>