Error with writing files

Hi,

I have a problem of writing files in driver.

I use this to create file:
status = ZwCreateFile(
FileHandle,
SYNCHRONIZE | GENERIC_ALL,
&oa,
&IoStatus,
NULL,
FILE_ATTRIBUTE_NORMAL,
0, // FILE_SHARE_READ, // | FILE_SHARE_WRITE,
FILE_OPEN,
FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE, // | FILE_WRITE_THROUGH,
NULL,
0
);

After that, I call:
status = ZwWriteFile(
*FileHandle,
NULL,
NULL,
NULL,
&IoStatus,
Buffer,
(ULONG)NumberOfBytesToWrite,
ByteOffset,
NULL
);
to write data. But sometimes ZwWriteFile hangs after couple successful calls. However, I’m pretty sure that ZwWriteFile runs in a worker thread which is a part of Csq fashion. Is there any proble with such Cancel-safe-queue worker thread?

Then, with the previous failures, I change the code to:
status = ObReferenceObjectByHandle(
*FileHandle,
0,
*IoFileObjectType,
KernelMode,
(PVOID*)&FileObject,
NULL
);
if(status == STATUS_SUCCESS)
{
DeviceObject = IoGetRelatedDeviceObject(FileObject);
if(DeviceObject)
{
Irp = IoBuildSynchronousFsdRequest(
IRP_MJ_WRITE,
DeviceObject,
Buffer,
(ULONG)NumberOfBytesToWrite,
ByteOffset,
&Event,
&IoStatus
);
if(Irp)
{

status = IoCallDriver(DeviceObject, Irp);

However, this code also causes BSOD when IoCallDriver gets executes:
NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00190292
Arg2: f7a7ab00
Arg3: f7a7a7fc
Arg4: 804ee55c

Debugging Details:

EXCEPTION_RECORD: f7a7ab00 – (.exr fffffffff7a7ab00)
ExceptionAddress: 804ee55c (nt!IoIsOperationSynchronous+0x0000000e)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000002c
Attempt to read from address 0000002c

CONTEXT: f7a7a7fc – (.cxr fffffffff7a7a7fc)
eax=fdc06008 ebx=fdc06008 ecx=00000000 edx=fdc06008 esi=f7a7abe0 edi=804ee54e
eip=804ee55c esp=f7a7abc8 ebp=f7a7abc8 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!IoIsOperationSynchronous+0xe:
804ee55c f6412c02 test byte ptr [ecx+2Ch],2 ds:0023:0000002c=??
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

READ_ADDRESS: 0000002c

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f7310c0c to 804ee55c

STACK_TEXT:
f7a7abc8 f7310c0c fdc06008 00000000 82f6c910 nt!IoIsOperationSynchronous+0xe
f7a7ac28 804eddf9 82faa020 fdc06008 fdc8ab78 Ntfs!NtfsFsdWrite+0x3e

Any idea about writing file in a driver?

BTW: ZwReadFile always works fine at all time. So weird…

A 5s look at the bug check tends to indicate you provide NTFS with an invalid buffer.

On Thu, 1 Mar 2007 04:42:50 -0500 (EST), xxxxx@gmail.com wrote:

Hi,

I have a problem of writing files in driver.

I use this to create file:
status = ZwCreateFile(
FileHandle,
SYNCHRONIZE | GENERIC_ALL,
&oa,
&IoStatus,
NULL,
FILE_ATTRIBUTE_NORMAL,
0, // FILE_SHARE_READ, // | FILE_SHARE_WRITE,
FILE_OPEN,
FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE, // |
FILE_WRITE_THROUGH,
NULL,
0
);

After that, I call:
status = ZwWriteFile(
*FileHandle,
NULL,
NULL,
NULL,
&IoStatus,
Buffer,
(ULONG)NumberOfBytesToWrite,
ByteOffset,
NULL
);
to write data. But sometimes ZwWriteFile hangs after couple successful
calls. However, I’m pretty sure that ZwWriteFile runs in a worker thread
which is a part of Csq fashion. Is there any proble with such
Cancel-safe-queue worker thread?

Then, with the previous failures, I change the code to:
status = ObReferenceObjectByHandle(
*FileHandle,
0,
*IoFileObjectType,
KernelMode,
(PVOID*)&FileObject,
NULL
);
if(status == STATUS_SUCCESS)
{
DeviceObject = IoGetRelatedDeviceObject(FileObject);
if(DeviceObject)
{
Irp = IoBuildSynchronousFsdRequest(
IRP_MJ_WRITE,
DeviceObject,
Buffer,
(ULONG)NumberOfBytesToWrite,
ByteOffset,
&Event,
&IoStatus
);
if(Irp)
{

status = IoCallDriver(DeviceObject, Irp);

However, this code also causes BSOD when IoCallDriver gets executes:
NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00190292
Arg2: f7a7ab00
Arg3: f7a7a7fc
Arg4: 804ee55c

Debugging Details:

EXCEPTION_RECORD: f7a7ab00 – (.exr fffffffff7a7ab00)
ExceptionAddress: 804ee55c (nt!IoIsOperationSynchronous+0x0000000e)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000002c
Attempt to read from address 0000002c

CONTEXT: f7a7a7fc – (.cxr fffffffff7a7a7fc)
eax=fdc06008 ebx=fdc06008 ecx=00000000 edx=fdc06008 esi=f7a7abe0
edi=804ee54e
eip=804ee55c esp=f7a7abc8 ebp=f7a7abc8 iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
nt!IoIsOperationSynchronous+0xe:
804ee55c f6412c02 test byte ptr [ecx+2Ch],2
ds:0023:0000002c=??
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

READ_ADDRESS: 0000002c

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f7310c0c to 804ee55c

STACK_TEXT:
f7a7abc8 f7310c0c fdc06008 00000000 82f6c910
nt!IoIsOperationSynchronous+0xe
f7a7ac28 804eddf9 82faa020 fdc06008 fdc8ab78 Ntfs!NtfsFsdWrite+0x3e

Any idea about writing file in a driver?

BTW: ZwReadFile always works fine at all time. So weird…


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

EA

Your crash is because you haven’t set the FileObject in the Irp stack
location.

You don’t say what kind of driver this is. If you are in the storage stack
beneath the file system you are writing to, you will naturally see the
results of your own filesystem I/O. If that is the case, your deadlock on
ZwWriteFile is unsurprising. At the very least, you need to make sure you
are holding nothing (mutex, eresource, synchronization event, etc.) when you
make the filesystem call.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, March 01, 2007 2:43 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Error with writing files

Hi,

I have a problem of writing files in driver.

I use this to create file:
status = ZwCreateFile(
FileHandle,
SYNCHRONIZE | GENERIC_ALL,
&oa,
&IoStatus,
NULL,
FILE_ATTRIBUTE_NORMAL,
0, // FILE_SHARE_READ, // | FILE_SHARE_WRITE,
FILE_OPEN,
FILE_SYNCHRONOUS_IO_NONALERT |
FILE_NON_DIRECTORY_FILE, // | FILE_WRITE_THROUGH,
NULL,
0
);

After that, I call:
status = ZwWriteFile(
*FileHandle,
NULL,
NULL,
NULL,
&IoStatus,
Buffer,
(ULONG)NumberOfBytesToWrite,
ByteOffset,
NULL
);
to write data. But sometimes ZwWriteFile hangs after couple successful
calls. However, I’m pretty sure that ZwWriteFile runs in a worker thread
which is a part of Csq fashion. Is there any proble with such
Cancel-safe-queue worker thread?

Then, with the previous failures, I change the code to:
status = ObReferenceObjectByHandle(
*FileHandle,
0,
*IoFileObjectType,
KernelMode,
(PVOID*)&FileObject,
NULL
);
if(status == STATUS_SUCCESS)
{
DeviceObject = IoGetRelatedDeviceObject(FileObject);
if(DeviceObject)
{
Irp = IoBuildSynchronousFsdRequest(
IRP_MJ_WRITE,
DeviceObject,
Buffer,
(ULONG)NumberOfBytesToWrite,
ByteOffset,
&Event,
&IoStatus
);
if(Irp)
{

status = IoCallDriver(DeviceObject,
Irp);

However, this code also causes BSOD when IoCallDriver gets executes:
NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00190292
Arg2: f7a7ab00
Arg3: f7a7a7fc
Arg4: 804ee55c

Debugging Details:

EXCEPTION_RECORD: f7a7ab00 – (.exr fffffffff7a7ab00)
ExceptionAddress: 804ee55c (nt!IoIsOperationSynchronous+0x0000000e)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000002c
Attempt to read from address 0000002c

CONTEXT: f7a7a7fc – (.cxr fffffffff7a7a7fc)
eax=fdc06008 ebx=fdc06008 ecx=00000000 edx=fdc06008 esi=f7a7abe0
edi=804ee54e
eip=804ee55c esp=f7a7abc8 ebp=f7a7abc8 iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
nt!IoIsOperationSynchronous+0xe:
804ee55c f6412c02 test byte ptr [ecx+2Ch],2
ds:0023:0000002c=??
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced
memory at “0x%08lx”. The memory could not be “%s”.

READ_ADDRESS: 0000002c

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f7310c0c to 804ee55c

STACK_TEXT:
f7a7abc8 f7310c0c fdc06008 00000000 82f6c910 nt!IoIsOperationSynchronous+0xe
f7a7ac28 804eddf9 82faa020 fdc06008 fdc8ab78 Ntfs!NtfsFsdWrite+0x3e

Any idea about writing file in a driver?

BTW: ZwReadFile always works fine at all time. So weird…


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Edouard,

I don’t think the buffer is invalid. It’s from SRBs which are sent from disk.sys. This buffer works with ZwWriteFile sometime but totally does not work with IoBuildSynchronousFsdRequest.

Dan,

It’s a port driver to simulate a virtual harddisk. No mutex, spinlock or eresource is held when ZwWriteFile is executing. The file is not on the virtual harddisk, so no recursive calls which could cause deadlock.

I set up FileObject in IoGetNextIrpStackLocation. Now IoBuildSynchronousFsdRequest works but still gets hangs.

You aren’t calling IoBuildSynchronousFsdRequest at >= DISPATCH_LEVEL,
are you? There is no guarantee that SRBs sent from disk.sys are getting
to your driver at < DISPATCH_LEVEL, and you generally need to do
filesystem IO at passive level. To write these out to a filesystem you
need to queue them to a worker thread and perform the filesystem IO at
passive level.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, March 01, 2007 6:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Error with writing files

I set up FileObject in IoGetNextIrpStackLocation. Now
IoBuildSynchronousFsdRequest works but still gets hangs.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I’m pretty sure it’s called at PASSIVE_LEVEL since I queue all SRB-IRPs to a worker thread which is running at PASSIVE_LEVEL. I also call

KeSetPriorityThread(KeGetCurrentThread(), LOW_REALTIME_PRIORITY);

to ensure this. The only thing is I call IoCsqRemoveNextIrp to retrieve the IRP from the queue in the worker thread before processing SRB. Does this call do something special which afffects writing file?

IoCsqRemoveNextIrp is fine to call and KeSetPriorityThread does nothing to change your interrupt level, it adjusts your thread priority level which are two separate concepts.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-279663-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, March 01, 2007 7:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Error with writing files

I’m pretty sure it’s called at PASSIVE_LEVEL since I queue all SRB-IRPs
to a worker thread which is running at PASSIVE_LEVEL. I also call

KeSetPriorityThread(KeGetCurrentThread(), LOW_REALTIME_PRIORITY);

to ensure this. The only thing is I call IoCsqRemoveNextIrp to retrieve
the IRP from the queue in the worker thread before processing SRB. Does
this call do something special which afffects writing file?


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Mark,

Do you mean PsCreateSystemThread always creates a thread which runs at PASSIVE_LEVEL?

Yes


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Mark,
>
> Do you mean PsCreateSystemThread always creates a thread which runs at
PASSIVE_LEVEL?
>

Thanks Maxim. I do not see such comments in DDK about this API. So I always think KeSetPriorityThread takes such job.

Anyway, I still have the problem of hangs on writing files. Hope more gurus could give me more hints.

Finally, with FILE_NO_INTERMEDIATE_BUFFERING on ZwCreateFile, it works fine. It seems that something is wrong with FSD stuff (maybe buffering, I guess). The virtual HDD is in FAT format but the image file is on a NTFS physical disk. I can not get any idea about the relationship between that flag and hangs…

For virtual drive it is the only way which makes sense. You don’t want to have cached both image file and files on the image.

It reminds me old bug I had to solve when worked at similar project years before. There was an occasional deadlock in FastFat driver when a cache for image file existed. I never opened it cached but it was enough if somebody else (a silly antivirus) opened image file cached before because cache isn’t destroyed immediatelly. Maybe NTFS has some similar problem, it’d need investigation. Start is rather easy; reproduce deadlock, invoke debugger (this is a case when debugger can be useful) and dump stack for hung thread. Or for all processes and find hung thread searching for your routine names. Then continue with analysis.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@gmail.com[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, March 02, 2007 5:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Error with writing files

Finally, with FILE_NO_INTERMEDIATE_BUFFERING on ZwCreateFile, it works fine. It seems that something is wrong with FSD stuff (maybe buffering, I guess). The virtual HDD is in FAT format but the image file is on a NTFS physical disk. I can not get any idea about the relationship between that flag and hangs…


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

>For virtual drive it is the only way which makes sense. You don’t want to have

cached both image file and files on the image.

It makes sense to me :slight_smile: For speed up read/write as well.

New problem is, how to get the sector size of a hdd (or a volume?)? I assume that there are some IOCTLs to do this. Searching in DDK…

And another thing is the alignment required by DDK for this flag. I need to find some way to deal with such alignment stuff. Is there any sample?

> New problem is, how to get the sector size of a hdd (or a volume?)? I assume

that there are some IOCTLs to do this. Searching in DDK…

IOCTL_DISK_GET_DRIVE_GEOMETRY(_EX)


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Don’t hesitate to use the PAGED_CODE() macro to switch from pretty sure to absolutely certain. :wink:

Edouard

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-279663-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: vendredi 2 mars 2007 01:22
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Error with writing files

I’m pretty sure it’s called at PASSIVE_LEVEL since I queue all SRB-IRPs
to a worker thread which is running at PASSIVE_LEVEL. I also call

KeSetPriorityThread(KeGetCurrentThread(), LOW_REALTIME_PRIORITY);

to ensure this. The only thing is I call IoCsqRemoveNextIrp to retrieve
the IRP from the queue in the worker thread before processing SRB. Does
this call do something special which afffects writing file?


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Actually running driver verifier might help too. Also, once the system is hung it is a good time to use the debugger to understand why it is hung. !locks is a good place to start.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-279804-
xxxxx@lists.osr.com] On Behalf Of Edouard A.
Sent: Saturday, March 03, 2007 3:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Error with writing files

Don’t hesitate to use the PAGED_CODE() macro to switch from pretty
sure to absolutely certain. :wink:

Edouard

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-279663-
> xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> Sent: vendredi 2 mars 2007 01:22
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Error with writing files
>
> I’m pretty sure it’s called at PASSIVE_LEVEL since I queue all SRB-
IRPs
> to a worker thread which is running at PASSIVE_LEVEL. I also call
>
> KeSetPriorityThread(KeGetCurrentThread(), LOW_REALTIME_PRIORITY);
>
> to ensure this. The only thing is I call IoCsqRemoveNextIrp to
retrieve
> the IRP from the queue in the worker thread before processing SRB.
Does
> this call do something special which afffects writing file?
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks guys for PASSIVE_LEVEL talk :slight_smile:

Anther question is the alignment. Is it really necessary for the NTFS/FAT FSD to get an aligned buffer? I cannot get the exact reason from my head for this alignment requirement.

It is important for noncached file IO as the intention is to send this data buffer copy-free straight to disk. Failing to align the buffer makes this difficult.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-279826-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, March 04, 2007 5:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Error with writing files

Thanks guys for PASSIVE_LEVEL talk :slight_smile:

Anther question is the alignment. Is it really necessary for the
NTFS/FAT FSD to get an aligned buffer? I cannot get the exact reason
from my head for this alignment requirement.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks Mark.

I’m really confused by this requirement. The followings are from DDK and MSDN:

====================================================
DDK (ZwCreateFile):
Buffers must be aligned in accordance with the alignment requirement of the underlying device. To obtain this information, call ZwCreateFile to get a handle for the file object that represents the physical device, and pass that handle to ZwQueryInformationFile.

MSDN (CreateFile):
Buffer addresses for read and write operations should be sector aligned, which means aligned on addresses in memory that are integer multiples of the volume sector size. Depending on the disk, this requirement may not be enforced.

I assume Win32 CreateFile is a counterpart of DDK’s ZwCreateFile. The problem is, for CreateFile the required alignment is sector size but for ZwCreateFile it’s not. I’ve tried on several XP on a file in NTFS partitions. The alignment is always FILE_WORD_ALIGNMENT.