Visual Studio 2015 linking issues for WDM driver

NTDEV
1

Hi All,

I’m working on the project to build the old WDM driver using Visual Studio 2015 with WDK 10. The driver used to be build with NMAKE successfully. After creating an empty WDM driver project and adding the source files and header files and change some settings, I can compile it successfully except the following linking issues with the C++ operator new/delete because the driver was implemented with C++ which calls the C++ operator. I would like to know how I can set in the Visual Studio to solve the following linking issues?

1>DriverEntry.obj : error LNK2019: unresolved external symbol “void __cdecl operator delete(void *,unsigned int)” (??xxxxx@YAXPAXI@Z) referenced in function “public: virtual void * __thiscall drv2::CDeviceInstance::`scalar deleting destructor’(unsigned int)” (??_G?$xxxxx@VCUsbInstance@@@drv2@@UAEPAXI@Z)
1>Enhancer.obj : error LNK2001: unresolved external symbol “void __cdecl operator delete(void *,unsigned int)” (??xxxxx@YAXPAXI@Z)
1>UsbInstance.obj : error LNK2001: unresolved external symbol “void__cdecl operator delete(void *,unsigned int)” (??xxxxx@YAXPAXI@Z)
1>DriverEntry.obj : error LNK2019: unresolved external symbol “void * __cdecl operator new(unsigned int)” (??xxxxx@YAPAXI@Z) referenced in function “bool__stdcall drv2::StringTo::Guid(unsigned short const *,struct _GUID *)” (?xxxxx@xxxxx@drv2@@YG_NPBGPAU_GUID@@@Z)
1>Enhancer.obj : error LNK2001: unresolved external symbol “void * __cdecl operator new(unsigned int)” (??xxxxx@YAPAXI@Z)
1>DriverEntry.obj : error LNK2019: unresolved external symbol “void__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z) referenced in function “bool __stdcall drv2::StringTo::Guid(unsigned short const *,struct _GUID *)” (?xxxxx@xxxxx@drv2@@YG_NPBGPAU_GUID@@@Z)
1>Enhancer.obj : error LNK2001: unresolved external symbol “void__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)

2

Just write the operator delete yourself.

wrote in message news:xxxxx@ntdev…
> Hi All,
>
> I’m working on the project to build the old WDM driver using Visual Studio 2015 with WDK 10. The driver used to be build with NMAKE successfully. After creating an empty WDM driver project and adding the source files and header files and change some settings, I can compile it successfully except the following linking issues with the C++ operator new/delete because the driver was implemented with C++ which calls the C++ operator. I would like to know how I can set in the Visual Studio to solve the following linking issues?
>
> 1>DriverEntry.obj : error LNK2019: unresolved external symbol “void __cdecl operator delete(void *,unsigned int)” (??xxxxx@YAXPAXI@Z) referenced in function “public: virtual void *__thiscall drv2::CDeviceInstance::`scalar deleting destructor’(unsigned int)” (??_G?$xxxxx@VCUsbInstance@@@drv2@@UAEPAXI@Z)
> 1>Enhancer.obj : error LNK2001: unresolved external symbol “void __cdecl operator delete(void *,unsigned int)” (??xxxxx@YAXPAXI@Z)
> 1>UsbInstance.obj : error LNK2001: unresolved external symbol “void__cdecl operator delete(void *,unsigned int)” (??xxxxx@YAXPAXI@Z)
> 1>DriverEntry.obj : error LNK2019: unresolved external symbol “void * __cdecl operator new(unsigned int)” (??xxxxx@YAPAXI@Z) referenced in function “bool__stdcall drv2::StringTo::Guid(unsigned short const *,struct _GUID *)” (?xxxxx@xxxxx@drv2@@YG_NPBGPAU_GUID@@@Z)
> 1>Enhancer.obj : error LNK2001: unresolved external symbol “void * __cdecl operator new(unsigned int)” (??xxxxx@YAPAXI@Z)
> 1>DriverEntry.obj : error LNK2019: unresolved external symbol “void__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z) referenced in function “bool __stdcall drv2::StringTo::Guid(unsigned short const *,struct _GUID *)” (?xxxxx@xxxxx@drv2@@YG_NPBGPAU_GUID@@@Z)
> 1>Enhancer.obj : error LNK2001: unresolved external symbol “void__cdecl operator delete(void *)” (??xxxxx@YAXPAX@Z)
>

3

I don’t know much about writing Windows Drivers in OO C++, but I *do* think you have to implement your own “new” and “delete” operators.

Like “new” becomes ExAllocatePoolWithTag and “delete” becomes ExFreePoolWithTag.

Does that make sense?

Peter
OSR
@OSRDrivers

4

xxxxx@hotmail.com wrote:

I’m working on the project to build the old WDM driver using Visual Studio 2015 with WDK 10. The driver used to be build with NMAKE successfully. After creating an empty WDM driver project and adding the source files and header files and change some settings, I can compile it successfully except the following linking issues with the C++ operator new/delete because the driver was implemented with C++ which calls the C++ operator. I would like to know how I can set in the Visual Studio to solve the following linking issues?

You can grab a copy of global operator new and delete from <kcom.h> in
the WDK header files.

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

5

Thanks a lot, everyone. It begins to work after adding the operator new and delete into the project as similar as those defined in the <kcom.h>.

However, I’m running into another issue as below:
warning C4316: ‘CPendingAsyncIrpTracker’: object allocated on the heap may not be aligned 64

The class CPendingAsyncIrpTracker is actually referencing the NPAGED_LOOKASIDE_LIST and the NPAGED_LOOKASIDE_LIST is referencing GENERAL_LOOKASIDE which is decorated with the following 64bytes alignment in the WDM.h.

#ifndef SYSTEM_CACHE_ALIGNMENT_SIZE
#if defined(AMD64) || defined(X86)
#define SYSTEM_CACHE_ALIGNMENT_SIZE 64
#else
#define SYSTEM_CACHE_ALIGNMENT_SIZE 128
#endif
#endif

class CPendingAsyncIrpTracker
{
SAFE_DESTRUCTORS

static ALLOCATE_FUNCTION CppAllocate;
//static PVOID CppAllocate(POOL_TYPE PoolType, SIZE_T NumberOfBytes, ULONG Tag);
static FREE_FUNCTION CppFree;
//static VOID CppFree(PVOID Buffer);

KSPIN_LOCK m_spnLk;
NPAGED_LOOKASIDE_LIST m_lalTracker;
LIST_ENTRY m_AllocListHead;

#if DBG
LONG m_nCount;
#endif

public:
CPendingAsyncIrpTracker();
~CPendingAsyncIrpTracker();

NTSTATUS AppendNewIrp(PGENERIC_EXTENSION pdx, PIRP pIrpCur);
bool RetrievePendingIrp(PGENERIC_EXTENSION pdx, PIRP* pIrpOut);
void CompleteOutstandingIrp(PGENERIC_EXTENSION pdx, PIRP* pIrp, int info = 0, NTSTATUS code = STATUS_SUCCESS);
};

How can I fix this issue? Although it’s a warning, but I don’t want the driver throws exception due to this issue.

Thanks,
Marshall</kcom.h>

6

On 30-Oct-2015 10:58, xxxxx@hotmail.com wrote:

However, I’m running into another issue as below:
warning C4316: ‘CPendingAsyncIrpTracker’: object allocated on the heap may not be aligned 64

Documentation on NPAGED_LOOKASIDE_LIST says:
“On 64-bit platforms, this structure must be 16-byte aligned.”

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

But in wdm.h:

#if !defined(_WIN64) /* … */
#define LOOKASIDE_ALIGN
#else
#define LOOKASIDE_ALIGN DECLSPEC_CACHEALIGN
#endif

A docum bug?

@OP: it’s good to be safe rather than sorry, so yes, ensure the
alignment yourself (as usual, exactly as you would do the same in
usermode). ExAllocate… functions align on 16 bytes at most.

– pa

7

xxxxx@hotmail.com wrote:

Thanks a lot, everyone. It begins to work after adding the operator new and delete into the project as similar as those defined in the <kcom.h>.
>
> However, I’m running into another issue as below:
> warning C4316: ‘CPendingAsyncIrpTracker’: object allocated on the heap may not be aligned 64
>
> The class CPendingAsyncIrpTracker is actually referencing the NPAGED_LOOKASIDE_LIST and the NPAGED_LOOKASIDE_LIST is referencing GENERAL_LOOKASIDE which is decorated with the following 64bytes alignment in the WDM.h.

“operator new” from <kcom.h> calls ExAllocatePool, and ExAllocatePool
aligns on16-byte boundaries. As Pavel points out, the documentation for
NPAGED_LOOKASIDE_LIST requires 16-byte boundaries, so everything should
be just fine. I suggest you simply use “#pragma warning(disable :
4316)” to silence the warning, perhaps with a comment as to the
justification.

If you don’t like that solution, you can write member functions for
“operator new” and “operator delete” in CPendingAsyncIrpTracker that
allocates 64 extra bytes and returns the aligned address. You’ll have
to remember the unaligned address somewhere so you can free it properly.

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