{"id":382,"date":"2009-04-01T14:28:09","date_gmt":"2009-04-01T14:28:09","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2009\/04\/01\/reading-files\/"},"modified":"2026-07-30T16:21:44","modified_gmt":"2026-07-30T16:21:44","slug":"reading-files","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2009\/04\/01\/reading-files\/","title":{"rendered":"Reading Files"},"content":{"rendered":"
\"\"<\/a><\/div>\n

As you saw in my last post, my graduation project will use a tool called LabView<\/a> to receive and handle data from a USB<\/a> board. This data will be collected from a device called a gyroscope<\/a> using TTL 232, which is an RS 232<\/a> with voltages of 0 and 5 volts. But as a proof of concept<\/a>, we would have to make the driver simulate the reception of data to send to LabView<\/span>. We used a circuit that turns TTL 232 into RS 232 just to allow the data to be read from a conventional serial port. Then I made a silly little program that writes to a file everything it receives through the serial port. Since the firmware had not even been started, I decided to make a driver that would read this file and pass the data on to the application layer. Questions about how to manipulate files are especially frequent. Many readers would like to know how to create, read, write and even delete files in Kernel Mode. Maybe I will disappoint you a little by saying that it is not so different from User Mode, but since we are here doing nothing, why not demonstrate?<\/p>\n

I believe the biggest difference is in the step where we get the handle to the file. Let us start by taking a look at the ZwCreateFile()<\/a> routine.<\/p>\n

\n
NTSTATUS  <\/pre>\n
  ZwCreateFile(<\/pre>\n
    OUT PHANDLE  FileHandle,<\/pre>\n
    IN ACCESS_MASK  DesiredAccess,<\/pre>\n
    IN POBJECT_ATTRIBUTES  ObjectAttributes,<\/pre>\n
    OUT PIO_STATUS_BLOCK  IoStatusBlock,<\/pre>\n
    IN PLARGE_INTEGER  AllocationSize  OPTIONAL,<\/pre>\n
    IN ULONG  FileAttributes,<\/pre>\n
    IN ULONG  ShareAccess,<\/pre>\n
    IN ULONG  CreateDisposition,<\/pre>\n
    IN ULONG  CreateOptions,<\/pre>\n
    IN PVOID  EaBuffer  OPTIONAL,<\/pre>\n
    IN ULONG  EaLength<\/pre>\n
    );<\/pre>\n<\/div>\n
The interesting part of this step is that the routine does not have the classic FileName <\/span>parameter that we saw in the equivalent CreateFile()<\/a> API for User Mode. The file name is described in the OBJECT_ATTRIBUTES<\/a> structure described below.<\/p>\n
\n
typedef<\/span> struct<\/span> _OBJECT_ATTRIBUTES {<\/pre>\n
    ULONG  Length;<\/pre>\n
    HANDLE  RootDirectory;<\/pre>\n
    PUNICODE_STRING  ObjectName;<\/pre>\n
    ULONG  Attributes;<\/pre>\n
    PVOID  SecurityDescriptor;<\/pre>\n
    PVOID  SecurityQualityOfService;<\/pre>\n
 <\/pre>\n
} OBJECT_ATTRIBUTES, *POBJECT_ATTRIBUTES;<\/pre>\n
 <\/pre>\n
typedef<\/span> CONST OBJECT_ATTRIBUTES *PCOBJECT_ATTRIBUTES;<\/pre>\n<\/div>\n
To fill in this structure we use the InitializeObjectAttributes()<\/a> macro.<\/p>\n
\n
VOID <\/pre>\n
  InitializeObjectAttributes(<\/pre>\n
    OUT POBJECT_ATTRIBUTES  InitializedAttributes,<\/pre>\n
    IN PUNICODE_STRING  ObjectName,<\/pre>\n
    IN ULONG  Attributes,<\/pre>\n
    IN HANDLE  RootDirectory,<\/pre>\n
    IN PSECURITY_DESCRIPTOR  SecurityDescriptor<\/pre>\n
    );<\/pre>\n<\/div>\n
The file path is described in the ObjectName<\/span> parameter, which is a pointer to a UNICODE_STRING<\/a>. In Kernel, the full path to a file would be described as “\\Device\\HarddiskVolume0\\Directory\\File.ext” for example. This happens because the “C:” part, which we normally use in the file path in User Mode, is a Symbolic Link<\/span>. Symbolic who?<\/span><\/span> A Symbolic Link<\/span> would be like a shortcut to the name in Kernel Mode. User Mode applications cannot open just any Kernel object right off the bat. So each driver creates Symbolic Links<\/span> for the objects it wants to make available to User Mode. When an application wants to open the file “C:\\Temp\\Test.txt”, the Win32<\/span> subsystem prefixes this path with “\\??\\”, which is the starting directory of this search, resulting in “\\??\\C:\\Temp\\Test.txt”. When this name reaches the Object Manager<\/a>, the prefix indicates that the search must start in the “\\DosDevices” directory, the same one we used in the call to the IoCreateSymbolicLink()<\/a> API. Anyway, skipping some details to finish this post still in this lifetime, the prefix will take us to the “\\GLOBAL??\\” directory. After the “\\??” prefix was processed, the next part to be processed is “C:”. Using the WinObj<\/a> tool from Sysinternals<\/a> illustrated in the figure below, we see that here on my machine “C:” will be replaced by “\\Device\\HarddiskVolume3”, which in this case is the path to the device that will receive the rest of the string to be processed. After this substitution is done, the string is now “\\Device\\HarddiskVolume3\\Temp\\Test.txt”. The Object Manager<\/span> now starts processing the string again and finds the device described in it.<\/p>\n
\"\"<\/div>\n

<\/p>\n
After that, knowing that it is a data volume device, the system consults a structure called the Volume Parameter Block<\/span> (VPB). It creates a link that will tell us whether the indicated volume was mounted by some File System<\/a> driver. In my case, NTFS would be this driver. The device it created would do the rest of the string handling to find the desired file. You will not have to go through this whole path to open the file. Just put the “\\??\\” prefix in the path of the file you want to open and all your problems are over and done with<\/a>. If you want more details about the name translations that occur during the opening of a file, this article<\/a> from OSR Online<\/a> is great. This is the link<\/a> to the reference that talks about this.<\/p>\n
After it is open, reading the file becomes easy with the ZwReadFile()<\/a> routine.<\/p>\n
\n
NTSTATUS <\/pre>\n
  ZwReadFile(<\/pre>\n
    IN HANDLE  FileHandle,<\/pre>\n
    IN HANDLE  Event  OPTIONAL,<\/pre>\n
    IN PIO_APC_ROUTINE  ApcRoutine  OPTIONAL,<\/pre>\n
    IN PVOID  ApcContext  OPTIONAL,<\/pre>\n
    OUT PIO_STATUS_BLOCK  IoStatusBlock,<\/pre>\n
    OUT PVOID  Buffer,<\/pre>\n
    IN ULONG  Length,<\/pre>\n
    IN PLARGE_INTEGER  ByteOffset  OPTIONAL,<\/pre>\n
    IN PULONG  Key  OPTIONAL<\/pre>\n
    )<\/pre>\n<\/div>\n
The steps needed to open and read a file can be summarized in this little example that follows.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     ReadTestFile<\/span><\/pre>\n
**<\/span><\/pre>\n
**      Routine that demonstrates in a simple way how to open and<\/span><\/pre>\n
**      read a file.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS ReadTestFile(PVOID     pBuffer,<\/pre>\n
                      ULONG     cbBuffer,<\/pre>\n
                      PULONG    pulBytesRead)<\/pre>\n
{<\/pre>\n
    UNICODE_STRING      usFileName;<\/pre>\n
    OBJECT_ATTRIBUTES   ObjAttributes;<\/pre>\n
    IO_STATUS_BLOCK     IoStatusBlock;<\/pre>\n
    HANDLE              hFile = NULL;<\/pre>\n
    NTSTATUS            nts = STATUS_SUCCESS;<\/pre>\n
 <\/pre>\n
    \/\/-f--> We build the UNICODE_STRING containing the path<\/span><\/pre>\n
    \/\/      of the file we want to open<\/span><\/pre>\n
    RtlInitUnicodeString(&usFileName,<\/pre>\n
                         L\"\\\\??\\\\C:\\\\Temp\\\\Test.txt\"<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here the macro helps us with the<\/span><\/pre>\n
    \/\/      OBJECT_ATTRIBUTES structure<\/span><\/pre>\n
    InitializeObjectAttributes(&ObjAttributes,<\/pre>\n
                               &usFileName,<\/pre>\n
                               OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE,<\/pre>\n
                               NULL,<\/pre>\n
                               NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we open the file.<\/span><\/pre>\n
    nts = ZwCreateFile(&hFile,<\/pre>\n
                       GENERIC_READ | SYNCHRONIZE,<\/pre>\n
                       &ObjAttributes,<\/pre>\n
                       &IoStatusBlock,<\/pre>\n
                       NULL,<\/pre>\n
                       FILE_ATTRIBUTE_NORMAL,<\/pre>\n
                       FILE_SHARE_READ,<\/pre>\n
                       FILE_OPEN,<\/pre>\n
                       FILE_SYNCHRONOUS_IO_NONALERT,<\/pre>\n
                       NULL,<\/pre>\n
                       0<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Returns the error in case of failure.<\/span><\/pre>\n
    if<\/span> (!NT_SUCCESS(nts))<\/pre>\n
        return<\/span> nts;<\/pre>\n
 <\/pre>\n
    \/\/-f--> A simple read from the file.<\/span><\/pre>\n
    nts = ZwReadFile(hFile,<\/pre>\n
                     NULL,<\/pre>\n
                     NULL,<\/pre>\n
                     NULL,<\/pre>\n
                     &IoStatusBlock,<\/pre>\n
                     Buffer,<\/pre>\n
                     cbBuffer,<\/pre>\n
                     NULL,<\/pre>\n
                     NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> In case of failure, closes the file, returns the<\/span><\/pre>\n
    \/\/      error and pretends it is not your problem.<\/span><\/pre>\n
    if<\/span> (!NT_SUCCESS(nts))<\/pre>\n
    {<\/pre>\n
        ZwClose(hFile);<\/pre>\n
        return<\/span> nts;<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we get the number of bytes read<\/span><\/pre>\n
    *pulBytesRead = IoStatusBlock.Information;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Closes the file handle<\/span><\/pre>\n
    ZwClose(hFile);<\/pre>\n
    return<\/span> nts;<\/pre>\n
}<\/pre>\n<\/div>\n
The proof of concept<\/h3>\n
Now that we all know how to read a file, it becomes easier to explain how I made a driver that would simulate the readings of a gyroscope just by reading the content of a file. During the existence of this blog, we have already seen how to create a little project from scratch<\/a>, how to compile drivers using Visual Studio<\/a>, we have also seen what an IRP is<\/a>, how to offer read and write services<\/a>, how to use the FsContext<\/a> to keep the context between different operations, and since debugging is part of development, we also saw how to debug drivers<\/a> even on a virtual machine<\/a>. We are going to use all this junk to build a driver that opens a file, stores its handle in a context area, and that as we perform reads on the device it creates and exports, returns the data from a file on disk. This will serve nicely to simulate the continuous readings that LabView<\/span> will make to my USB driver.<\/p>\n
Opening the Device and File<\/h3>\n
The driver will receive an IRP_MJ_CREATE<\/a> call when a handle to the device is opened. I am going to take advantage of this event to already open the file and store its resulting handle in the FsContext<\/span> of the FILE_OBJECT<\/a> that I will receive. If you are lost, take a look at the posts indicated earlier.<\/p>\n
And what if the file does not exist?<\/span><\/span><\/p>\n
Well, in case such unfortunate events occur, I am going to return the error through the IRP received itself. So, in case the file does not exist or you do not have permission to open it, the error code can be checked through the GetLastError()<\/a> routine in case we get INVALID_HANDLE_VALUE as the return from opening the device handle.<\/p>\n
Take a look at how the opening of the device handle turned out, which in the same operation opens the handle to the file. Attention, do not mix things up. The application will get the handle to the device, and through it, will perform reads on the device. The device in turn will use the file handle to perform reads and return the data to the application.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     OnCreate<\/span><\/pre>\n
**<\/span><\/pre>\n
**      The application is calling CreateFile with the path<\/span><\/pre>\n
**      of our device.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS OnCreate(PDEVICE_OBJECT    pDeviceObj,<\/pre>\n
                  PIRP              pIrp)<\/pre>\n
{<\/pre>\n
    UNICODE_STRING      usFileName;<\/pre>\n
    OBJECT_ATTRIBUTES   ObjAttributes;<\/pre>\n
    IO_STATUS_BLOCK     IoStatusBlock;<\/pre>\n
    PIO_STACK_LOCATION  pStack;<\/pre>\n
    NTSTATUS            nts = STATUS_SUCCESS;<\/pre>\n
    HANDLE              hFile = NULL;<\/pre>\n
 <\/pre>\n
    \/\/-f--> We build the UNICODE_STRING containing the path<\/span><\/pre>\n
    \/\/      of the file we want to open<\/span><\/pre>\n
    RtlInitUnicodeString(&usFileName,<\/pre>\n
                         L\"\\\\??\\\\C:\\\\Temp\\\\Test.txt\"<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here the macro helps us with the<\/span><\/pre>\n
    \/\/      OBJECT_ATTRIBUTES structure<\/span><\/pre>\n
    InitializeObjectAttributes(&ObjAttributes,<\/pre>\n
                               &usFileName,<\/pre>\n
                               OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE,<\/pre>\n
                               NULL,<\/pre>\n
                               NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we open the file. Since we are going to pass any<\/span><\/pre>\n
    \/\/      error on to the application, we can use the<\/span><\/pre>\n
    \/\/      IO_STATUS_BLOCK structure of our IRP. Otherwise we could<\/span><\/pre>\n
    \/\/      use one created as a local variable.<\/span><\/pre>\n
    nts = ZwCreateFile(&hFile,<\/pre>\n
                       GENERIC_READ | SYNCHRONIZE,<\/pre>\n
                       &ObjAttributes,<\/pre>\n
                       &pIrp->IoStatus,<\/pre>\n
                       NULL,<\/pre>\n
                       FILE_ATTRIBUTE_NORMAL,<\/pre>\n
                       FILE_SHARE_READ,<\/pre>\n
                       FILE_OPEN,<\/pre>\n
                       FILE_SYNCHRONOUS_IO_NONALERT,<\/pre>\n
                       NULL,<\/pre>\n
                       0<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> We are going to store the file handle in our context<\/span><\/pre>\n
    \/\/      area. This allows several test applications<\/span><\/pre>\n
    \/\/      to run at the same time. For that we will have to<\/span><\/pre>\n
    \/\/      get the current Stack Location.<\/span><\/pre>\n
    pStack = IoGetCurrentIrpStackLocation(pIrp);<\/pre>\n
    pStack->FileObject->FsContext = (PVOID)hFile;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Now we just read the file, but we will do that in the read<\/span><\/pre>\n
    \/\/      IRP, just to...<\/span><\/pre>\n
    IoCompleteRequest(pIrp,<\/pre>\n
                      IO_NO_INCREMENT);<\/pre>\n
    return<\/span> nts;<\/pre>\n
}<\/pre>\n<\/div>\n
Note that the ZwCreateFile()<\/span> API asks for a pointer to IO_STATUS_BLOCK<\/a>. I used the same structure that is contained in the IRP we receive. That way I do not have to pass the status of one operation to the other. The application continues getting the handle to the device the same way it always has, but remember that if there is a failure in getting it, the error may have been generated by a problem opening the file handle. Check out how the application will use the driver.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     main<\/span><\/pre>\n
**<\/span><\/pre>\n
**      Application entry point<\/span><\/pre>\n
**<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
int<\/span> __cdecl<\/span> main(int<\/span> argc,<\/pre>\n
                 char<\/span>* argv[])<\/pre>\n
{<\/pre>\n
    char<\/span>    szBuffer[4096<\/span>];<\/pre>\n
    HANDLE  hDevice = NULL;<\/pre>\n
    DWORD   dwError = ERROR_SUCCESS,<\/pre>\n
            dwBytes,<\/pre>\n
            i;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Getting a handle to the device<\/span><\/pre>\n
    printf(\"Opening the device \\\"\\\\\\\\.\\\\FileReader\\\"...\\n\"<\/span>);<\/pre>\n
 <\/pre>\n
    hDevice = CreateFile(\"\\\\\\\\.\\\\FileReader\"<\/span>,<\/pre>\n
                         GENERIC_ALL,<\/pre>\n
                         0<\/span>,<\/pre>\n
                         NULL,<\/pre>\n
                         OPEN_EXISTING,<\/pre>\n
                         0<\/span>,<\/pre>\n
                         NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Checks whether the handle was opened.<\/span><\/pre>\n
    if<\/span> (hDevice == INVALID_HANDLE_VALUE)<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Oops!<\/span><\/pre>\n
        dwError = GetLastError();<\/pre>\n
        printf(\"Error #%d opening device...\\n\"<\/span>,<\/pre>\n
               dwError);<\/pre>\n
        return<\/span> dwError;<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    \/\/-f--> Performs the reads on the device<\/span><\/pre>\n
    while<\/span> (ReadFile(hDevice,<\/pre>\n
                    szBuffer,<\/pre>\n
                    sizeof<\/span>(szBuffer),<\/pre>\n
                    &dwBytes,<\/pre>\n
                    NULL))<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Displays data on the screen<\/span><\/pre>\n
        \/\/      Yeah yeah, I know it is not the most efficient way in the world.<\/span><\/pre>\n
        for<\/span> (i = 0<\/span>; i < dwBytes; i++)<\/pre>\n
            printf(\"%c\"<\/span>, szBuffer[i]);<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    \/\/-f--> Any failure of the ZwReadFile function call is passed on to<\/span><\/pre>\n
    \/\/      the IO_STATUS_BLOCK structure of the IRP. That is why we see this<\/span><\/pre>\n
    \/\/      error here.<\/span><\/pre>\n
    if<\/span> ((dwError = GetLastError()) != ERROR_NO_MORE_ITEMS)<\/pre>\n
        printf(\"\\n\\n Error #%d reading device...\\n\"<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Puts the house in order.<\/span><\/pre>\n
    printf(\"Closing device...\\n\"<\/span>);<\/pre>\n
    CloseHandle(hDevice);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Party's over! Enough!<\/span><\/pre>\n
    return<\/span> dwError;<\/pre>\n
}<\/pre>\n<\/div>\n
Reading the Device and the File<\/h3>\n
We will read the file in a way similar to the opening. We are going to get the file handle from the FsContext<\/span>. This pointer was originally made available so that the driver could store in it the address of a structure defined by the developer. This pointer will always be the same for all operations that use the same FILE_OBJECT<\/span> until the IRP_MJ_CLOSE<\/a> operation is called. Since a handle is something very small, we can store its value instead of a pointer to a structure allocated in memory that contains the handle value.<\/p>\n
Here too we are going to use the passing of the IO_STATUS_BLOCK<\/span> structure to transfer the status of the file read operation to the application.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     OnRead<\/span><\/pre>\n
**<\/span><\/pre>\n
**      Routine that reads from the already<\/span><\/pre>\n
**      opened file.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS OnRead(PDEVICE_OBJECT    pDeviceObj,<\/pre>\n
                PIRP              pIrp)<\/pre>\n
{<\/pre>\n
    NTSTATUS            nts = STATUS_SUCCESS;<\/pre>\n
    PIO_STACK_LOCATION  pStack;<\/pre>\n
    HANDLE              hFile;<\/pre>\n
 <\/pre>\n
    \/\/-f--> We get the current stack location<\/span><\/pre>\n
    pStack = IoGetCurrentIrpStackLocation(pIrp);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we retrieve the file handle.<\/span><\/pre>\n
    ASSERT(pStack->FileObject->FsContext != NULL);<\/pre>\n
    hFile = (HANDLE)pStack->FileObject->FsContext;<\/pre>\n
 <\/pre>\n
    \/\/-f--> A simple read from the file.<\/span><\/pre>\n
    nts = ZwReadFile(hFile,<\/pre>\n
                     NULL,<\/pre>\n
                     NULL,<\/pre>\n
                     NULL,<\/pre>\n
                     &pIrp->IoStatus,<\/pre>\n
                     pIrp->AssociatedIrp.SystemBuffer,<\/pre>\n
                     pStack->Parameters.Read.Length,<\/pre>\n
                     NULL,<\/pre>\n
                     NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> STATUS_END_OF_FILE is not passed on to the application layer<\/span><\/pre>\n
    \/\/      as a read failure, so we will use an error that is easier<\/span><\/pre>\n
    \/\/      to detect.<\/span><\/pre>\n
    if<\/span> (pIrp->IoStatus.Status == STATUS_END_OF_FILE)<\/pre>\n
        nts = pIrp->IoStatus.Status = STATUS_NO_MORE_ENTRIES;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Completes the IRP.<\/span><\/pre>\n
    IoCompleteRequest(pIrp,<\/pre>\n
                      IO_NO_INCREMENT);<\/pre>\n
    return<\/span> nts;<\/pre>\n
}<\/pre>\n<\/div>\n
If our driver returns STATUS_END_OF_FILE<\/span> to the application, the ReadFile()<\/a> API will not signal a failure, but will only report that zero bytes were read. To make it easier to detect the end of file over in the application, I am going to return a different error code, so the ReadFile()<\/span> routine will return FALSE and the read loop will be interrupted.<\/p>\n
Closing the Device and File handle<\/h3>\n
Now it becomes very easy. We are going to close the file handle when the device handle is closed. Nothing much new here.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     OnCleanup<\/span><\/pre>\n
**<\/span><\/pre>\n
**      The handle to our device was closed. Let us<\/span><\/pre>\n
**      take the chance and close the file handle too.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS OnCleanup(PDEVICE_OBJECT    pDeviceObj,<\/pre>\n
                   PIRP              pIrp)<\/pre>\n
{<\/pre>\n
    PIO_STACK_LOCATION  pStack;<\/pre>\n
    HANDLE              hFile;<\/pre>\n
 <\/pre>\n
    \/\/-f--> We get the current stack location<\/span><\/pre>\n
    pStack = IoGetCurrentIrpStackLocation(pIrp);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we retrieve the file handle.<\/span><\/pre>\n
    ASSERT(pStack->FileObject->FsContext != NULL);<\/pre>\n
    hFile = (HANDLE)pStack->FileObject->FsContext;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Closes the handle<\/span><\/pre>\n
    ZwClose(hFile);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Completes the IRP normally<\/span><\/pre>\n
    pIrp->IoStatus.Status = STATUS_SUCCESS;<\/pre>\n
    pIrp->IoStatus.Information = 0<\/span>;<\/pre>\n
    IoCompleteRequest(pIrp,<\/pre>\n
                      IO_NO_INCREMENT);<\/pre>\n
 <\/pre>\n
    return<\/span> STATUS_SUCCESS;<\/pre>\n
}<\/pre>\n<\/div>\n
If you have been a reader of this blog for a while, you will see that the rest of the driver contains elementary code that has already been commented on in other posts. In any case, both the driver source and the test application source are available for download. In case you have any doubt, just send an e-mail. I usually say that you will only need to hope that I know the answer, but lately you will also have to hope that I also have time to answer.<\/p>\n
As always, I hope I have helped.
\n Have fun!<\/p>\n
FileReader.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
As you saw in my last post, my graduation project will use a tool called LabView to receive and handle data from a USB board. This data will be collected from a device called a gyroscope using TTL 232, which is an RS 232 with voltages of 0 and 5 volts. But as a proof […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-382","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/382","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=382"}],"version-history":[{"count":2,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/382\/revisions"}],"predecessor-version":[{"id":391,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/382\/revisions\/391"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=382"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=382"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=382"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}