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>