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...
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.
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)
this may not be the problem, but it's a syntax issue
buffer byte 1024 dup(?)
and another
discn byte "\\.\physicaldisc0",0
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
I went crazy w/this until I aligned it:
http://masm32.com/board/index.php?topic=2130.0
assemble as console app
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
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.
1 kb sounds odd - lol
but, i modifed the code to page-align
Quote from: dedndave on December 28, 2013, 04:09:19 AM
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 ;-)
sectors are 512 bytes - i guess i could understand 512-alignment - or page-align, or 16-align :P
but, 1024 sounds weird
1024 is wrong, I meant 4096, page aligned as from VirtualAlloc.
Dave.
Quote from: dedndave on December 28, 2013, 01:37:19 AM
assemble as console app
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
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.
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