ERROR_INVALID_PARAMETER

[shaikkareem]

Hi there......
I'm trying to read my physical drive by using the win32 function CreateFile....it is return the handle as usual. But the problem raises when i tried to invoke ReadFile function. It just returning the error code 87 wich is error_invalid_parameter. I just studied about posting about the same problem faced by other programmer. But its is very difficult to me to understand those instructions....discussed in their posting...but some one tell me or give a way to overcome this problem...

[jj2007]

Why do you believe we can read your thoughts and thus know what "those instructions" are?
Why do you believe we can remotely control your computer and read your code?

Post the complete code.

[shaikkareem]

not a big deal......

i declare an array as buffer for storing the retrieved information as bytes from the result of ReadFile function...as

buffer byte 1024 byte (0)
nobtread dword 0
hdisc dword 0

discn "\\.\physicaldisc0",0

in the code segment i invoke the function both CreateFunction and ReadFunction as follows


invoke CrateFile,offset discn, GENERIC_READ OR GENERIC_WRITE, FILE_SHARE_READ 0R FILE_SHARE_WRITE, NULL, OPEN_EXISTING, NULL, NULL
mov hdisc,eax

invoke ReadFile,hdisc,offset buffer,1024,offset nobtread,NULL

here it is not successfully completing the operation.
and when i call the GetLastError function to see for any errors it is returning 87(error_invalid_parameter)

[dedndave]

this may not be the problem, but it's a syntax issue

Code Select Expand

buffer   byte  1024 dup(?)
and another

Code Select Expand

discn   byte "\\.\physicaldisc0",0

[dedndave]

i don't know what you expect to see when reading a physical device like a file
never tried this before - lol

i don't know - it may be that you don't have sufficient access rights to access it that way
although, you'd think it would be ERROR_ACCESS_DENIED or a security error of some sort

but, when i have wanted a handle to a device like this, in the past,
it was to use something like DeviceIoControl - not ReadFile

there are probably other functions where a device handle is required, as well
at the moment DeviceIoControl is the only one that comes to mind   :P

[MtheK]

  I went crazy w/this until I aligned it:

http://masm32.com/board/index.php?topic=2130.0

[dedndave]

assemble as console app

Code Select Expand

        INCLUDE    \Masm32\Include\Masm32rt.inc

;###############################################################################################

        .DATA

UCSTR discn,"\\.\PhysicalDrive0",0

szMbrFile byte 'mbrbin.bin',0

;***********************************************************************************************

        .DATA?

nobtread dword ?
hdisc    dword ?
hfile    dword ?
lpBuf    dword ?
buffer   byte  5120 dup(?)  ;4 kb page-align + 1 kb buffer

;###############################################################################################

        .CODE

;***********************************************************************************************

_main   PROC

;align the buffer

        mov     eax,offset buffer
        add     eax,4095
        and     eax,-4096
        mov     lpBuf,eax

;read the first 2 sectors

        INVOKE  CreateFileW,offset discn,GENERIC_READ,0,NULL,OPEN_EXISTING,0,NULL
        mov     hdisc,eax
        INVOKE  ReadFile,hdisc,lpBuf,1024,offset nobtread,NULL
        INVOKE  CloseHandle,hdisc

;write to bin file

        INVOKE  CreateFile,offset szMbrFile,GENERIC_WRITE,FILE_SHARE_READ,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
        mov     hfile,eax
        INVOKE  WriteFile,hfile,lpBuf,1024,offset nobtread,NULL
        INVOKE  CloseHandle,hfile

;pause and exit

        print   chr$(13,10)
        inkey
        INVOKE  ExitProcess,0

_main   ENDP

;###############################################################################################

        END     _main

i opened the device as UNICODE, but the rest of the functions are ANSI
it works under XP, but under newer OS's, it may require admin privileges - or, it may not work at all - lol

[KeepingRealBusy]

Just a thought.

I do not know whether reading a device as opposed to reading a file requires buffer alignment, but when I do unbuffered I/O and do not have the buffer on a 1024 BYTE boundary, I get an invalid parameter error. To guarantee a buffer alignment, use VirtualAlloc to allocate the buffer.

Dave.

[dedndave]

1 kb sounds odd - lol

but, i modifed the code to page-align

[jj2007]

1 kb sounds odd - lol

Indeed. If it works, check if "by accident" it was also 4k-aligned. If yes, you have a bug that is really difficult to chase because it occurs only in one of four cases ;-)

[dedndave]

sectors are 512 bytes - i guess i could understand 512-alignment - or page-align, or 16-align   :P

but, 1024 sounds weird

[KeepingRealBusy]

1024 is wrong, I meant 4096, page aligned as from VirtualAlloc.

Dave.

[shaikkareem]

assemble as console app

Code Select Expand

        INCLUDE    \Masm32\Include\Masm32rt.inc

;###############################################################################################

        .DATA

UCSTR discn,"\\.\PhysicalDrive0",0

szMbrFile byte 'mbrbin.bin',0

;***********************************************************************************************

        .DATA?

nobtread dword ?
hdisc    dword ?
hfile    dword ?
lpBuf    dword ?
buffer   byte  5120 dup(?)  ;4 kb page-align + 1 kb buffer

;###############################################################################################

        .CODE

;***********************************************************************************************

_main   PROC

;align the buffer

        mov     eax,offset buffer
        add     eax,4095
        and     eax,-4096
        mov     lpBuf,eax

;read the first 2 sectors

        INVOKE  CreateFileW,offset discn,GENERIC_READ,0,NULL,OPEN_EXISTING,0,NULL
        mov     hdisc,eax
        INVOKE  ReadFile,hdisc,lpBuf,1024,offset nobtread,NULL
        INVOKE  CloseHandle,hdisc

;write to bin file

        INVOKE  CreateFile,offset szMbrFile,GENERIC_WRITE,FILE_SHARE_READ,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL
        mov     hfile,eax
        INVOKE  WriteFile,hfile,lpBuf,1024,offset nobtread,NULL
        INVOKE  CloseHandle,hfile

;pause and exit

        print   chr$(13,10)
        inkey
        INVOKE  ExitProcess,0

_main   ENDP

;###############################################################################################

        END     _main

i opened the device as UNICODE, but the rest of the functions are ANSI
it works under XP, but under newer OS's, it may require admin privileges - or, it may not work at all - lol

here i need a lots of explanation........
why did the same thing didn't work for me.....and actually why the alignment issue makes work here...i want know everything about segmentation.....in windows........just

[KeepingRealBusy]

shaikkareem,

The problem is not segmentation, but a requirement of the system to do the I/O. Read all of the MSDN documentation for CreateFile, especially the information about doing unbuffered I/O. The system needs to lock virtual pages in memory before it starts an I/O - all of the pages that this I/O will read (or write) need to be locked down until the I/O is completed, otherwise the system may swap out a page from your process (a page is your buffer) and give it to some other process to use while the I/O system is moving data from the drive to/from the memory block. To take away this page, it usually picks an unused page (that is not dirty - i.e that has not been written into by your process) and your buffer would be exactly the pages that would fit that description. The system does not need to actually swap anything, it just marks your page table word as missing, and allocates that physical page for the other process. If you need that page and try to access it by storing data into it or loading data from it, the access will fault and the system will see the fault (missing page fault) and it will reload your page from the swap file (in the process, stealing a page from some other process), and restart your process and your program will re-access the required data. Now, all of the CPU(s) can detect missing page faults to allow this virtualization, but the I/O system cannot detect them. To to do I/O, the system locks down the pages that will be affected by this I/O until it is completed.

For buffered I/O, the I/O system reads/writes physical sectors of the disk into locked down memory pages (an internal buffer in the OS), and copies the actual required data items into your buffer. This move time is in addition to the actual time it takes the I/O system to read the data from the disk and write it into the memory buffer. For huge files, this can be a substantial amount of time. To get around this additional time penalty, you can use unbuffered I/O. You specify this during the CreateFile call. Then when you read this file, the system reads it directly into your buffer instead of an OS buffer. It may copy this data to cache it, but that is another story. At any rate, your program runs faster. There are restrictions about your buffer that match the system requirements. The buffer must be on a boundary that matches the disk sector size, and the I/O must be for a modulo sector sized block of data (could be more than one sector). Now, sector sizes come in two flavors, 512 BYTES, or 4096 BYTES (up to 2 TB drives, the sector sizes are 512 BYTES, but for huge drives like 4 TB drives, the sector sizes are 4096).

Apparently, when you open a drive as a physical drive, the system opens it as an unbuffered device and the unbuffered I/O restrictions apply.

Dave.

[dedndave]

many of us don't know all there is to know about data alignment under windows - lol
it isn't always well documented

but, in this particular case, alignment wasn't the biggest issue
notice the parameters i used for CreateFile

also, i used CreateFileW - the UNICODE version - not sure that was necessary, though