Share memory between driver(miniport driver) and win32 application

NTDEV
1

Hi
I’am trying to share memory between Win32 application and driver(miniport driver) to write/read data to a device.
I’am allocating memory in user and mapping it in to kernel miniport driver.

Steps i’am using while mapping user virtual address to kernel virtual address in driver:

  1. IoAllocateMdl(UserVirtualAddress, Length, NULL, FALSE, NULL);
  2. MmProbeAndLockPages(MDL, KernelMode, ReadAccess); //I’ll try using IoModifyAccess for both read and write
  3. MmMapLockedPagesSpecifyCache( ,KernelMode,…)

Steps while unmapping:

  1. MmUnmapLockedPages
  2. MmUnlockPages
  3. IOFreeMdl()

After mapping i’m getting Corresponding physical address using:

  1. MmGetPhysicalAddress;

I’m able to check the data integrity for write and read data buffer. So no doubt that i’m able to map user buffer to kernel and get data from driver to user application.

But i’am getting these errors…

  1. My MmProbeAndLockPages call follows try/except so in exception i’m getting below code…

Error exception 0xC00000A1
The working set is not big enough to allow the requested pages to be locked.
STATUS_WORKING_SET_QUOTA

  1. Sometime randomly i’m getting below crash

PROCESS_HAS_LOCKED_PAGES BSOD error

Mapping and unmapping are done in the miniport driver.

Note: I’m using IOCTL’s (IOCTL_SCSI_MINIPORT control code with METHOD_BUFFERED) to pass pointer to data buffer allocated in Win32 application and using DeviceIoctlControl().

Am i doing anything wrong here?

2

On Nov 24, 2017, at 12:46 PM, xxxxx@gmail.com wrote:
>
> But i’am getting these errors…
> 1. My MmProbeAndLockPages call follows try/except so in exception i’m getting below code…
>
> Error exception 0xC00000A1
> The working set is not big enough to allow the requested pages to be locked.
> STATUS_WORKING_SET_QUOTA

Exactly how large is the buffer? And who told you the length?

> 2. Sometime randomly i’m getting below crash
>
> PROCESS_HAS_LOCKED_PAGES BSOD error
>
> Mapping and unmapping are done in the miniport driver.

That suggests you are not unmapping everything you have mapped. Are you cleaning up when a process exits?

> Note: I’m using IOCTL’s (IOCTL_SCSI_MINIPORT control code with METHOD_BUFFERED) to pass pointer to data buffer allocated in Win32 application and using DeviceIoctlControl().
>
> Am i doing anything wrong here?

Almost certainly. Can you not define your own ioctl code using METHOD_IN_DIRECT and allow the system to do the page locking for you?
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Hi Tim,
Thanks for the reply.

Below are the answer to your questions…

>Exactly how large is the buffer? And who told you the length?

The buffer size is 4K for Random write/read and 128K for sequential write/read.

And regarding length, I’m passing transfer length in IOCTL structure as a data member. So whatever size i’ll allocate in application, that size value i’ll be able to access in driver.

>That suggests you are not unmapping everything you have mapped. Are you =
cleaning up when a process exits?

Yes i’m making ensure to clean up everything in the driver. At the time of crash, My application is running…

>Almost certainly. Can you not define your own ioctl code using =
METHOD_IN_DIRECT and allow the system to do the page locking for you?

Actually I’m trying to boost the driver performance so instead of variable size DataBuffer I’m passing the pointer to user allocated buffer in IOCTL structure and using that User virtual address to map to kernel virtual address. So my IOCTL’s structure size is very small. I’m doubting on data buffer size which is being copied on various driver stacks before reaching to miniport driver.

So any suggestion to boost the driver performance is appreciated.

Thanks,
Sudhanshu

4

I don’t think you are guaranteed to be in the calling application’s context in a storage miniport. That would explain the quota error as you are trying to map VA in a different process (and may the process exit with locked pages whole your app is running). Does a storage miniport have access to IRP_MJ_CREATE, CLEANUP, and CLOSE? If not, you will not be able to pull off this design.

d

Bent from my phone

From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Saturday, November 25, 2017 5:44:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Share memory between driver(miniport driver) and win32 application

Hi Tim,
Thanks for the reply.

Below are the answer to your questions…

>>Exactly how large is the buffer? And who told you the length?

The buffer size is 4K for Random write/read and 128K for sequential write/read.

And regarding length, I’m passing transfer length in IOCTL structure as a data member. So whatever size i’ll allocate in application, that size value i’ll be able to access in driver.

>>That suggests you are not unmapping everything you have mapped. Are you =
cleaning up when a process exits?

Yes i’m making ensure to clean up everything in the driver. At the time of crash, My application is running…

>>Almost certainly. Can you not define your own ioctl code using =
METHOD_IN_DIRECT and allow the system to do the page locking for you?

Actually I’m trying to boost the driver performance so instead of variable size DataBuffer I’m passing the pointer to user allocated buffer in IOCTL structure and using that User virtual address to map to kernel virtual address. So my IOCTL’s structure size is very small. I’m doubting on data buffer size which is being copied on various driver stacks before reaching to miniport driver.

So any suggestion to boost the driver performance is appreciated.

Thanks,
Sudhanshu

—
NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

5

A Storport does not have access to the IRP’s Doron enumerates. I wonder
if the OP has tested performance of the driver before going down this
rathole? Storports can be very efficient when tuned well.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Saturday, November 25, 2017 8:01 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Share memory between driver(miniport driver) and win32
application

I don’t think you are guaranteed to be in the calling application’s context
in a storage miniport. That would explain the quota error as you are trying
to map VA in a different process (and may the process exit with locked pages
whole your app is running). Does a storage miniport have access to
IRP_MJ_CREATE, CLEANUP, and CLOSE? If not, you will not be able to pull off
this design.

d

Bent from my phone
________________________________

From: xxxxx@lists.osr.com
on behalf of xxxxx@gmail.com
Sent: Saturday, November 25, 2017 5:44:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Share memory between driver(miniport driver) and win32
application

Hi Tim,
Thanks for the reply.

Below are the answer to your questions…

>>Exactly how large is the buffer? And who told you the length?

The buffer size is 4K for Random write/read and 128K for sequential
write/read.

And regarding length, I’m passing transfer length in IOCTL structure as a
data member. So whatever size i’ll allocate in application, that size value
i’ll be able to access in driver.

>>That suggests you are not unmapping everything you have mapped. Are you =
cleaning up when a process exits?

Yes i’m making ensure to clean up everything in the driver. At the time of
crash, My application is running…

>>Almost certainly. Can you not define your own ioctl code using =
METHOD_IN_DIRECT and allow the system to do the page locking for you?

Actually I’m trying to boost the driver performance so instead of variable
size DataBuffer I’m passing the pointer to user allocated buffer in IOCTL
structure and using that User virtual address to map to kernel virtual
address. So my IOCTL’s structure size is very small. I’m doubting on data
buffer size which is being copied on various driver stacks before reaching
to miniport driver.

So any suggestion to boost the driver performance is appreciated.

Thanks,
Sudhanshu

—
NTDEV is sponsored by OSR

Visit the list online at:
https:ne.com%2Fshowlists.cfm%3Flist%3Dntdev&data=02%7C01%7CDoron.Holan%40microsoft
.com%7C7056ad89f99c425246a308d533f18edf%7C72f988bf86f141af91ab2d7cd011db47%7
C1%7C0%7C636472034934003518&sdata=fGU5BpftzvZbmdJXYPO451Mm6TDENjTan7EJlXHwBG
Q%3D&reserved=0>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at
https:%2Fseminars&data=02%7C01%7CDoron.Holan%40microsoft.com%7C7056ad89f99c425246a
308d533f18edf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63647203493400351
8&sdata=MAuPMYFfqLCaai5A3wVdwvA2VgibFlehXdl2d8UvPSY%3D&reserved=0>

To unsubscribe, visit the List Server section of OSR Online at
https:ne.com%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7CDoron.Holan%40microsoft
.com%7C7056ad89f99c425246a308d533f18edf%7C72f988bf86f141af91ab2d7cd011db47%7
C1%7C0%7C636472034934003518&sdata=lU1priGRUJ8Pzs4sDWZSc8BkiraYj%2BYwGVGR925Y
xqs%3D&reserved=0>

—
NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:></https:></https:></https:>

6

On Nov 25, 2017, at 2:44 AM, xxxxx@gmail.com wrote:
>
>>> Almost certainly. Can you not define your own ioctl code using =
> METHOD_IN_DIRECT and allow the system to do the page locking for you?
>
> Actually I’m trying to boost the driver performance so instead of variable size DataBuffer I’m passing the pointer to user allocated buffer in IOCTL structure and using that User virtual address to map to kernel virtual address. So my IOCTL’s structure size is very small. I’m doubting on data buffer size which is being copied on various driver stacks before reaching to miniport driver.

I hope you are not trying to argue that passing an address and length in a buffered ioctl will have higher performance than using METHOD_IN_DIRECT and allowing operating system code that has been optimized over 20 years do the exact same thing.

> So any suggestion to boost the driver performance is appreciated.

You haven’t told us what part of your performance bothers you. Have you actually done benchmarks to establish the actual performance? And what leads you to believe the performance CAN be improved?
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

Thank you all very much for the replies.

>> Almost certainly. Can you not define your own ioctl code using =3D
METHOD_IN_DIRECT and allow the system to do the page locking for you?
=20
Actually I’m trying to boost the driver performance so instead of =
variable size DataBuffer I’m passing the pointer to user allocated =
buffer in IOCTL structure and using that User virtual address to map to =
kernel virtual address. So my IOCTL’s structure size is very small. I’m =
doubting on data buffer size which is being copied on various driver =
stacks before reaching to miniport driver.

>>>I hope you are not trying to argue that passing an address and length in =
a buffered ioctl will have higher performance than using =
METHOD_IN_DIRECT and allowing operating system code that has been =
optimized over 20 years do the exact same thing.

No, I’m not arguing about this. The problem here is that I can’t use METHOD_XX_DIRECT for IOCTL_SCSI_MINIPORT.

As I said in my question as a Note part that I’m using IOCTL_SCSI_MINIPORT and it’s Buffered IO. If I change it to METHOD_XX_DIRECT then the control code is no longer IOCTL_SCSI_MINIPORT and it won’t be understood by the port driver.

So the other ways to use METHOD_XX_DIRECT is:

  1. IOCTL_SCSI_PASS_THROUGH_DIRECT instead of IOCTL_SCSI_MINIPORT.
    But here also in this case I can see it’s method used is METHOD_BUFFERED.
    #define IOCTL_SCSI_PASS_THROUGH_DIRECT CTL_CODE(IOCTL_SCSI_BASE, 0x0405, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

Now my querry is if I use IOCTL_SCSI_PASS_THROUGH_DIRECT then what’s the method used here…?? Internally it also uses buffered method. Am I right…???

Even if METHOD_XX_DIRECT is used then MSDN Link: (https://msdn.microsoft.com/en-us/library/windows/hardware/ff560521(v=vs.85).aspx)
says, this (IOCTL_SCSI_PASS_THROUGH_DIRECT) request is typically used for transferring larger amounts of data (>16K).

But in my case lagging is more in Random Write/Read case which is 4K in size. So no chances for improvement here.

One more thing I found regarding Direct Io on MSDN Link: (https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-direct-i-o)
[[Drivers that use direct I/O will sometimes also use buffered I/O to handle some IRPs.
In particular, drivers typically use buffered I/O for some I/O control codes for IRP_MJ_DEVICE_CONTROL requests that require data transfers,
regardless of whether the driver uses direct I/O for read and write operations.]]

According to above documentation, Direct Io is not guaranteed even if we use METHOD_XX_DIRECT. Correct if I’m wrong…

Almost certainly. Can you not define your own ioctl code using =
METHOD_IN_DIRECT and allow the system to do the page locking for you?

> Second method as suggested by Tim Roberts

  1. Custom Control Code.
    Here I’m not sure if a Custom Control Code might work with miniport driver.
    Any help related how to use Custom Control Code with miniport driver would be appreciated.

So any suggestion to boost the driver performance is appreciated.

>>>You haven’t told us what part of your performance bothers you. Have you =
actually done benchmarks to establish the actual performance? And what =
leads you to believe the performance CAN be improved?

For benchmarks testing, I’m using IoMeter. I’ve taken the performance measurement with IoMeter and found that performance is low as compared to Standard Inbox Driver.
For sequential, difference is negligible but Lagging is more in Random Write/Read around 20%.

Alongwith I’m using my own Win32 application. It uses DeviceIoControl with IOCTL_SCSI_MINIPORT control code.
I found very poor performance with my application as compared to IoMeter.

With my Win32 Application, performance measurement difference is very high. Around 15% in case of sequential and in case of Random Read it’s 20% and Random Write 40%.

Is it the correct way to compare performance measurement taken with a custom Win32 application using DeviceIoControl which follows IOCTL_SCSI_MINIPORT path with IoMeter…??
IoMeter uses ReadFile and WriteFile Windows API but my application follows IOCTL_SCSI_MINIPORT path…

Thanks again for everyone’s help…
Sudhanshu

8

Create a system thread in the context of your user-mode process. You can
set this up in your ServiceRequest callback. When your thread runs, you
will have full access to memory and handles in your um process.

On Sun, Nov 26, 2017, 7:18 AM xxxxx@gmail.com
wrote:

> Thank you all very much for the replies.
>
> >>> Almost certainly. Can you not define your own ioctl code using =3D
> > METHOD_IN_DIRECT and allow the system to do the page locking for you?
> >=20
> > Actually I’m trying to boost the driver performance so instead of =
> variable size DataBuffer I’m passing the pointer to user allocated =
> buffer in IOCTL structure and using that User virtual address to map to =
> kernel virtual address. So my IOCTL’s structure size is very small. I’m =
> doubting on data buffer size which is being copied on various driver =
> stacks before reaching to miniport driver.
>
> >>>>I hope you are not trying to argue that passing an address and length
> in =
> a buffered ioctl will have higher performance than using =
> METHOD_IN_DIRECT and allowing operating system code that has been =
> optimized over 20 years do the exact same thing.
>
> No, I’m not arguing about this. The problem here is that I can’t use
> METHOD_XX_DIRECT for IOCTL_SCSI_MINIPORT.
>
> As I said in my question as a Note part that I’m using IOCTL_SCSI_MINIPORT
> and it’s Buffered IO. If I change it to METHOD_XX_DIRECT then the control
> code is no longer IOCTL_SCSI_MINIPORT and it won’t be understood by the
> port driver.
>
> So the other ways to use METHOD_XX_DIRECT is:
>
> 1. IOCTL_SCSI_PASS_THROUGH_DIRECT instead of IOCTL_SCSI_MINIPORT.
> But here also in this case I can see it’s method used is
> METHOD_BUFFERED.
> #define IOCTL_SCSI_PASS_THROUGH_DIRECT CTL_CODE(IOCTL_SCSI_BASE,
> 0x0405, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
>
> Now my querry is if I use IOCTL_SCSI_PASS_THROUGH_DIRECT then what’s
> the method used here…?? Internally it also uses buffered method. Am I
> right…???
>
> Even if METHOD_XX_DIRECT is used then MSDN Link: (
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff560521(v=vs.85).aspx
> )
> says, this (IOCTL_SCSI_PASS_THROUGH_DIRECT) request is typically used
> for transferring larger amounts of data (>16K).
>
> But in my case lagging is more in Random Write/Read case which is 4K in
> size. So no chances for improvement here.
>
> One more thing I found regarding Direct Io on MSDN Link: (
> https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-direct-i-o
> )
> [[Drivers that use direct I/O will sometimes also use buffered I/O to
> handle some IRPs.
> In particular, drivers typically use buffered I/O for some I/O control
> codes for IRP_MJ_DEVICE_CONTROL requests that require data transfers,
> regardless of whether the driver uses direct I/O for read and write
> operations.]]
>
> According to above documentation, Direct Io is not guaranteed even if
> we use METHOD_XX_DIRECT. Correct if I’m wrong…
>
> > Almost certainly. Can you not define your own ioctl code using =
> METHOD_IN_DIRECT and allow the system to do the page locking for you?
>
> >> Second method as suggested by Tim Roberts
> 2. Custom Control Code.
> Here I’m not sure if a Custom Control Code might work with miniport
> driver.
> Any help related how to use Custom Control Code with miniport driver
> would be appreciated.
>
> > So any suggestion to boost the driver performance is appreciated.
>
> >>>>You haven’t told us what part of your performance bothers you. Have
> you =
> actually done benchmarks to establish the actual performance? And what =
> leads you to believe the performance CAN be improved?
>
> For benchmarks testing, I’m using IoMeter. I’ve taken the performance
> measurement with IoMeter and found that performance is low as compared to
> Standard Inbox Driver.
> For sequential, difference is negligible but Lagging is more in Random
> Write/Read around 20%.
>
> Alongwith I’m using my own Win32 application. It uses DeviceIoControl with
> IOCTL_SCSI_MINIPORT control code.
> I found very poor performance with my application as compared to IoMeter.
>
> With my Win32 Application, performance measurement difference is very
> high. Around 15% in case of sequential and in case of Random Read it’s 20%
> and Random Write 40%.
>
> Is it the correct way to compare performance measurement taken with a
> custom Win32 application using DeviceIoControl which follows
> IOCTL_SCSI_MINIPORT path with IoMeter…??
> IoMeter uses ReadFile and WriteFile Windows API but my application follows
> IOCTL_SCSI_MINIPORT path…
>
> Thanks again for everyone’s help…
> Sudhanshu
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

9

If performance is low compared to the inbox driver, then take a serious look
at your miniport. I suspect you have the request handling or the locking
wrong use xperf to look at what the heck your driver is doing.

I’ve never seen an approach of rolling your own that works well with
IOCTL_SCSI_MINIPORT from user space. Unless you are doing stuff up along
the storage stack (i.e. filter drivers, or your own stack) and typically
this is with a custom I/O model (for instance a video file system that used
block sizes of 1MB or larger) you are not going to get the performance.

Bottom line, your driver has problems fix the driver, don’t try to code
around it.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Sunday, November 26, 2017 7:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Share memory between driver(miniport driver) and win32
application

Thank you all very much for the replies.

>>> Almost certainly. Can you not define your own ioctl code using =3D
> METHOD_IN_DIRECT and allow the system to do the page locking for you?
>=20
> Actually I’m trying to boost the driver performance so instead of =
variable size DataBuffer I’m passing the pointer to user allocated =
buffer in IOCTL structure and using that User virtual address to map to =
kernel virtual address. So my IOCTL’s structure size is very small. I’m =
doubting on data buffer size which is being copied on various driver =
stacks before reaching to miniport driver.

>>>>I hope you are not trying to argue that passing an address and length in
=
a buffered ioctl will have higher performance than using =
METHOD_IN_DIRECT and allowing operating system code that has been =
optimized over 20 years do the exact same thing.

No, I’m not arguing about this. The problem here is that I can’t use
METHOD_XX_DIRECT for IOCTL_SCSI_MINIPORT.

As I said in my question as a Note part that I’m using IOCTL_SCSI_MINIPORT
and it’s Buffered IO. If I change it to METHOD_XX_DIRECT then the control
code is no longer IOCTL_SCSI_MINIPORT and it won’t be understood by the port
driver.

So the other ways to use METHOD_XX_DIRECT is:

1. IOCTL_SCSI_PASS_THROUGH_DIRECT instead of IOCTL_SCSI_MINIPORT.
But here also in this case I can see it’s method used is METHOD_BUFFERED.
#define IOCTL_SCSI_PASS_THROUGH_DIRECT CTL_CODE(IOCTL_SCSI_BASE, 0x0405,
METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

Now my querry is if I use IOCTL_SCSI_PASS_THROUGH_DIRECT then what’s the
method used here…?? Internally it also uses buffered method. Am I
right…???

Even if METHOD_XX_DIRECT is used then MSDN Link:
(https://msdn.microsoft.com/en-us/library/windows/hardware/ff560521(v=vs.85)
.aspx)
says, this (IOCTL_SCSI_PASS_THROUGH_DIRECT) request is typically used for
transferring larger amounts of data (>16K).

But in my case lagging is more in Random Write/Read case which is 4K in
size. So no chances for improvement here.

One more thing I found regarding Direct Io on MSDN Link:
(https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-dire
ct-i-o)
[[Drivers that use direct I/O will sometimes also use buffered I/O to
handle some IRPs.
In particular, drivers typically use buffered I/O for some I/O control
codes for IRP_MJ_DEVICE_CONTROL requests that require data transfers,
regardless of whether the driver uses direct I/O for read and write
operations.]]

According to above documentation, Direct Io is not guaranteed even if we
use METHOD_XX_DIRECT. Correct if I’m wrong…

> Almost certainly. Can you not define your own ioctl code using =
METHOD_IN_DIRECT and allow the system to do the page locking for you?

>> Second method as suggested by Tim Roberts
2. Custom Control Code.
Here I’m not sure if a Custom Control Code might work with miniport
driver.
Any help related how to use Custom Control Code with miniport driver
would be appreciated.

> So any suggestion to boost the driver performance is appreciated.

>>>>You haven’t told us what part of your performance bothers you. Have you
=
actually done benchmarks to establish the actual performance? And what =
leads you to believe the performance CAN be improved?

For benchmarks testing, I’m using IoMeter. I’ve taken the performance
measurement with IoMeter and found that performance is low as compared to
Standard Inbox Driver.
For sequential, difference is negligible but Lagging is more in Random
Write/Read around 20%.

Alongwith I’m using my own Win32 application. It uses DeviceIoControl with
IOCTL_SCSI_MINIPORT control code.
I found very poor performance with my application as compared to IoMeter.

With my Win32 Application, performance measurement difference is very high.
Around 15% in case of sequential and in case of Random Read it’s 20% and
Random Write 40%.

Is it the correct way to compare performance measurement taken with a
custom Win32 application using DeviceIoControl which follows
IOCTL_SCSI_MINIPORT path with IoMeter…??
IoMeter uses ReadFile and WriteFile Windows API but my application follows
IOCTL_SCSI_MINIPORT path…

Thanks again for everyone’s help…
Sudhanshu

—
NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

10

Creating a system thread in a non-system process is generally not recommended. Doing so may create situations that you may be ill-equipped to handle, such as ensuring that something reasonable happens if somebody attempts to terminate your process (perhaps due to a user mode crash), as well as ensuring that various ?environmental? characteristics of the owning process (security context etc.) do not interfere with forward progress of your thread.

Getting this right is tricky and the rules are not all particularly well defined. It is very easy to introduce subtle security or correctness problems that may not be caught in basic testing. System threads in the system process are shielded from many gotchas that you would otherwise not need to be concerned about.

  • S (Msft)

From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Sunday, November 26, 2017 5:06:00 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Share memory between driver(miniport driver) and win32 application

Create a system thread in the context of your user-mode process. You can set this up in your ServiceRequest callback. When your thread runs, you will have full access to memory and handles in your um process.

On Sun, Nov 26, 2017, 7:18 AM xxxxx@gmail.commailto:xxxxx > wrote:
Thank you all very much for the replies.

>>> Almost certainly. Can you not define your own ioctl code using =3D
> METHOD_IN_DIRECT and allow the system to do the page locking for you?
>=20
> Actually I’m trying to boost the driver performance so instead of =
variable size DataBuffer I’m passing the pointer to user allocated =
buffer in IOCTL structure and using that User virtual address to map to =
kernel virtual address. So my IOCTL’s structure size is very small. I’m =
doubting on data buffer size which is being copied on various driver =
stacks before reaching to miniport driver.

>>>>I hope you are not trying to argue that passing an address and length in =
a buffered ioctl will have higher performance than using =
METHOD_IN_DIRECT and allowing operating system code that has been =
optimized over 20 years do the exact same thing.

No, I’m not arguing about this. The problem here is that I can’t use METHOD_XX_DIRECT for IOCTL_SCSI_MINIPORT.

As I said in my question as a Note part that I’m using IOCTL_SCSI_MINIPORT and it’s Buffered IO. If I change it to METHOD_XX_DIRECT then the control code is no longer IOCTL_SCSI_MINIPORT and it won’t be understood by the port driver.

So the other ways to use METHOD_XX_DIRECT is:

1. IOCTL_SCSI_PASS_THROUGH_DIRECT instead of IOCTL_SCSI_MINIPORT.
But here also in this case I can see it’s method used is METHOD_BUFFERED.
#define IOCTL_SCSI_PASS_THROUGH_DIRECT CTL_CODE(IOCTL_SCSI_BASE, 0x0405, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

Now my querry is if I use IOCTL_SCSI_PASS_THROUGH_DIRECT then what’s the method used here…?? Internally it also uses buffered method. Am I right…???

Even if METHOD_XX_DIRECT is used then MSDN Link: (https://msdn.microsoft.com/en-us/library/windows/hardware/ff560521(v=vs.85).aspxhttps:)
says, this (IOCTL_SCSI_PASS_THROUGH_DIRECT) request is typically used for transferring larger amounts of data (>16K).

But in my case lagging is more in Random Write/Read case which is 4K in size. So no chances for improvement here.

One more thing I found regarding Direct Io on MSDN Link: (https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-direct-i-ohttps:)
[[Drivers that use direct I/O will sometimes also use buffered I/O to handle some IRPs.
In particular, drivers typically use buffered I/O for some I/O control codes for IRP_MJ_DEVICE_CONTROL requests that require data transfers,
regardless of whether the driver uses direct I/O for read and write operations.]]

According to above documentation, Direct Io is not guaranteed even if we use METHOD_XX_DIRECT. Correct if I’m wrong…

> Almost certainly. Can you not define your own ioctl code using =
METHOD_IN_DIRECT and allow the system to do the page locking for you?

>> Second method as suggested by Tim Roberts
2. Custom Control Code.
Here I’m not sure if a Custom Control Code might work with miniport driver.
Any help related how to use Custom Control Code with miniport driver would be appreciated.

> So any suggestion to boost the driver performance is appreciated.

>>>>You haven’t told us what part of your performance bothers you. Have you =
actually done benchmarks to establish the actual performance? And what =
leads you to believe the performance CAN be improved?

For benchmarks testing, I’m using IoMeter. I’ve taken the performance measurement with IoMeter and found that performance is low as compared to Standard Inbox Driver.
For sequential, difference is negligible but Lagging is more in Random Write/Read around 20%.

Alongwith I’m using my own Win32 application. It uses DeviceIoControl with IOCTL_SCSI_MINIPORT control code.
I found very poor performance with my application as compared to IoMeter.

With my Win32 Application, performance measurement difference is very high. Around 15% in case of sequential and in case of Random Read it’s 20% and Random Write 40%.

Is it the correct way to compare performance measurement taken with a custom Win32 application using DeviceIoControl which follows IOCTL_SCSI_MINIPORT path with IoMeter…??
IoMeter uses ReadFile and WriteFile Windows API but my application follows IOCTL_SCSI_MINIPORT path…

Thanks again for everyone’s help…
Sudhanshu

—
NTDEV is sponsored by OSR

Visit the list online at: http:>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:>

To unsubscribe, visit the List Server section of OSR Online at http:>
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></https:></https:></mailto:xxxxx>

11

>Creating a system thread in a non-system process is generally not recommended.

This.

Beat me to it.

Peter
OSR