Native application for driver

I have the need for a native NT application to interface with my driver. I
found a couple of samples and was able to build, but I get back screen at
boot and then a reboot into recovery. The behavior is similar to an
unsigned driver.

Are there any official documents? It would be nice to have some
documentation rather than spending the next week hacking through it.


Jamey Kirby
Disrupting the establishment since 1964

*This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.*

Jamey Kirby wrote:

I have the need for a native NT application to interface with my driver.

Interesting. How do you plan to find your driver?

I found a couple of samples and was able to build, but I get back
screen at boot and then a reboot into recovery. The behavior is
similar to an unsigned driver.

Have you attached a kernel debugger to see if you are getting a BSOD?

Are there any official documents? It would be nice to have some
documentation rather than spending the next week hacking through it.

There are a couple of books on the topic, but essentially no documentation.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

  1. I do not understand what you mean by “How do you plan to find your
    driver?”. I will use NtCreateFile() and the likes to open and utilize the
    driver.

  2. No. I was hoping to find some good examples or documentation before
    delving in that deep; hence my comment “… rather than spending the next
    week hacking through it.”

  3. Yeah, that seems to be the case. It is not rocket science, and I am sure
    I can pull something together this week. I was just hoping there was some
    information to make my life easier :slight_smile:

On Wed, Jul 1, 2015 at 12:26 PM, Tim Roberts wrote:

> Jamey Kirby wrote:
> > I have the need for a native NT application to interface with my driver.
>
> Interesting. How do you plan to find your driver?
>
>
> > I found a couple of samples and was able to build, but I get back
> > screen at boot and then a reboot into recovery. The behavior is
> > similar to an unsigned driver.
>
> Have you attached a kernel debugger to see if you are getting a BSOD?
>
>
> > Are there any official documents? It would be nice to have some
> > documentation rather than spending the next week hacking through it.
>
> There are a couple of books on the topic, but essentially no documentation.
>
> –
> 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
>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

Hmmmm… It seems to me that if you know your Windows internals, you know your native API. I’ve written a good number of native API programs in my career, though I admit I’ve written none recently. I always found it a lot like writing kernel-mode Windows code… but in user-mode. :wink:

What is it that you’re trying to do that’s giving you difficulty?

Why would you get anything at boot time at all? Is your application actually a Windows Servier that’s running at boot time?

Why on earthy would you NEED to write an application with the Native NT API (ah, because you WANT IT TO RUN AT BLUE SCREEN STARTUP TIME of course… right? You kinda left that out of the post).

Obviously, conventional wisdom would say to (a) debug it by running it interactively and not at boot time, and (b) debug it (like Tim said). Chances are its just something simple.

Peter
OSR
@OSRDrivers

Looking at my notes… one of the most common mistakes that people make doing file I/O with the native API is that they don’t realize that there’s no default directory provided for CreateFile. So, you always need to specify a fully qualified path name.

Aside from THAT, and the fact that the NtReadFile and NtWriteFile default to asynchronous which I’m sure you know… I’m not really aware of any “tricks”…

Peter
OSR
@OSRDrivers

Thanks for the input.

I am mostly experimenting with some ideas. Let’s say that you are tracking
I/O via a volume filter, and during the I/O, you need to do some of your
own IO such as reading and writing a file. In the past, I would have
addressed this with creating a system thread, posting the IRP to a queue,
and peel off the requests in the thread and do whatever IO I needed via
ZwXxx(). This is side-by-side IO, not redirection, so synchronization of
the IO is not so important. It gets a little tricky, but it does work.

I would rather have a native “service” that loads very early to pull the
queued data from the driver and write it to a file. If it loads too late,
the driver can exhaust memory; so a service would not work. For example,
autochk could need to fix a corrupted disk and generate tons of IO, so I
would want the native application to load before autochk.

Another advantage to this is that code is moved out of KM and into UM. It
is always best to do as little as possible in KM.

So, in short, I would like to move secondary file IO out of the driver an
into a custom native “service” that loads VERY early in the boot process.

On Thu, Jul 2, 2015 at 8:39 AM, wrote:

> Looking at my notes… one of the most common mistakes that people make
> doing file I/O with the native API is that they don’t realize that there’s
> no default directory provided for CreateFile. So, you always need to
> specify a fully qualified path name.
>
> Aside from THAT, and the fact that the NtReadFile and NtWriteFile default
> to asynchronous which I’m sure you know… I’m not really aware of any
> “tricks”…
>
> Peter
> OSR
> @OSRDrivers
>
> —
> 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
>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

I see two native components/apps:

  1. A loader application that loads before autochk
  2. A native application that is loaded by 1) that creates the process that
    remains resident after the loaded app terminates.

This resident app then communicates witht he driver to do its thing.

On Thu, Jul 2, 2015 at 1:29 PM, Jamey Kirby wrote:

> Thanks for the input.
>
> I am mostly experimenting with some ideas. Let’s say that you are tracking
> I/O via a volume filter, and during the I/O, you need to do some of your
> own IO such as reading and writing a file. In the past, I would have
> addressed this with creating a system thread, posting the IRP to a queue,
> and peel off the requests in the thread and do whatever IO I needed via
> ZwXxx(). This is side-by-side IO, not redirection, so synchronization of
> the IO is not so important. It gets a little tricky, but it does work.
>
> I would rather have a native “service” that loads very early to pull the
> queued data from the driver and write it to a file. If it loads too late,
> the driver can exhaust memory; so a service would not work. For example,
> autochk could need to fix a corrupted disk and generate tons of IO, so I
> would want the native application to load before autochk.
>
> Another advantage to this is that code is moved out of KM and into UM. It
> is always best to do as little as possible in KM.
>
> So, in short, I would like to move secondary file IO out of the driver an
> into a custom native “service” that loads VERY early in the boot process.
>
> ᐧ
>
> On Thu, Jul 2, 2015 at 8:39 AM, wrote:
>
>> Looking at my notes… one of the most common mistakes that people make
>> doing file I/O with the native API is that they don’t realize that there’s
>> no default directory provided for CreateFile. So, you always need to
>> specify a fully qualified path name.
>>
>> Aside from THAT, and the fact that the NtReadFile and NtWriteFile default
>> to asynchronous which I’m sure you know… I’m not really aware of any
>> “tricks”…
>>
>> Peter
>> OSR
>> @OSRDrivers
>>
>> —
>> 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
>>
>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.

>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

Should read:

… after the loader app terminates.

On Thu, Jul 2, 2015 at 1:34 PM, Jamey Kirby wrote:

> I see two native components/apps:
>
> 1) A loader application that loads before autochk
> 2) A native application that is loaded by 1) that creates the process that
> remains resident after the loaded app terminates.
>
> This resident app then communicates witht he driver to do its thing.
> ᐧ
>
> On Thu, Jul 2, 2015 at 1:29 PM, Jamey Kirby wrote:
>
>> Thanks for the input.
>>
>> I am mostly experimenting with some ideas. Let’s say that you are
>> tracking I/O via a volume filter, and during the I/O, you need to do some
>> of your own IO such as reading and writing a file. In the past, I would
>> have addressed this with creating a system thread, posting the IRP to a
>> queue, and peel off the requests in the thread and do whatever IO I needed
>> via ZwXxx(). This is side-by-side IO, not redirection, so synchronization
>> of the IO is not so important. It gets a little tricky, but it does work.
>>
>> I would rather have a native “service” that loads very early to pull the
>> queued data from the driver and write it to a file. If it loads too late,
>> the driver can exhaust memory; so a service would not work. For example,
>> autochk could need to fix a corrupted disk and generate tons of IO, so I
>> would want the native application to load before autochk.
>>
>> Another advantage to this is that code is moved out of KM and into UM. It
>> is always best to do as little as possible in KM.
>>
>> So, in short, I would like to move secondary file IO out of the driver an
>> into a custom native “service” that loads VERY early in the boot process.
>>
>> ᐧ
>>
>> On Thu, Jul 2, 2015 at 8:39 AM, wrote:
>>
>>> Looking at my notes… one of the most common mistakes that people make
>>> doing file I/O with the native API is that they don’t realize that there’s
>>> no default directory provided for CreateFile. So, you always need to
>>> specify a fully qualified path name.
>>>
>>> Aside from THAT, and the fact that the NtReadFile and NtWriteFile
>>> default to asynchronous which I’m sure you know… I’m not really aware of
>>> any “tricks”…
>>>
>>> Peter
>>> OSR
>>> @OSRDrivers
>>>
>>> —
>>> 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
>>>
>>
>>
>>
>> –
>> Jamey Kirby
>> Disrupting the establishment since 1964
>>
>> This is a personal email account and as such, emails are not subject to
>> archiving. Nothing else really matters.

>>
>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.

>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

The reason for the reboot at load time was because of an error I made in
setting up the registry. Once I fixed this, the application ran just fine.
I shaved the code down to something you can build from the command line
with a simple . Here is a boiler plate program that will build
and run before autochk.exe.

// Build:
// cl native.c

#define AMD64
#include <ntdef.h>

#pragma comment(linker,“/ENTRY:NtProcessStartup /SUBSYSTEM:NATIVE”)
#pragma comment(lib, “ntdll.lib”)

NTSTATUS NTAPI NtTerminateProcess(HANDLE ProcessHandle, LONG ExitStatus);

void __stdcall NtProcessStartup(PVOID StartupArgument)
{
NtTerminateProcess((HANDLE)-1, 0);
}

Registry

Key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\BootExecute

Values:

MyNativeProgram native Arguments
autocheck autochk *



On Thu, Jul 2, 2015 at 1:38 PM, Jamey Kirby wrote:

> Should read:
>
> … after the loader app terminates.
>
>
> ᐧ
>
> On Thu, Jul 2, 2015 at 1:34 PM, Jamey Kirby wrote:
>
>> I see two native components/apps:
>>
>> 1) A loader application that loads before autochk
>> 2) A native application that is loaded by 1) that creates the process
>> that remains resident after the loaded app terminates.
>>
>> This resident app then communicates witht he driver to do its thing.
>> ᐧ
>>
>> On Thu, Jul 2, 2015 at 1:29 PM, Jamey Kirby
>> wrote:
>>
>>> Thanks for the input.
>>>
>>> I am mostly experimenting with some ideas. Let’s say that you are
>>> tracking I/O via a volume filter, and during the I/O, you need to do some
>>> of your own IO such as reading and writing a file. In the past, I would
>>> have addressed this with creating a system thread, posting the IRP to a
>>> queue, and peel off the requests in the thread and do whatever IO I needed
>>> via ZwXxx(). This is side-by-side IO, not redirection, so synchronization
>>> of the IO is not so important. It gets a little tricky, but it does work.
>>>
>>> I would rather have a native “service” that loads very early to pull the
>>> queued data from the driver and write it to a file. If it loads too late,
>>> the driver can exhaust memory; so a service would not work. For example,
>>> autochk could need to fix a corrupted disk and generate tons of IO, so I
>>> would want the native application to load before autochk.
>>>
>>> Another advantage to this is that code is moved out of KM and into UM.
>>> It is always best to do as little as possible in KM.
>>>
>>> So, in short, I would like to move secondary file IO out of the driver
>>> an into a custom native “service” that loads VERY early in the boot process.
>>>
>>> ᐧ
>>>
>>> On Thu, Jul 2, 2015 at 8:39 AM, wrote:
>>>
>>>> Looking at my notes… one of the most common mistakes that people make
>>>> doing file I/O with the native API is that they don’t realize that there’s
>>>> no default directory provided for CreateFile. So, you always need to
>>>> specify a fully qualified path name.
>>>>
>>>> Aside from THAT, and the fact that the NtReadFile and NtWriteFile
>>>> default to asynchronous which I’m sure you know… I’m not really aware of
>>>> any “tricks”…
>>>>
>>>> Peter
>>>> OSR
>>>> @OSRDrivers
>>>>
>>>> —
>>>> 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
>>>>
>>>
>>>
>>>
>>> –
>>> Jamey Kirby
>>> Disrupting the establishment since 1964
>>>
>>> This is a personal email account and as such, emails are not subject to
>>> archiving. Nothing else really matters.

>>>
>>
>>
>>
>> –
>> Jamey Kirby
>> Disrupting the establishment since 1964
>>
>> This is a personal email account and as such, emails are not subject to
>> archiving. Nothing else really matters.

>>
>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.

>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
</ntdef.h>

Oh, Tim, I now understand what you may have been referring to when you
asked “how will I find my driver?” How will I determine the device name in
order to control the device; right? Fortunately, in this case, the devices
are volume filters, so I can use well know device names. This is how
autochk does its thing.

Again, I am just experimenting, and I suspect I may get yelled at pretty
soon for going too far off topic with respect to NT driver development; but
many of us driver developers utilize system level user-mode components to
interact with our drivers, so I thought it might be informative for me to
share the experience.

On Thu, Jul 2, 2015 at 3:57 PM, Jamey Kirby wrote:

> The reason for the reboot at load time was because of an error I made in
> setting up the registry. Once I fixed this, the application ran just fine.
> I shaved the code down to something you can build from the command line
> with a simple . Here is a boiler plate program that will build
> and run before autochk.exe.
>
> // Build:
> // cl native.c
>
> #define AMD64
> #include <ntdef.h>
>
> #pragma comment(linker,“/ENTRY:NtProcessStartup /SUBSYSTEM:NATIVE”)
> #pragma comment(lib, “ntdll.lib”)
>
> NTSTATUS NTAPI NtTerminateProcess(HANDLE ProcessHandle, LONG ExitStatus);
>
> void __stdcall NtProcessStartup(PVOID StartupArgument)
> {
> NtTerminateProcess((HANDLE)-1, 0);
> }
>
> Registry
>
> Key:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
> Manager\BootExecute
>
> Values:
>
> MyNativeProgram native Arguments
> autocheck autochk *
>
>
> ᐧ
>
> On Thu, Jul 2, 2015 at 1:38 PM, Jamey Kirby wrote:
>
>> Should read:
>>
>> … after the loader app terminates.
>>
>>
>> ᐧ
>>
>> On Thu, Jul 2, 2015 at 1:34 PM, Jamey Kirby
>> wrote:
>>
>>> I see two native components/apps:
>>>
>>> 1) A loader application that loads before autochk
>>> 2) A native application that is loaded by 1) that creates the process
>>> that remains resident after the loaded app terminates.
>>>
>>> This resident app then communicates witht he driver to do its thing.
>>> ᐧ
>>>
>>> On Thu, Jul 2, 2015 at 1:29 PM, Jamey Kirby
>>> wrote:
>>>
>>>> Thanks for the input.
>>>>
>>>> I am mostly experimenting with some ideas. Let’s say that you are
>>>> tracking I/O via a volume filter, and during the I/O, you need to do some
>>>> of your own IO such as reading and writing a file. In the past, I would
>>>> have addressed this with creating a system thread, posting the IRP to a
>>>> queue, and peel off the requests in the thread and do whatever IO I needed
>>>> via ZwXxx(). This is side-by-side IO, not redirection, so synchronization
>>>> of the IO is not so important. It gets a little tricky, but it does work.
>>>>
>>>> I would rather have a native “service” that loads very early to pull
>>>> the queued data from the driver and write it to a file. If it loads too
>>>> late, the driver can exhaust memory; so a service would not work. For
>>>> example, autochk could need to fix a corrupted disk and generate tons of
>>>> IO, so I would want the native application to load before autochk.
>>>>
>>>> Another advantage to this is that code is moved out of KM and into UM.
>>>> It is always best to do as little as possible in KM.
>>>>
>>>> So, in short, I would like to move secondary file IO out of the driver
>>>> an into a custom native “service” that loads VERY early in the boot process.
>>>>
>>>> ᐧ
>>>>
>>>> On Thu, Jul 2, 2015 at 8:39 AM, wrote:
>>>>
>>>>> Looking at my notes… one of the most common mistakes that people
>>>>> make doing file I/O with the native API is that they don’t realize that
>>>>> there’s no default directory provided for CreateFile. So, you always need
>>>>> to specify a fully qualified path name.
>>>>>
>>>>> Aside from THAT, and the fact that the NtReadFile and NtWriteFile
>>>>> default to asynchronous which I’m sure you know… I’m not really aware of
>>>>> any “tricks”…
>>>>>
>>>>> Peter
>>>>> OSR
>>>>> @OSRDrivers
>>>>>
>>>>> —
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> –
>>>> Jamey Kirby
>>>> Disrupting the establishment since 1964
>>>>
>>>> This is a personal email account and as such, emails are not subject
>>>> to archiving. Nothing else really matters.

>>>>
>>>
>>>
>>>
>>> –
>>> Jamey Kirby
>>> Disrupting the establishment since 1964
>>>
>>> This is a personal email account and as such, emails are not subject to
>>> archiving. Nothing else really matters.

>>>
>>
>>
>>
>> –
>> Jamey Kirby
>> Disrupting the establishment since 1964
>>
>> This is a personal email account and as such, emails are not subject to
>> archiving. Nothing else really matters.

>>
>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.

>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
</ntdef.h>

Nah… It’s not the “NT driver development list” it’s the “NT system software list”… And if programming to the native API is t system software almost by definition, I don’t know what is.

Peter
OSR
@OSRDrivers

Great.

Making excellent progress. I will post the code on my GitHub when I am
ready to share with everyone.

On Fri, Jul 3, 2015 at 5:46 PM, wrote:

> Nah… It’s not the “NT driver development list” it’s the “NT system
> software list”… And if programming to the native API is t system
> software almost by definition, I don’t know what is.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> 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
>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.