none
ZwCreateFile/ZwWriteFile issue

    Question

  • Hello,

    So, our kmdf driver creates two output files: (1) To L"\\SystemRoot\\Temp\\myfile.xml"; and (2) L"\\DosDevices\\c:\\temp\\myfile.xml".  All of the following code returned STATUS_SUCCESS (0x0) after completing their calls, but when I looked in these two directories, the files did not exist.  I rebooted our test computer, and then I found \\SystemRoot\\Temp\\myfile.xml, but it was empty.  So, I am trying to figure out the following:

    1) Why didn't the files appear before I rebooted the computer;

    2) Since all of these functions returned success, why didn't I find the file in both of the directories?

    3) Since all of these functions returned success, why is \\SystemRoot\\Temp\\myfile.xml empty?

    I looked to see if there was a function that had to be called to flush the file buffers before closing, but I didn't see anything in Zw namespace.  I thought that there may be something like FlushFileBuffers(), but I couldn't find anything.

    I would appreciate your suggestions as to what I am doing wrong...  I've included my test code so you can see what I am doing...

    Thank you for your help!

    Mike

    ====================

    OBJECT_ATTRIBUTES attributes; 
    UNICODE_STRING uniName; 
    BOOLEAN res = FALSE;
    wchar_t* msg = L"Hi Mike!";

    ////////////////// TO SYSTEMROOT PATH ////////////// 
    RtlInitUnicodeString(&uniName, L"\\SystemRoot\\Temp\\myfile.xml");     
    InitializeObjectAttributes(&attributes, &uniName,
                        (OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE), NULL, NULL);
    status = ZwCreateFile(&hFile,
         (GENERIC_WRITE | SYNCHRONIZE),
         &attributes,
         &ioStatus,
         NULL,
         FILE_ATTRIBUTE_NORMAL,
         0,
         FILE_SUPERSEDE,      
         (FILE_NON_DIRECTORY_FILE |
         FILE_SEQUENTIAL_ONLY |
         FILE_SYNCHRONOUS_IO_NONALERT),
         NULL,
         0);    
    status = ZwWriteFile(hFile, NULL, NULL, NULL, &ioStatus,
                        msg, (USHORT) wcslen(msg) * sizeof(wchar_t), NULL, NULL);
    //res = FlushFileBuffers(hFile);
    status = ZwClose(hFile);
    hFile = NULL;


    /////////////////// TO DOSDEVICES PATH ///////////
    RtlInitUnicodeString(&uniName, L"\\DosDevices\\c:\\temp\\myfile.xml");        
    InitializeObjectAttributes(&attributes, &uniName,
                        (OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE), NULL, NULL);
    status = ZwCreateFile(&hFile,
         (GENERIC_WRITE | SYNCHRONIZE),
         &attributes,
         &ioStatus,
         NULL,
         FILE_ATTRIBUTE_NORMAL,
         0,
         FILE_SUPERSEDE,      
         (FILE_NON_DIRECTORY_FILE |
         FILE_SEQUENTIAL_ONLY |
         FILE_SYNCHRONOUS_IO_NONALERT),
         NULL,
         0);    
    status = ZwWriteFile(hFile, NULL, NULL, NULL, &ioStatus,
          msg, (USHORT) wcslen(msg) * sizeof(wchar_t), NULL, NULL);
    //res = FlushFileBuffers(hFile);      
    status = ZwClose(hFile);

     

    Thursday, January 20, 2011 3:08 AM

Answers

  • Hi Everyone,

    Well, I have kind of resolved the issue...  I was getting a memory allocation error that did not make sense, and discovered/remembered that I had Driver Verifier turned on to similate low memory conditions.  When I disabled Driver Verifier, my code worked perfectly.  So, I wondered whether it may have affected the issue that I posted here.  When I ran the above code without Driver Verifier being enabled, I received an INVALID_KERNEL_HANDLE error and a dump.  When I deleted the \\DosDevices\\ code above, the other write to \\SystemRoot\\ worked properly and the invalid handle error disappeared.  So, I cannot explain why the \\DosDevices\\ code didn't work, but it doesn't matter for my application because we want to use \\SystemRoot\\Temp.  So, I am coping out on the \\DosDevices\\ question.

    Thank you for your comments, :)

    Mike

    • Marked as answer by ABOHAK Friday, January 21, 2011 8:08 AM
    Friday, January 21, 2011 8:07 AM

All replies

  • do you ever close the handle? a lot of metadata is only flushed to the disk when you close the handle
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, January 20, 2011 6:09 PM
    Owner
  • Could it be the following in the create statement?

     (GENERIC_WRITE | SYNCHRONIZE),

    or

         FILE_SUPERSEDE,      
         (FILE_NON_DIRECTORY_FILE |
         FILE_SEQUENTIAL_ONLY |
         FILE_SYNCHRONOUS_IO_NONALERT),

    I've reread the info on MSDN for these Zw functions and don't see any issues...  But, I know that I must be doing something wrong! :P

    Thursday, January 20, 2011 9:03 PM
  • Hi Everyone,

    Well, I have kind of resolved the issue...  I was getting a memory allocation error that did not make sense, and discovered/remembered that I had Driver Verifier turned on to similate low memory conditions.  When I disabled Driver Verifier, my code worked perfectly.  So, I wondered whether it may have affected the issue that I posted here.  When I ran the above code without Driver Verifier being enabled, I received an INVALID_KERNEL_HANDLE error and a dump.  When I deleted the \\DosDevices\\ code above, the other write to \\SystemRoot\\ worked properly and the invalid handle error disappeared.  So, I cannot explain why the \\DosDevices\\ code didn't work, but it doesn't matter for my application because we want to use \\SystemRoot\\Temp.  So, I am coping out on the \\DosDevices\\ question.

    Thank you for your comments, :)

    Mike

    • Marked as answer by ABOHAK Friday, January 21, 2011 8:08 AM
    Friday, January 21, 2011 8:07 AM
  • so now after all your fixes, have you enabled driver verifier and confirmed that it does not complain?
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, January 21, 2011 6:22 PM
    Owner
  • Oh yeah ... enable WDF Verifier also, and have you taken a look at the Prefast output as well as run ChkInf on you INF file? And Please please have WinDbg connected via a 1394 connection.

    Gary G. Little NanoTelesis Systems, LLC
    Saturday, January 22, 2011 3:37 AM