Ioctl buffer size

extredo · February 6, 2011, 9:21am

HI,

Could you please answer on following questions.

Environment Win7 x86
WDK version: 7600.16385.1

I write driver on kernel mode.User-mode application uses ioctl call to request data from driver.
I called ioctl periodically with 3 second interval from user application.

Here is my ioctl driver implementation:

NTSTATUS
IoctlDeviceControl(
PDEVICE_OBJECT DeviceObject,
PIRP Irp
)
{
PIO_STACK_LOCATION irpSp;
NTSTATUS ntStatus = STATUS_SUCCESS;
ULONG inBufLength;
ULONG outBufLength;
PCHAR inBuf;
PCHAR outBuf;
PACKET_INFO* packet;
LIST_ENTRY* listEntry;
KLOCK_QUEUE_HANDLE packetInfoListLockHandle;
int maxSize;
int currentSize;
int packetSize;
int count;
char data[1028];
int counter;
memset(data, 0, sizeof(data));

UNREFERENCED_PARAMETER(DeviceObject);

PAGED_CODE();

irpSp = IoGetCurrentIrpStackLocation( Irp );
inBufLength = irpSp->Parameters.DeviceIoControl.InputBufferLength;
outBufLength = irpSp->Parameters.DeviceIoControl.OutputBufferLength;

DoTraceMessage(FLAG_ONE, “Enter IoctlDeviceControl \n”);
KdPrint((“Enter IoctlDeviceControl \n”));

if (!inBufLength || !outBufLength)
{
ntStatus = STATUS_INVALID_PARAMETER;
goto End;
}
if( irpSp->Parameters.DeviceIoControl.IoControlCode==IOCTL_METHOD_BUFFERED )
{
maxSize=1028;
currentSize=4;
packetSize=sizeof(PACKET_INFO);
counter=0;
while (!IsListEmpty(&gPacketInfoList))
{
if (currentSize+packetSize>maxSize)
break;
packet = NULL;
KeAcquireInStackQueuedSpinLock(
&gPacketInfoListLock,
&packetInfoListLockHandle);
if (!IsListEmpty(&gPacketInfoList))
{
listEntry = RemoveHeadList(&gPacketInfoList);
packet = CONTAINING_RECORD(
listEntry,
PACKET_INFO,
listEntry);
}

KeReleaseInStackQueuedSpinLock(&packetInfoListLockHandle);

if (packet!=NULL)
{
counter++;
KdPrint((“Packet Info %d proccessed \n”,counter));
memcpy(&data[currentSize],(char*)packet,packetSize);
currentSize+=packetSize;
ExFreePoolWithTag(packet, PACKET_INFO_POOL_TAG);
}
}
count=(int)((currentSize-4)/packetSize);
DoTraceMessage(FLAG_ONE, “Count packets %d \n”,count );
KdPrint((“Count packets %d \n”,count ));
inBuf = Irp->AssociatedIrp.SystemBuffer;
outBuf = Irp->AssociatedIrp.SystemBuffer;
memcpy(&data[0],&count,4);
RtlCopyBytes(outBuf, data, currentSize);
Irp->IoStatus.Information = (outBufLength }
End:
Irp->IoStatus.Status = ntStatus;
IoCompleteRequest( Irp, IO_NO_INCREMENT );

DoTraceMessage(FLAG_ONE, “Exit IoctlDeviceControl \n”);
KdPrint((“Exit IoctlDeviceControl \n” ));
return ntStatus;
}

Here is my ioctl user application implementation:

char* FilterManager::GetAvailableDriverData()
{

char OutputBuffer[1028];
char data[1028];
int countPackets=0;
ULONG bytesReturned;
memset(OutputBuffer, 0, sizeof(OutputBuffer));
BOOL resultDriver = DeviceIoControl (
driverManager.driver,
IOCTL_METHOD_BUFFERED ,
&OutputBuffer,
sizeof( OutputBuffer),
&OutputBuffer,
sizeof( OutputBuffer),
&bytesReturned,
NULL
);
if ( !resultDriver )
{
int count=0;
printf ( “Error in DeviceIoControl : %d”, GetLastError());
return data;
}
memcpy(data,OutputBuffer,bytesReturned);
memcpy(&countPackets,&data[0],4);
printf(“Count Recieved Bytes = %d \n”, bytesReturned);
printf(“Count Recieved Packets = %d \n”,countPackets);
return data;
}

After i increased ioctl buffer from 1028 to 64516 byteas i get PAGE_FAULT_IN_NONPAGED_AREA (50) error.

Here is windbg output:

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.

Arguments:

Arg1: 944f0000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 828b636b, If non-zero, the instruction address which referenced the bad memory
- Show quoted text -
address.
Arg4: 00000000, (reserved)

READ_ADDRESS: 944f0000
FAULTING_IP:
nt!_alloca_probe+27
828b636b 8500 test dword ptr [eax],eax

MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: TestEngine.exe
CURRENT_IRQL: 2
MANAGED_STACK: !dumpstack -EE

TRAP_FRAME: 944f3b80 – (.trap 0xffffffff944f3b80)
ErrCode = 00000000
eax=944f0000 ebx=00000000 ecx=944e3b9c edx=85e25790 esi=8434ff08 edi=842e8e58
eip=828b636b esp=944f3bf4 ebp=944f3bfc iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
nt!_alloca_probe+0x27:
828b636b 8500 test dword ptr [eax],eax ds:0023:944f0000=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 82928e71 to 828b7394
STACK_TEXT:

944f36cc 82928e71 00000003 be8c7861 00000065 nt!RtlpBreakWithStatusInstruction
944f371c 8292996d 00000003 84265a58 00000000 nt!KiBugCheckDebugBreak+0x1c
944f3ae0 828d18e3 00000050 944f0000 00000000 nt!KeBugCheck2+0x68b
944f3b68 828925f8 00000000 944f0000 00000000 nt!MmAccessFault+0x106
944f3b68 828b636b 00000000 944f0000 00000000 nt!KiTrap0E+0xdc
944f3bfc 828884bc 8434ff08 85e25790 85e25790 nt!_alloca_probe+0x27
944f3c14 82a89eee 842e8e58 85e25790 85e25800 nt!IofCallDriver+0x63
944f3c34 82aa6cd1 8434ff08 842e8e58 00000000 nt!IopSynchronousServiceTail+0x1f8
944f3cd0 82aa94ac 8434ff08 85e25790 00000000 nt!IopXxxControlFile+0x6aa
944f3d04 8288f42a 0000025c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
944f3d04 77aa64f4 0000025c 00000000 00000000 nt!KiFastCallEntry+0x12a
0032f044 77aa4cac 75dda08f 0000025c 00000000 ntdll!KiFastSystemCallRet
0032f048 75dda08f 0000025c 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
0032f0a8 778cec25 0000025c 9c402408 0032f178 KERNELBASE!DeviceIoControl+0xf6
0032f0d4 0035bc8b 0000025c 9c402408 0032f178 KERNEL32!DeviceIoControlImplementation+0x80
WARNING: Frame IP not in any known module. Following frames may be wrong.
0032f10c 03e85e60 00000000 000ff9e0 0034f24c 0x35bc8b
0034f1c8 6c8b13fc 01a43aac 01a43a8c 01a43a7c 0x3e85e60
0034f220 6c8a1b6c 00000003 0034f234 0034f2b0 mscorwks!PreStubWorker+0x141
0034f230 6c8b2209 0034f300 00000000 0034f2d0 mscorwks!CallDescrWorker+0x33
0034f2b0 6c8c6511 0034f300 00000000 0034f2d0 mscorwks!CallDescrWorkerWithHandler+0xa3
0034f3f0 6c8c6544 0036c030 0034f4bc 0034f488 mscorwks!MethodDesc::CallDescr+0x19c
0034f40c 6c8c6562 0036c030 0034f4bc 0034f488 mscorwks!MethodDesc::CallTargetWorker+0x1f
0034f424 6c930c45 0034f488 0020ba3b 00000000 mscorwks!MethodDescCallSite::CallWithValueTypes_RetArgSlot+0x1a
0034f588 6c930b65 00362ffc 00000001 0034f5c4 mscorwks!ClassLoader::RunMain+0x223
0034f7f0 6c9310b5 00000000 0020b373 00000001 mscorwks!Assembly::ExecuteMainMethod+0xa6
0034fcc0 6c93129f 00070000 00000000 0020b2a3 mscorwks!SystemDomain::ExecuteMainMethod+0x456
0034fd10 6c9311cf 00070000 0020b2eb 00000000 mscorwks!ExecuteEXE+0x59
0034fd58 6dfc7c24 00000000 6c8a0000 0034fd74 mscorwks!_CorExeMain+0x15c
0034fd68 778d1174 7ffd9000 0034fdb4 77abb3f5 MSCOREE!_CorExeMain+0x2c
0034fd74 77abb3f5 7ffd9000 7782713e 00000000 KERNEL32!BaseThreadInitThunk+0xe
0034fdb4 77abb3c8 6dfc7bf0 7ffd9000 00000000 ntdll!__RtlUserThreadStart+0x70
0034fdcc 00000000 6dfc7bf0 7ffd9000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb
FOLLOWUP_IP:

nt!_alloca_probe+27
828b636b 8500 test dword ptr [eax],eax

SYMBOL_STACK_INDEX: 5
SYMBOL_NAME: nt!_alloca_probe+27
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc007
FAILURE_BUCKET_ID: 0x50_nt!_alloca_probe+27
BUCKET_ID: 0x50_nt!_alloca_probe+27

Followup: MachineOwner

1) How to resolve this issue?
2) How often can i call data from the driver?
3) What is optimal buffer size for ioctl?

Thanks for any help.

dan-3 · February 6, 2011, 2:51pm

If you are changing the size of the local “data” array to 64K then you
could be accessing memory beyond the stack as the kernel stack size is only
12K IIRC.
You can call the driver as often as you need to but a more elegant way is
to pend the irp to a cancel safe queue and then complete it whenever your
driver gets (or filters) data (probably alot easier in KMDF however).
I dont know, it depends

a couple of other things:

you dont need the temporary stack allocated data array, you can just
copy the packets directly into the user supplied buffer
the ioctl control code is generally built up from the CTL_CODE macro (of
which IOCTL_METHOD_BUFFERED will be a parameter to)
if you dont need an input buffer to your ioctl you can just use NULL as
the parameter.
oh and replace all those magic numbers with defines! it will be less
work in the long run and is much less error prone

Cheers,
dan

On Mon, Feb 7, 2011 at 3:20 AM, wrote:

> HI,
>
> Could you please answer on following questions.
>
> Environment Win7 x86
> WDK version: 7600.16385.1
>
> I write driver on kernel mode.User-mode application uses ioctl call to
> request data from driver.
> I called ioctl periodically with 3 second interval from user application.
>
> Here is my ioctl driver implementation:
>
> NTSTATUS
> IoctlDeviceControl(
> PDEVICE_OBJECT DeviceObject,
> PIRP Irp
> )
> {
> PIO_STACK_LOCATION irpSp;
> NTSTATUS ntStatus = STATUS_SUCCESS;
> ULONG inBufLength;
> ULONG outBufLength;
> PCHAR inBuf;
> PCHAR outBuf;
> PACKET_INFO* packet;
> LIST_ENTRY* listEntry;
> KLOCK_QUEUE_HANDLE packetInfoListLockHandle;
> int maxSize;
> int currentSize;
> int packetSize;
> int count;
> char data[1028];
> int counter;
> memset(data, 0, sizeof(data));
>
> UNREFERENCED_PARAMETER(DeviceObject);
>
> PAGED_CODE();
>
> irpSp = IoGetCurrentIrpStackLocation( Irp );
> inBufLength = irpSp->Parameters.DeviceIoControl.InputBufferLength;
> outBufLength = irpSp->Parameters.DeviceIoControl.OutputBufferLength;
>
> DoTraceMessage(FLAG_ONE, “Enter IoctlDeviceControl \n”);
> KdPrint((“Enter IoctlDeviceControl \n”));
>
> if (!inBufLength || !outBufLength)
> {
> ntStatus = STATUS_INVALID_PARAMETER;
> goto End;
> }
> if(
> irpSp->Parameters.DeviceIoControl.IoControlCode==IOCTL_METHOD_BUFFERED )
> {
> maxSize=1028;
> currentSize=4;
> packetSize=sizeof(PACKET_INFO);
> counter=0;
> while (!IsListEmpty(&gPacketInfoList))
> {
> if (currentSize+packetSize>maxSize)
> break;
> packet = NULL;
> KeAcquireInStackQueuedSpinLock(
> &gPacketInfoListLock,
> &packetInfoListLockHandle);
> if (!IsListEmpty(&gPacketInfoList))
> {
> listEntry =
> RemoveHeadList(&gPacketInfoList);
> packet = CONTAINING_RECORD(
> listEntry,
> PACKET_INFO,
> listEntry);
> }
>
>
> KeReleaseInStackQueuedSpinLock(&packetInfoListLockHandle);
>
> if (packet!=NULL)
> {
> counter++;
> KdPrint((“Packet Info %d proccessed
> \n”,counter));
>
> memcpy(&data[currentSize],(char*)packet,packetSize);
> currentSize+=packetSize;
> ExFreePoolWithTag(packet,
> PACKET_INFO_POOL_TAG);
> }
> }
> count=(int)((currentSize-4)/packetSize);
> DoTraceMessage(FLAG_ONE, “Count packets %d \n”,count );
> KdPrint((“Count packets %d \n”,count ));
> inBuf = Irp->AssociatedIrp.SystemBuffer;
> outBuf = Irp->AssociatedIrp.SystemBuffer;
> memcpy(&data[0],&count,4);
> RtlCopyBytes(outBuf, data, currentSize);
> Irp->IoStatus.Information =
> (outBufLength> }
> End:
> Irp->IoStatus.Status = ntStatus;
> IoCompleteRequest( Irp, IO_NO_INCREMENT );
>
> DoTraceMessage(FLAG_ONE, “Exit IoctlDeviceControl \n”);
> KdPrint((“Exit IoctlDeviceControl \n” ));
> return ntStatus;
> }
>
>
> Here is my ioctl user application implementation:
>
> char* FilterManager::GetAvailableDriverData()
> {
>
> char OutputBuffer[1028];
> char data[1028];
> int countPackets=0;
> ULONG bytesReturned;
> memset(OutputBuffer, 0, sizeof(OutputBuffer));
> BOOL resultDriver = DeviceIoControl (
> driverManager.driver,
> IOCTL_METHOD_BUFFERED ,
> &OutputBuffer,
> sizeof( OutputBuffer),
> &OutputBuffer,
> sizeof( OutputBuffer),
> &bytesReturned,
> NULL
> );
> if ( !resultDriver )
> {
> int count=0;
> printf ( “Error in DeviceIoControl : %d”, GetLastError());
> return data;
> }
> memcpy(data,OutputBuffer,bytesReturned);
> memcpy(&countPackets,&data[0],4);
> printf(“Count Recieved Bytes = %d \n”, bytesReturned);
> printf(“Count Recieved Packets = %d \n”,countPackets);
> return data;
> }
>
> After i increased ioctl buffer from 1028 to 64516 byteas i get
> PAGE_FAULT_IN_NONPAGED_AREA (50) error.
>
>
> Here is windbg output:
>
> PAGE_FAULT_IN_NONPAGED_AREA (50)
> Invalid system memory was referenced. This cannot be protected by
> try-except,
> it must be protected by a Probe. Typically the address is just plain bad
> or it
> is pointing at freed memory.
>
> Arguments:
>
> Arg1: 944f0000, memory referenced.
> Arg2: 00000000, value 0 = read operation, 1 = write operation.
> Arg3: 828b636b, If non-zero, the instruction address which referenced the
> bad memory
> - Show quoted text -
> address.
> Arg4: 00000000, (reserved)
>
> READ_ADDRESS: 944f0000
> FAULTING_IP:
> nt!_alloca_probe+27
> 828b636b 8500 test dword ptr [eax],eax
>
>
> MM_INTERNAL_CODE: 0
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
> BUGCHECK_STR: 0x50
> PROCESS_NAME: TestEngine.exe
> CURRENT_IRQL: 2
> MANAGED_STACK: !dumpstack -EE
>
>
> TRAP_FRAME: 944f3b80 – (.trap 0xffffffff944f3b80)
> ErrCode = 00000000
> eax=944f0000 ebx=00000000 ecx=944e3b9c edx=85e25790 esi=8434ff08
> edi=842e8e58
> eip=828b636b esp=944f3bf4 ebp=944f3bfc iopl=0 nv up ei ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> nt!_alloca_probe+0x27:
> 828b636b 8500 test dword ptr [eax],eax
> ds:0023:944f0000=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 82928e71 to 828b7394
> STACK_TEXT:
>
> 944f36cc 82928e71 00000003 be8c7861 00000065
> nt!RtlpBreakWithStatusInstruction
> 944f371c 8292996d 00000003 84265a58 00000000 nt!KiBugCheckDebugBreak+0x1c
> 944f3ae0 828d18e3 00000050 944f0000 00000000 nt!KeBugCheck2+0x68b
> 944f3b68 828925f8 00000000 944f0000 00000000 nt!MmAccessFault+0x106
> 944f3b68 828b636b 00000000 944f0000 00000000 nt!KiTrap0E+0xdc
> 944f3bfc 828884bc 8434ff08 85e25790 85e25790 nt!_alloca_probe+0x27
> 944f3c14 82a89eee 842e8e58 85e25790 85e25800 nt!IofCallDriver+0x63
> 944f3c34 82aa6cd1 8434ff08 842e8e58 00000000
> nt!IopSynchronousServiceTail+0x1f8
> 944f3cd0 82aa94ac 8434ff08 85e25790 00000000 nt!IopXxxControlFile+0x6aa
> 944f3d04 8288f42a 0000025c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
> 944f3d04 77aa64f4 0000025c 00000000 00000000 nt!KiFastCallEntry+0x12a
> 0032f044 77aa4cac 75dda08f 0000025c 00000000 ntdll!KiFastSystemCallRet
> 0032f048 75dda08f 0000025c 00000000 00000000
> ntdll!NtDeviceIoControlFile+0xc
> 0032f0a8 778cec25 0000025c 9c402408 0032f178
> KERNELBASE!DeviceIoControl+0xf6
> 0032f0d4 0035bc8b 0000025c 9c402408 0032f178
> KERNEL32!DeviceIoControlImplementation+0x80
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0032f10c 03e85e60 00000000 000ff9e0 0034f24c 0x35bc8b
> 0034f1c8 6c8b13fc 01a43aac 01a43a8c 01a43a7c 0x3e85e60
> 0034f220 6c8a1b6c 00000003 0034f234 0034f2b0 mscorwks!PreStubWorker+0x141
> 0034f230 6c8b2209 0034f300 00000000 0034f2d0 mscorwks!CallDescrWorker+0x33
> 0034f2b0 6c8c6511 0034f300 00000000 0034f2d0
> mscorwks!CallDescrWorkerWithHandler+0xa3
> 0034f3f0 6c8c6544 0036c030 0034f4bc 0034f488
> mscorwks!MethodDesc::CallDescr+0x19c
> 0034f40c 6c8c6562 0036c030 0034f4bc 0034f488
> mscorwks!MethodDesc::CallTargetWorker+0x1f
> 0034f424 6c930c45 0034f488 0020ba3b 00000000
> mscorwks!MethodDescCallSite::CallWithValueTypes_RetArgSlot+0x1a
> 0034f588 6c930b65 00362ffc 00000001 0034f5c4
> mscorwks!ClassLoader::RunMain+0x223
> 0034f7f0 6c9310b5 00000000 0020b373 00000001
> mscorwks!Assembly::ExecuteMainMethod+0xa6
> 0034fcc0 6c93129f 00070000 00000000 0020b2a3
> mscorwks!SystemDomain::ExecuteMainMethod+0x456
> 0034fd10 6c9311cf 00070000 0020b2eb 00000000 mscorwks!ExecuteEXE+0x59
> 0034fd58 6dfc7c24 00000000 6c8a0000 0034fd74 mscorwks!_CorExeMain+0x15c
> 0034fd68 778d1174 7ffd9000 0034fdb4 77abb3f5 MSCOREE!_CorExeMain+0x2c
> 0034fd74 77abb3f5 7ffd9000 7782713e 00000000
> KERNEL32!BaseThreadInitThunk+0xe
> 0034fdb4 77abb3c8 6dfc7bf0 7ffd9000 00000000
> ntdll!__RtlUserThreadStart+0x70
> 0034fdcc 00000000 6dfc7bf0 7ffd9000 00000000 ntdll!_RtlUserThreadStart+0x1b
>
> STACK_COMMAND: kb
> FOLLOWUP_IP:
>
> nt!_alloca_probe+27
> 828b636b 8500 test dword ptr [eax],eax
>
> SYMBOL_STACK_INDEX: 5
> SYMBOL_NAME: nt!_alloca_probe+27
> FOLLOWUP_NAME: MachineOwner
> MODULE_NAME: nt
> IMAGE_NAME: ntkrpamp.exe
> DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc007
> FAILURE_BUCKET_ID: 0x50_nt!_alloca_probe+27
> BUCKET_ID: 0x50_nt!_alloca_probe+27
>
> Followup: MachineOwner
>
> 1) How to resolve this issue?
> 2) How often can i call data from the driver?
> 3) What is optimal buffer size for ioctl?
>
> Thanks for any help.
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

Mark_Roddy · February 6, 2011, 6:13pm

On Sun, Feb 6, 2011 at 9:20 AM, wrote:
> IOCTL_METHOD_BUFFERED

This is not a valid IOCTL control code.

char OutputBuffer[1028];
.
.
.

driverManager.driver,
IOCTL_METHOD_BUFFERED ,
&OutputBuffer,

You actually do not mean &OutputBuffer, you mean OutputBuffer.

You are copying your packets into a stack allocated buffer (data) and
then from there into SystemBuffer.
1) that seems to be a ridiculous waste of time.
2) that is not going to work for a 64K buffer size.

Mark Roddy

Tim_Roberts · February 7, 2011, 1:54pm

Mark Roddy wrote:

On Sun, Feb 6, 2011 at 9:20 AM, wrote:
>> IOCTL_METHOD_BUFFERED
> This is not a valid IOCTL control code.

Actually, we don’t know that. The constant is METHOD_BUFFERED, so
IOCTL_METHOD_BUFFERED is a name of his own invention.

And, technically speaking, wouldn’t “METHOD_BUFFERED” by itself be a
valid ioctl control code, albeit an unwise one?

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

Mark_Roddy · February 7, 2011, 2:12pm

hmmm… good point. So perhaps it is a good IOCTL. And yes probably
METHOD_BUFFERED, if it manages to get through at all, is in fact a
METHOD_BUFFERED Ioctl. Or not…

Mark Roddy

On Mon, Feb 7, 2011 at 1:53 PM, Tim Roberts wrote:
> Mark Roddy wrote:
>> On Sun, Feb 6, 2011 at 9:20 AM, ? wrote:
>>> IOCTL_METHOD_BUFFERED
>> This is not a valid IOCTL control code.
>
> Actually, we don’t know that. ?The constant is METHOD_BUFFERED, so
> IOCTL_METHOD_BUFFERED is a name of his own invention.
>
> And, technically speaking, wouldn’t “METHOD_BUFFERED” by itself be a
> valid ioctl control code, albeit an unwise one?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

Tim_Roberts · February 7, 2011, 2:16pm

Mark Roddy wrote:

hmmm… good point. So perhaps it is a good IOCTL. And yes probably
METHOD_BUFFERED, if it manages to get through at all, is in fact a
METHOD_BUFFERED Ioctl. Or not…

Exactly!

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

OSR_Community_User · February 7, 2011, 2:19pm

Is there a problem with >=64K buffers? Just curious…

(No, it is not a good idea to allocate 64K buffers on the stack. Also, I
would have thought UCHAR or BYTE would have been better choices than “char”,
which is signed, unless the quantities being read really are signed 8-bit
values)
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Sunday, February 06, 2011 6:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Ioctl buffer size

On Sun, Feb 6, 2011 at 9:20 AM, wrote:
> IOCTL_METHOD_BUFFERED

This is not a valid IOCTL control code.

char OutputBuffer[1028];
.
.
.

driverManager.driver,
IOCTL_METHOD_BUFFERED ,
&OutputBuffer,

You actually do not mean &OutputBuffer, you mean OutputBuffer.

You are copying your packets into a stack allocated buffer (data) and
then from there into SystemBuffer.
1) that seems to be a ridiculous waste of time.
2) that is not going to work for a 64K buffer size.

Mark Roddy

—
NTDEV is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Tim_Roberts · February 7, 2011, 2:22pm

Joseph M. Newcomer wrote:

Is there a problem with >=64K buffers? Just curious…

Only because he’s copying them to the stack.

(No, it is not a good idea to allocate 64K buffers on the stack.

In fact, it is a fatally bad idea, because kernel stacks are limited to
12k bytes. That’s why his crash was in “alloca”, which allocates stack
space.

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

OSR_Community_User · February 8, 2011, 11:49am

I hadn’t seen the original post when I asked the question, but once I saw
the horror that was the user code and the kernel code it became obvious. I
thought the reference was to the user-level buffer or an IOCTL doing more
than 64K, which I hadn’t thought was a problem. But the huge buffers in the
kernel are, as you point out, a fatally bad idea.

I haven’t seen code that bad in years! It would have been bad code in user
space, and it is fatally bad for a lot of reasons in kernel space (the lack
of any locking at the right level is a good start to indicate that there are
deep problems, but the superficial problems hide the deep problems).
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, February 07, 2011 2:22 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Ioctl buffer size

Joseph M. Newcomer wrote:

Is there a problem with >=64K buffers? Just curious…

Only because he’s copying them to the stack.

(No, it is not a good idea to allocate 64K buffers on the stack.

In fact, it is a fatally bad idea, because kernel stacks are limited to
12k bytes. That’s why his crash was in “alloca”, which allocates stack
space.

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

NTDEV is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Tim_Roberts · February 8, 2011, 12:41pm

Joseph M. Newcomer wrote:

I haven’t seen code that bad in years! It would have been bad code in user
space, and it is fatally bad for a lot of reasons in kernel space (the lack
of any locking at the right level is a good start to indicate that there are
deep problems, but the superficial problems hide the deep problems).

I suppose we were all beginners once. I must have been at one point,
although apparently I’ve blocked it out.

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

OSR_Community_User · February 8, 2011, 8:55pm

I had a number of people beat seriously on me when I was learning, and they
had no tolerance for bad code. But I worry when I see code this bad; it
means that there was no oversight or training. The multiple copies are not
a mistake that even a newbie should make. *Someone* has to explain in
detail why this code is so bad! I’d have given it an “F” in an introductory
undergrad programming course. Because I would have already spent weeks
explaining why most of it would have been wrong if coded. The use of a
global variable in this context is definitely evil, and the failure to lock
it (although there is a demonstration that locking is understood) is
inexplicable. It looks like bad copy-and-paste from a bad driver example.

I learned from some of the best, and I would have gotten to write code like
that exactly once, then someone like my first manager (when I wrote FORTRAN
or COBOL), or Jim Mitchell (who was VP of Research for Sun, before it was
acquired, and I don’t know what his current state is, but he was our project
manager when he and I were grad students), Roy Levin, Bill Wulf, Hank
Mashburn, or a dozen other real experts who would have seen my code would
have raked me over the coals if I was the least bit sloppy. Now that I stop
to think of it, they did. Which is why I think I write good code; I do it
because I wasn’t given any other option. So I remember what it was like to
be a beginner, even 45 years later, because I was not allowed to forget that
while it was OK to be a beginner, it was NOT OK to be a sloppy beginner.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, February 08, 2011 12:41 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Ioctl buffer size

Joseph M. Newcomer wrote:

I haven’t seen code that bad in years! It would have been bad code in
user
space, and it is fatally bad for a lot of reasons in kernel space (the
lack
of any locking at the right level is a good start to indicate that there
are
deep problems, but the superficial problems hide the deep problems).

I suppose we were all beginners once. I must have been at one point,
although apparently I’ve blocked it out.

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

NTDEV is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Maxim_S_Shatskih · February 9, 2011, 8:58am

> because I wasn’t given any other option. So I remember what it was like to

be a beginner, even 45 years later, because I was not allowed to forget that
while it was OK to be a beginner, it was NOT OK to be a sloppy beginner.

This is how the current business model works.

The startup needs to deliver the demo FAST. This is the question of investor’s money and thus the very existence of startup.

And, if the new project is started within the well-established company, it’s the same thing as startup actually.

It is never mind that the demo “crashes sometimes” - the startup will get these money. In the worst case the enterpreneur will say to his investors - “yes, we have bugs, but there are always bugs, and they will be fixed”. Correct? in the case when the code is extremely dirty - incorrect. Only the total full rewrite will fix the bugs.

And, if the demo slips the schedule - then this can cause fatality to the startup immediately, not in some distant future. In this particular case, enterpreneur himself will lose money, while in the case of “demo-was-accepted-but-there-are-bugs” he can just plain afford killing this startup, since he earned enough money off it.

Such a “climate” introduced the generation of programmers which need to code fast and nothing else. No, they are not stupid. They just intentionally neglect the deep understanding of anything in favor of “deliver the demo ASAP”. For them, the deep understanding of anything is dull, unserious and not the place where the money live (some of them are really dreaming about the possibility for them to repeat the success story of Google).

Surely there are startups absolutely not such and much more serious about code quality, and they are usually much more successful I would even say that such (as the above) startup can be successful only if there is a really brilliant guy (or a team of guys) there, not just good professionals like, for instance, myself.

And, surely well-standing companies like MS are not such, at least their key teams (according to what MS’s people write here on this forum).

More so: such business model have spread by far outside the software development, and yes, one of the key causes of financial crisis of late 08 - early 09 was exactly this: such business model and its intrinsic weakness of being nearly unable to handle any more-or-less hard issue (can operate “in good weather” only).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Calvin_Guan-3 · February 9, 2011, 1:06pm

There is always time and resource constraints on any project. It doesn’t
matter if it’s start-up or publicly traded companies.

In general, the more time one spends in a project, the better the quality of
the work assuming the person who performs the work has positive
productivity. OTOH, the cost will increase which is not a good thing in the
corporation’s financial statement. If deadline is missed, the project or the
entire team may not even stand a chance to survive.

Good engineers are expected to deliver work that performs to spec, in time,
in budget with reasonably quality of work. These things generally goes to
one’s performance review. Whoever failed to do either one would get
punished.

For companies to have better chance to success, they would hire the best and
keep them nice and warm.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, February 09, 2011 5:58 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Ioctl buffer size

because I wasn’t given any other option. So I remember what it was like
to
be a beginner, even 45 years later, because I was not allowed to forget
that
while it was OK to be a beginner, it was NOT OK to be a sloppy beginner.

This is how the current business model works.

The startup needs to deliver the demo FAST. This is the question of
investor’s money and thus the very existence of startup.

And, if the new project is started within the well-established company, it’s
the same thing as startup actually.

It is never mind that the demo “crashes sometimes” - the startup will get
these money. In the worst case the enterpreneur will say to his investors -
“yes, we have bugs, but there are always bugs, and they will be fixed”.
Correct? in the case when the code is extremely dirty - incorrect. Only the
total full rewrite will fix the bugs.

And, if the demo slips the schedule - then this can cause fatality to the
startup immediately, not in some distant future. In this particular case,
enterpreneur himself will lose money, while in the case of
“demo-was-accepted-but-there-are-bugs” he can just plain afford killing this
startup, since he earned enough money off it.

Such a “climate” introduced the generation of programmers which need to
code fast and nothing else. No, they are not stupid. They just
intentionally neglect the deep understanding of anything in favor of
“deliver the demo ASAP”. For them, the deep understanding of anything is
dull, unserious and not the place where the money live (some of them are
really dreaming about the possibility for them to repeat the success story
of Google).

Surely there are startups absolutely not such and much more serious about
code quality, and they are usually much more successful I would even say
that such (as the above) startup can be successful only if there is a
really brilliant guy (or a team of guys) there, not just good
professionals like, for instance, myself.

And, surely well-standing companies like MS are not such, at least their key
teams (according to what MS’s people write here on this forum).

More so: such business model have spread by far outside the software
development, and yes, one of the key causes of financial crisis of late 08 -
early 09 was exactly this: such business model and its intrinsic weakness of
being nearly unable to handle any more-or-less hard issue (can operate “in
good weather” only).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

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

Calvin_Guan-3 · February 9, 2011, 1:38pm

Assuming the definition of success of start-up is getting IPO or getting
bought at a profitable price where significant amount can be allocated to
individuals not just the big sharks.

Engineers mainly bring the big idea into products. Engineering excellence is
paid off only when it’s a good idea to start off.

Calvin