GetQueuedCompletionStatus returns Error 122

NTFSD
1

Folks,

I am trying out the scanner sample, and have made some modifications to it,
in my case the Message to the user is of constant length (that is there is
no buffer in it) and the user returns me a buffer filled with data. (this
is some sort of a reflector driver scenario where the kernel requests the
user with some data offlet and length and the user code fetches the data
from the source and furnishes the kernel with a buffer).

The problem is I constantly am getting error 122 from the API

GetQueuedCompletionStatus()

122 stands for “The data area passed to a system call is too small.”

This at first seemed very simple, but unfortunately I haven’t found out why
it complains.

Here are the structures with relevant parts of code:

In the worker thread:

bRes = GetQueuedCompletionStatus( pTPCtx->hCompletion,
&outSize,
&key,
&pOvlp,
INFINITE );

pMessage = CONTAINING_RECORD( pOvlp,
MY_REQUEST_TO_USERLAND_MESSAGE, Ovlp );

where MY_REQUEST_TO_USERLAND_MESSAGE is defined as:

typedef struct _MY_REQUEST_TO_USERLAND_MESSAGE {

FILTER_MESSAGE_HEADER MessageHeader;
MY_TRANSLATE_CONTEXT TranslationRequest;
OVERLAPPED Ovlp;
} MY_REQUEST_TO_USERLAND_MESSAGE, *PMY_REQUEST_TO_USERLAND_MESSAGE;

and MY_TRANSLATE_CONTEXT is :

typedef struct _MY_TRANSLATE_CONTEXT {

ULONGLONG uOffset;
ULONGLONG uLen;

} MY_TRANSLATE_CONTEXT, *PMY_TRANSLATE_CONTEXT;

Here is how in the driver I allocate for these structures:

ULONG uLenMsgToUser = sizeof(FILTER_MESSAGE_HEADER) +
sizeof(MY_TRANSLATE_CONTEXT) + sizeof(OVERLAPPED);
pMsgToUser =
(PMY_REQUEST_TO_USERLAND_MESSAGE)MyAllocateMemory(NonPagedPool,

uLenMsgToUser,

MY_READOP_POOL_TAG);

RtlZeroMemory(pMsgToUser, uLenMsgToUser);

pMsgToUser->TranslationRequest.uLen = TransCtx.uLen;
pMsgToUser->TranslationRequest.uOffset = TransCtx.uOffset;

ULONG uReplyLength = sizeof(FILTER_REPLY_HEADER) + sizeof(MY_REPLY_CONTEXT)

  • TransCtx.uLen;

pReplyMsgFromUser = (PMY_REPLY_FROM_USERLAND_MESSAGE)MyAllocateMemory(
NonPagedPool,

uReplyLength,

MY_READOP_POOL_TAG);

RtlZeroMemory(pReplyMsgFromUser, uReplyLength);

status = FltSendMessage( g_MyData.Filter,
&g_MyData.ClientPort,
pMsgToUser,
uLenMsgToUser,
pReplyMsgFromUser,
&uReplyLength,
NULL );

I am unable to figure out why the user land thread complains. Can some one
please help…

regards

ami

2

Here’s the length you’re sending from kernel mode:

ULONG uLenMsgToUser = sizeof(FILTER_MESSAGE_HEADER) +
sizeof(MY_TRANSLATE_CONTEXT) + sizeof(OVERLAPPED);

What size do you pass to FilterGetMessage? Do you really include the size of
the overlapped structure?

-scott
OSR

“Ami Awbadhho” wrote in message news:xxxxx@ntfsd…
Folks,

I am trying out the scanner sample, and have made some modifications to it,
in my case the Message to the user is of constant length (that is there is
no buffer in it) and the user returns me a buffer filled with data. (this is
some sort of a reflector driver scenario where the kernel requests the user
with some data offlet and length and the user code fetches the data from the
source and furnishes the kernel with a buffer).

The problem is I constantly am getting error 122 from the API

GetQueuedCompletionStatus()

122 stands for “The data area passed to a system call is too small.”

This at first seemed very simple, but unfortunately I haven’t found out why
it complains.

Here are the structures with relevant parts of code:

In the worker thread:

bRes = GetQueuedCompletionStatus( pTPCtx->hCompletion,
&outSize,
&key,
&pOvlp,
INFINITE );

pMessage = CONTAINING_RECORD( pOvlp, MY_REQUEST_TO_USERLAND_MESSAGE,
Ovlp );

where MY_REQUEST_TO_USERLAND_MESSAGE is defined as:

typedef struct _MY_REQUEST_TO_USERLAND_MESSAGE {

FILTER_MESSAGE_HEADER MessageHeader;
MY_TRANSLATE_CONTEXT TranslationRequest;
OVERLAPPED Ovlp;
} MY_REQUEST_TO_USERLAND_MESSAGE, *PMY_REQUEST_TO_USERLAND_MESSAGE;

and MY_TRANSLATE_CONTEXT is :

typedef struct _MY_TRANSLATE_CONTEXT {

ULONGLONG uOffset;
ULONGLONG uLen;

} MY_TRANSLATE_CONTEXT, *PMY_TRANSLATE_CONTEXT;

Here is how in the driver I allocate for these structures:

ULONG uLenMsgToUser = sizeof(FILTER_MESSAGE_HEADER) +
sizeof(MY_TRANSLATE_CONTEXT) + sizeof(OVERLAPPED);
pMsgToUser =
(PMY_REQUEST_TO_USERLAND_MESSAGE)MyAllocateMemory(NonPagedPool,
uLenMsgToUser,
MY_READOP_POOL_TAG);

RtlZeroMemory(pMsgToUser, uLenMsgToUser);

pMsgToUser->TranslationRequest.uLen = TransCtx.uLen;
pMsgToUser->TranslationRequest.uOffset = TransCtx.uOffset;

ULONG uReplyLength = sizeof(FILTER_REPLY_HEADER) + sizeof(MY_REPLY_CONTEXT)
+ TransCtx.uLen;

pReplyMsgFromUser = (PMY_REPLY_FROM_USERLAND_MESSAGE)MyAllocateMemory(
NonPagedPool,
uReplyLength,
MY_READOP_POOL_TAG);

RtlZeroMemory(pReplyMsgFromUser, uReplyLength);

status = FltSendMessage( g_MyData.Filter,
&g_MyData.ClientPort,
pMsgToUser,
uLenMsgToUser,
pReplyMsgFromUser,
&uReplyLength,
NULL );

I am unable to figure out why the user land thread complains. Can some one
please help…

regards

ami

3

ami,

I think this is not the way it is designed to be performed. here is what I
think (and understand from the docs).

The scanner sample embeds the private portion (the one the programmer needs
to pass to the user land) of the structure in a larger structure which
contains the FILTER_MESSAGE_HEADER so that it is easier to access the
elements later on. Since this is the final structure the user mode *will*
see.

This doesn’t mean one needs to allocate memory for the whole structure. One
only needs to do so for his portion (private portion) of it. hence scanner
sample only does so.

The correct way to send a message (assuming your design and structure
definitions) would be something like:

MY_TRANSLATE_CONTEXT TxCtx; // Note this is member on the stack
not dynamic at all

PMY_REPLY_FROM_USERLAND_MESSAGE pReplyMsgFromUser = NULL;

ULONG uLenMsgToUser = sizeof(MY_TRANSLATE_CONTEXT) ;

RtlZeroMemory(&TxCtx, uLenMsgToUser);

//Fill up the context with what ever is the data here

// Also create a reply message accordingly (I am skipping that part)

status = FltSendMessage( g_MYData.Filter,
&g_MYData.ClientPort,
&TxCtx,
uLenMsgToUser,
the reply pointer goes here,
reply length goes here,
NULL );

Try this out and let us know if it works…

AB

On Mon, Apr 22, 2013 at 10:14 PM, Ami Awbadhho wrote:

> Folks,
>
> I am trying out the scanner sample, and have made some modifications to
> it, in my case the Message to the user is of constant length (that is there
> is no buffer in it) and the user returns me a buffer filled with data.
> (this is some sort of a reflector driver scenario where the kernel requests
> the user with some data offlet and length and the user code fetches the
> data from the source and furnishes the kernel with a buffer).
>
> The problem is I constantly am getting error 122 from the API
>
> GetQueuedCompletionStatus()
>
>
> 122 stands for “The data area passed to a system call is too small.”
>
> This at first seemed very simple, but unfortunately I haven’t found out
> why it complains.
>
> Here are the structures with relevant parts of code:
>
> In the worker thread:
>
>
> bRes = GetQueuedCompletionStatus( pTPCtx->hCompletion,
> &outSize,
> &key,
> &pOvlp,
> INFINITE );
>
>
> pMessage = CONTAINING_RECORD( pOvlp,
> MY_REQUEST_TO_USERLAND_MESSAGE, Ovlp );
>
> where MY_REQUEST_TO_USERLAND_MESSAGE is defined as:
>
> typedef struct _MY_REQUEST_TO_USERLAND_MESSAGE {
>
> FILTER_MESSAGE_HEADER MessageHeader;
> MY_TRANSLATE_CONTEXT TranslationRequest;
> OVERLAPPED Ovlp;
> } MY_REQUEST_TO_USERLAND_MESSAGE, *PMY_REQUEST_TO_USERLAND_MESSAGE;
>
> and MY_TRANSLATE_CONTEXT is :
>
> typedef struct _MY_TRANSLATE_CONTEXT {
>
> ULONGLONG uOffset;
> ULONGLONG uLen;
>
> } MY_TRANSLATE_CONTEXT, *PMY_TRANSLATE_CONTEXT;
>
>
> Here is how in the driver I allocate for these structures:
>
> ULONG uLenMsgToUser = sizeof(FILTER_MESSAGE_HEADER) +
> sizeof(MY_TRANSLATE_CONTEXT) + sizeof(OVERLAPPED);
> pMsgToUser =
> (PMY_REQUEST_TO_USERLAND_MESSAGE)MyAllocateMemory(NonPagedPool,
>
> uLenMsgToUser,
>
> MY_READOP_POOL_TAG);
>
>
>
> RtlZeroMemory(pMsgToUser, uLenMsgToUser);
>
> pMsgToUser->TranslationRequest.uLen = TransCtx.uLen;
> pMsgToUser->TranslationRequest.uOffset = TransCtx.uOffset;
>
>
> ULONG uReplyLength = sizeof(FILTER_REPLY_HEADER) +
> sizeof(MY_REPLY_CONTEXT) + TransCtx.uLen;
>
>
> pReplyMsgFromUser = (PMY_REPLY_FROM_USERLAND_MESSAGE)MyAllocateMemory(
> NonPagedPool,
>
> uReplyLength,
>
> MY_READOP_POOL_TAG);
>
>
> RtlZeroMemory(pReplyMsgFromUser, uReplyLength);
>
> status = FltSendMessage( g_MyData.Filter,
> &g_MyData.ClientPort,
> pMsgToUser,
> uLenMsgToUser,
> pReplyMsgFromUser,
> &uReplyLength,
> NULL );
>
>
>
>
> I am unable to figure out why the user land thread complains. Can some one
> please help…
>
> regards
>
> ami
>
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file system
> 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

–

- ab

4

AB,

This works and explains what i ws doing wrong. thanks!

On Wed, Apr 24, 2013 at 10:31 PM, A B wrote:

> ami,
>
> I think this is not the way it is designed to be performed. here is what I
> think (and understand from the docs).
>
> The scanner sample embeds the private portion (the one the programmer
> needs to pass to the user land) of the structure in a larger structure
> which contains the FILTER_MESSAGE_HEADER so that it is easier to access
> the elements later on. Since this is the final structure the user mode
> will see.
>
> This doesn’t mean one needs to allocate memory for the whole structure.
> One only needs to do so for his portion (private portion) of it. hence
> scanner sample only does so.
>
> The correct way to send a message (assuming your design and structure
> definitions) would be something like:
>
> MY_TRANSLATE_CONTEXT TxCtx; // Note this is member on the
> stack not dynamic at all
>
>
> PMY_REPLY_FROM_USERLAND_MESSAGE pReplyMsgFromUser = NULL;
>
> ULONG uLenMsgToUser = sizeof(MY_TRANSLATE_CONTEXT) ;
>
> RtlZeroMemory(&TxCtx, uLenMsgToUser);
>
> //Fill up the context with what ever is the data here
>
> // Also create a reply message accordingly (I am skipping that part)
>
>
>
> status = FltSendMessage( g_MYData.Filter,
> &g_MYData.ClientPort,
> &TxCtx,
> uLenMsgToUser,
> the reply pointer goes here,
> reply length goes here,
> NULL );
>
>
> Try this out and let us know if it works…
>
> AB
>
>
> On Mon, Apr 22, 2013 at 10:14 PM, Ami Awbadhho wrote:
>
>> Folks,
>>
>> I am trying out the scanner sample, and have made some modifications to
>> it, in my case the Message to the user is of constant length (that is there
>> is no buffer in it) and the user returns me a buffer filled with data.
>> (this is some sort of a reflector driver scenario where the kernel requests
>> the user with some data offlet and length and the user code fetches the
>> data from the source and furnishes the kernel with a buffer).
>>
>> The problem is I constantly am getting error 122 from the API
>>
>> GetQueuedCompletionStatus()
>>
>>
>> 122 stands for “The data area passed to a system call is too small.”
>>
>> This at first seemed very simple, but unfortunately I haven’t found out
>> why it complains.
>>
>> Here are the structures with relevant parts of code:
>>
>> In the worker thread:
>>
>>
>> bRes = GetQueuedCompletionStatus( pTPCtx->hCompletion,
>> &outSize,
>> &key,
>> &pOvlp,
>> INFINITE );
>>
>>
>> pMessage = CONTAINING_RECORD( pOvlp,
>> MY_REQUEST_TO_USERLAND_MESSAGE, Ovlp );
>>
>> where MY_REQUEST_TO_USERLAND_MESSAGE is defined as:
>>
>> typedef struct _MY_REQUEST_TO_USERLAND_MESSAGE {
>>
>> FILTER_MESSAGE_HEADER MessageHeader;
>> MY_TRANSLATE_CONTEXT TranslationRequest;
>> OVERLAPPED Ovlp;
>> } MY_REQUEST_TO_USERLAND_MESSAGE, *PMY_REQUEST_TO_USERLAND_MESSAGE;
>>
>> and MY_TRANSLATE_CONTEXT is :
>>
>> typedef struct _MY_TRANSLATE_CONTEXT {
>>
>> ULONGLONG uOffset;
>> ULONGLONG uLen;
>>
>> } MY_TRANSLATE_CONTEXT, *PMY_TRANSLATE_CONTEXT;
>>
>>
>> Here is how in the driver I allocate for these structures:
>>
>> ULONG uLenMsgToUser = sizeof(FILTER_MESSAGE_HEADER) +
>> sizeof(MY_TRANSLATE_CONTEXT) + sizeof(OVERLAPPED);
>> pMsgToUser =
>> (PMY_REQUEST_TO_USERLAND_MESSAGE)MyAllocateMemory(NonPagedPool,
>>
>> uLenMsgToUser,
>>
>> MY_READOP_POOL_TAG);
>>
>>
>>
>> RtlZeroMemory(pMsgToUser, uLenMsgToUser);
>>
>> pMsgToUser->TranslationRequest.uLen = TransCtx.uLen;
>> pMsgToUser->TranslationRequest.uOffset = TransCtx.uOffset;
>>
>>
>> ULONG uReplyLength = sizeof(FILTER_REPLY_HEADER) +
>> sizeof(MY_REPLY_CONTEXT) + TransCtx.uLen;
>>
>>
>> pReplyMsgFromUser = (PMY_REPLY_FROM_USERLAND_MESSAGE)MyAllocateMemory(
>> NonPagedPool,
>>
>> uReplyLength,
>>
>> MY_READOP_POOL_TAG);
>>
>>
>> RtlZeroMemory(pReplyMsgFromUser, uReplyLength);
>>
>> status = FltSendMessage( g_MyData.Filter,
>> &g_MyData.ClientPort,
>> pMsgToUser,
>> uLenMsgToUser,
>> pReplyMsgFromUser,
>> &uReplyLength,
>> NULL );
>>
>>
>>
>>
>> I am unable to figure out why the user land thread complains. Can some
>> one please help…
>>
>> regards
>>
>> ami
>>
>> — NTFSD is sponsored by OSR OSR is hiring!! Info at
>> http://www.osr.com/careers For our schedule of debugging and file system
>> 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
>>
>
>
>
> –
>
> - ab
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file system
> 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
>