Windows 10 Driver Entry point is not getting called when Driver is loaded

My company is a linux shop, however, we have resurrected a project that was originally done using Visual Studio 2010. The build process is command line driver. I have been tasked with getting the system to build using Visual Studio 2019. I have successfully built the product. I have created a .msi file, a .inf file, a .sys file. When I attempt to load the driver the DriverEntry function is not called. I assume that either a compile or link switch is incorrect or missing. Since I don’t get to the DriverEntry point I don’t know how to debug.

Below I have included the full compile line, the full link line. Any suggestions that you can provide would be appreciated.
Is there any output that I can view to see if the DriverEntry is defined without having to try to load it?
Can you suggest any strategies for debugging this?

my Driver is in file mx.c
This is the compile line for mx.c
cl /FC /c /Zc:wchar_t- /Zp8 /Gy /W3 /EHs-c- /GR- /GF /GS /Zi /GL /wd4018 /wd4101 /wd4102 /wd4146 /wo4133 /wo4244 /wo4267 /kernel /Oxs -cbstring -I…/…/common -I…/…/mcp/10g/zekit/fapi -I…/…/driver/common -I…/…/common -I…/…/mcp/10g -I. -DMAL_KERNEL -DMX_THREAD_SAFE=1 -I./…/zlib -D_WIN64 -D_AMD64_ -DAMD64 -DCONDITION_HANDLING=1 -DNT_INST=0 -DWIN32=100 -D_NT1X_=100 -DWINNT=1 -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -D_WIN32_IE=0x0700 -DWIN32_LEAN_AND_MEAN=1 -DDEVL=1 -D__BUILDMACHINE__=WinDDK -DNTDDI_VERSION=0x06020000 -DNDEBUG -DNDIS_MINIPORT_DRIVER -DBUILD_W2K=0 -DNDIS60_MINIPORT=1 -Dinline=inline -DMYRI_DRIVER=myri_mva -I. -D__func_=FUNCTION -DNDIS_MINIPORT_DRIVER=1 -DNDIS60_MINIPORT=1 /c mx.c /Fomx.obj

This is the link line:
link /machine:amd64 /MERGE:_PAGE=PAGE /MERGE:_TEXT=.text /SECTION:INIT,d /OPT:REF /OPT:ICF /IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,4218,4235 /INCREMENTAL:NO /FULLBUILD /release /debug /debugtype:cv /version:6.0 /osversion:6.0 /debug /ltcg /STACK:0x40000,0x1000 /driver:WDM /subsystem:native,6.0 -entry:DriverEntry “C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/km/x64/hal.lib” “C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/km/x64/ntoskrnl.lib” “C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/km/x64/BufferOverflowK.lib” “C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/km/x64/ntstrsafe.lib” “C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x64/libucrt.lib” “C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/km/x64/ndis.lib” -out:myri_mva.sys mx.obj mx_ntddk.obj mx_common.obj mx_instance.obj mx_lanai_command.obj kraw.obj mcp_wrapper_common.obj mx_lx.obj mx_lz.obj myri_ptp_common.obj myri_raw_ops.obj myri_mva_ops.obj mx_ether_common.obj adler32.obj crc32.obj infblock.obj infcodes.obj inffast.obj inflate.obj inftrees.obj infutil.obj trees.obj uncompr.obj zutil.obj in_cksum.obj myri_mva.RES

The first thing i do when DriverEntry is not called is check the imports: link /dump /imports . From a quick scan of the linker command lineyou are linking against libucrt.lib which is meant for kernel mode binaries. You can tell from the path as there is no “km” in it

C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x64/libucrt.lib

Compare that to C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/km/x64/BufferOverflowK.lib

I added that library because I was getting these link errors? The legacy code from Visual Studio 2010 was using some stdio calls. Is there a kernel library that supplies these or do I need to rewrite the code without the stdio calls?

mx.obj : error LNK2001: unresolved external symbol __stdio_common_vsnprintf_s
mx.obj : error LNK2001: unresolved external symbol __stdio_common_vswprintf
mx_common.obj : error LNK2001: unresolved external symbol __stdio_common_vsprin

The core components of the kernel were built on top of C (not C++) and does not support anything related to the CRT.
The functions you are referring to are available in kernel, ntoskrnl does export them. You should rewrite your std calls to use thoses (without the CRT prefixes like ‘_stdio_common’ obviously).

you want to link against $(DDK_LIB_PATH)/libcntpr.lib