building a kernel mode dll

NTDEV
1

Hi ntdev guys,

I need some help here. Maybe somebody can fill in the gap in my technical knowledge.

I just gave this feedback to Microsoft. I was wondering if you generally agree with the statement in bold, or is it just that I want to do weird things that nobody else bothers about? Or maybe I’m dumber than the average bear?

Hi Microsoft,

I’m looking to craft a kernel mode dll from an earlier WDM static library using latest build tools (10586).

I can only find very dated information about kernel dll’s in published documentation sources. Have I missed something?

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

This is the top hit on Microsoft pages and is clearly relevant but despite title with RELEASE: (2/17/2016) it reports “Last updated May 2007”
Indeed the content is from that vintage, with references back to 2003 material.

This contains (now) incorrect guidance - like don’t use visual studio - and needs so much interpretation that essentially its obsolete now.
In fact in general it seems that the supplementary guidance on Microsoft website is overwhelmingly irrelevant to the new way of building drivers.

So we are limited to what’s in the WDK Help. That scope is narrow (which is why there have been so many good supplementary articles such as this particular one in the past). We rely on this latter resource. I appreciate that it is a huge job to update them, but the writing has been on the wall since the initial integration of driver development in Visual Studio, and that is years ago now. […]

In the current WDK setup :

there is no legacy DDK build support (to which the current posted material is relevant)
there is no migration tool to support working-round this limitation using an old WDK as a start point.
there is no new template to demonstrate how [it] can be achieved with the current tools
The visual studio guidance on the effect of project settings is (for this purpose at least) difficult to find, scant and inadequate.

I was hoping one of the current samples would come to the rescue but, after some searching, I despaired. Maybe I missed something?

Please tell me you’re aware of this, and [are] pulling out all the stops to update your online kernel literature.

That’s my contribution to the community badgering. Here’s what I’ve tried by way of self help on this problem:

  1. I chose the VS template under “Windows Drivers /Applications/ Empty DLL for Drivers” as a start point. That approach ignores the fact that this template evidently meant for some other mysterious and veiled purpose in user mode. I just trust that its name and location might possibly make it a “better” kernel dll template candidate than a standard UM dll.

  2. From here I’ve done all that I know about (modified include path & libraries in the obvious ways) and changed extension to .sys - just to comply with usual convention) .

The result is, well, “something” that compiles and links without errors. But that’s about all I could say about it.

Whereas I do have a dll, and it does IMPORT ntoskrnl.exe, there are some clear problems …

I haven’t got a ‘lib’ file to link against which renders it spectacularly useless – (probably because I forgot to add DLL_EXPORT declspec until now)
I haven’t done anything equivalent to the old EXPORT_DRIVER trick (which just worries me like a rheumatic pain).
The pecoff image reflects the fact that its a DLL and confirms the ntoskrnl import, but indicates that its still IMAGE_SUBSYSTEM_WINDOWS_GUI (and that’s plain wrong).

These residuals might well be fixable, but it strikes me that this trial and error approach is the perfect way to accumulate dormant hidden problems.
This isn’t a path for the professional engineer, and I’m a bit hacked off at having to do this. Hence this post.

In a perfect world somebody’ll flame me with a “RTFM” reply, pointing me to chapter and verse….

I don’t know what you guys are finding, but vs projects settings in place of make files is all very trendy, and laudably convenient in principle…
assuming there were working and documented templates and all the property settings were well documented and stable from one VS studio version to the next…
But we’re not even close there yet. In practice it can easily obsolete all the help that you can find, and only succeed in creating a new complex and undocumented build paradigm.

Lets face it a kernel dll isn’t exactly something from outer space. Why so obscure? Hopefully I just missed something amongst all the new stuff, and the noise.

MANY THANKS!

Sent from Mail for Windows 10

2

This has been brought up previously, there is not an easy option for setting
up an export driver from the GUI. “Empty DLL for Drivers” is certainly a
misleading name, but that’s definitely NOT what you want (it creates an
empty user mode DLL project, presumably for a user mode control program).

The easiest way I know to get an export driver is to:

  1. Create an Empty WDM Driver project, delete the INF it creates

  2. Open the vcxproj in Notepad. Change this:

WDM

To:

ExportDriver

Voila, you have an export driver. The only other thing to remember is to
specify your module definition file (.DEF) via the GUI (Project
Properties->Linker->Input->Module Definition File)

-scott
OSR
@OSRDrivers

“Dev Home” wrote in message news:xxxxx@ntdev…

Hi ntdev guys,

I need some help here. Maybe somebody can fill in the gap in my technical
knowledge.

I just gave this feedback to Microsoft. I was wondering if you generally
agree with the statement in bold, or is it just that I want to do weird
things that nobody else bothers about? Or maybe I’m dumber than the average
bear?

Hi Microsoft,

I’m looking to craft a kernel mode dll from an earlier WDM static library
using latest build tools (10586).

I can only find very dated information about kernel dll’s in published
documentation sources. Have I missed something?

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

This is the top hit on Microsoft pages and is clearly relevant but despite
title with RELEASE: (2/17/2016) it reports “Last updated May 2007”

Indeed the content is from that vintage, with references back to 2003
material.

This contains (now) incorrect guidance - like don’t use visual studio - and
needs so much interpretation that essentially its obsolete now.

In fact in general it seems that the supplementary guidance on Microsoft
website is overwhelmingly irrelevant to the new way of building drivers.

So we are limited to what’s in the WDK Help. That scope is narrow (which is
why there have been so many good supplementary articles such as this
particular one in the past). We rely on this latter resource. I appreciate
that it is a huge job to update them, but the writing has been on the wall
since the initial integration of driver development in Visual Studio, and
that is years ago now. […]

In the current WDK setup :

there is no legacy DDK build support (to which the current posted material
is relevant)

there is no migration tool to support working-round this limitation using an
old WDK as a start point.

there is no new template to demonstrate how [it] can be achieved with the
current tools

The visual studio guidance on the effect of project settings is (for this
purpose at least) difficult to find, scant and inadequate.

I was hoping one of the current samples would come to the rescue but, after
some searching, I despaired. Maybe I missed something?

Please tell me you’re aware of this, and [are] pulling out all the stops to
update your online kernel literature.

That’s my contribution to the community badgering. Here’s what I’ve tried by
way of self help on this problem:

1. I chose the VS template under “Windows Drivers /Applications/ Empty
DLL for Drivers” as a start point. That approach ignores the fact that this
template evidently meant for some other mysterious and veiled purpose in
user mode. I just trust that its name and location might possibly make it a
“better” kernel dll template candidate than a standard UM dll.

2. From here I’ve done all that I know about (modified include path &
libraries in the obvious ways) and changed extension to .sys - just to
comply with usual convention) .

The result is, well, “something” that compiles and links without errors.
But that’s about all I could say about it.

Whereas I do have a dll, and it does IMPORT ntoskrnl.exe, there are some
clear problems …

I haven’t got a ‘lib’ file to link against which renders it spectacularly
useless – (probably because I forgot to add DLL_EXPORT declspec until now)

I haven’t done anything equivalent to the old EXPORT_DRIVER trick (which
just worries me like a rheumatic pain).

The pecoff image reflects the fact that its a DLL and confirms the ntoskrnl
import, but indicates that its still IMAGE_SUBSYSTEM_WINDOWS_GUI (and that’s
plain wrong).

These residuals might well be fixable, but it strikes me that this trial and
error approach is the perfect way to accumulate dormant hidden problems.

This isn’t a path for the professional engineer, and I’m a bit hacked off at
having to do this. Hence this post.

In a perfect world somebody’ll flame me with a “RTFM” reply, pointing me to
chapter and verse….

I don’t know what you guys are finding, but vs projects settings in place of
make files is all very trendy, and laudably convenient in principle…

assuming there were working and documented templates and all the property
settings were well documented and stable from one VS studio version to the
next…

But we’re not even close there yet. In practice it can easily obsolete all
the help that you can find, and only succeed in creating a new complex and
undocumented build paradigm.

Lets face it a kernel dll isn’t exactly something from outer space. Why so
obscure? Hopefully I just missed something amongst all the new stuff, and
the noise.

Many thanks!

Sent from Mail for Windows 10