Data transfer limits in ioctl calls on Windows 10

Hello,

#define IOCTL_SATA_COMMAND CTL_CODE( DEVICE_TYPE_SDCATA, 0x930, METHOD_BUFFERED, FILE_ANY_ACCESS

Does anyone know why the DeviceIoControl() call on a Windows 10 system limits data transfers to 16,007 512-byte blocks (8,195,584 bytes)? Is this the data transfer limit of the kernel buffers for block devices???

We have been using this ioctl since the early 2000s to send commands to PATA & SATA HDDs, without issue. Recently, I tried sending a command which would transfer > 16007 blocks to the host.
Windows returns the following error code:
EE_MA_NOT_ENOUGH_MEMORY =0x00000704,

The host application has over 100,000 blocks of buffer allocated, of which a pointer is passed in the above-mentioned ioctl.

The system being used has 32GB of RAM, of which only 6-8GB is in use.

Thanks for any advice

On a side note, because that's METHOD_BUFFERED, the kernel is making a COPY of your input buffer into kernel memory. You may want to think about better ways of transferring 8MB of data.

Thanks, do you have any suggestions?
I am not the maintainer of our driver, I typically maintain the Python layer.

Well, the system is trying to allocate 8MB of non-paged pool to satisfy this request. Depending on the version of Windows, I *guess” it’s possible that it doesn’t have the memory?

But, as Mr. Robert’s said… this does not seem to be a reasonable request. This IOCTL was clearly not designed to account for buffers nearly this large. By convention, we typically limit this type of transfer to something in the order of 64K. So, yeah.,. 8MB is “a bit too much”.

Thanks. How did you come to this conclusion, it's not so clear to me. Is there documentation for data transfer limits for ioctls?

Because it copies the data to an intermediate buffer in non-paged pool. Why on earth would gratuitously copying a buffer that size be a good idea?

In Windows, we have a mechanism (Direct I/O) that's designed exactly for this (non-copying) purpose. It's the mechanism that's used by, for example, the storage stack where buffers for read/write are expected to be large (sometimes).