64-bit driver built with the latest DDK wouldnt load

Well, by now I've made some progress investigating the problem.

What renders the driver unfit for loading is linking with any of the following libraries (all taken from libs\wnet\amd64 DDK's directory): libc.lib, libcntpr.lib, ntdll.lib.

I had to try linking with these libraries because they contain some floating point functions that we use: sin, cos, log etc.. All these functions are supposed to be intrinsic, yet the compiler creates external references for them. When any of the above libraries is used for linking, all references are resolved, but the driver simply doesn't load. By comparing the good and the bad versions, I've found out that the bad driver contains references to 2 functions in kernel32.dll : RtlRaiseException and RtlUnwindEx. I can see both functions by WinDbg in the nt module (nt!RtlRaiseException and nt!RtlUnwindEx). Yet, referencing them prevents the driver from being loaded.

Before changing over to the new DDK I used my own implementation of these functions that was based on moving the operands from XMM registers to the Floating point unit, performing the necessary operations there and then moving the results back to the XMM registers. That worked perfectly fine, but the new assember treats the very usage of the floating point instructions as an error.

Does anybody know where these functions can be imported from in the new DDK?
Or will I have to implement them by my own in assembly (or find such an implementation) without using the FP unit?

Hope someone can help

Thank you!

Hi,

Yes, I resolved the issue. I'm sorry I didn't fill everybody in on that.

There have been a couple of problems.

First, don't use ntdll.lib !!! It seems to be a ring 3 library. Anyway, kernel drivers don't load when they as much as reference the library. The same goes for libc.lib, ntoskrnl.lib

Second, don't use bufferoverflow.lib to reslove the references generated by the new compiler. Instead, use bufferoverflowk.lib. I believe, "k" stands for "kernel" here.

Also, there's a new test in Microsoft's HCT called Calling conventions. It failed my driver even after it became loadable and worked perfectly fine. This way I learnt that wdmsec.lib had to be used instead of wdm.lib.

Just to sum things up, here's the list of kernel import libraries I link with:

wdmsec.lib
hal.lib
bufferoverflowk.lib
ntstrsafe.lib

I would recommend starting from this set and then finding additional libs in case there are unresolved externals. For the USB drivers you'll need usbd.lib.

Hope this helps.
Good luck!

Well, that's great news! Enjoy:)