CcCopyWriteEx causing nt!KiPageFault

Hello experts!

So I have been running my FSD without file caching, but thought it about
time to attempt to implement it. I can almost compile my sources on my
filesystem using visual studio. (vs is a pretty thorough filesystem tester!)

I’m not entirely sure how it hangs together, mostly just reading fastfat
sources, but in my write function I go through something like:

if (!nocache && !CcCanIWrite(fileObject, bufferLength, TRUE, FALSE))
return STATUS_PENDING;

  • if (!nocache) {
  • if (fileObject->PrivateCacheMap == NULL) {
    /* more details setting up filesizes and callbacks */
  • CcInitializeCacheMap(fileObject, &ccfs, FALSE,
  • &CacheManagerCallbacks, vp);
    }

/* later */

  • if (!FlagOn(IrpSp->MinorFunction, IRP_MN_MDL)) {
  • void *SystemBuffer;
  • if (!Irp->AssociatedIrp.SystemBuffer) {
  • if (!Irp->MdlAddress)
  • SystemBuffer = Irp->UserBuffer;
  • else
  • SystemBuffer =
    MmGetSystemAddressForMdlSafe(Irp->MdlAddress, NormalPagePriority);
  • } else {
  • SystemBuffer = Irp->AssociatedIrp.SystemBuffer;
  • }
  • if (!CcCopyWriteEx(fileObject,
  • &byteOffset,
  • bufferLength,
  • TRUE,
  • SystemBuffer,
  • Irp->Tail.Overlay.Thread)) {
  • dprintf(“Could not wait\n”);
  • }

And CacheManagerCallbacks sets 4 callbacks which just acquire (or release)
FileHeader.Resource (or FileHeader.PagingIoResource).

Dragging some files onto my volume in explorer, it starts to copy, and
everything works until the first .EXE file:

BugCheck 3B, {c0000005, fffff8037da7217c, ffffa187aa5686f0, 0}

Probably caused by : ZFSin.sys ( ZFSin!fs_write+4a9 )

nt!DbgBreakPointWithStatus C/C++/ASM Symbols loaded.
nt!KiBugCheckDebugBreak+0x12 C/C++/ASM Symbols loaded.
nt!KeBugCheck2+0x937 C/C++/ASM Symbols loaded.
nt!KeBugCheckEx+0x107 C/C++/ASM Symbols loaded.
nt!KiBugCheckDispatch+0x69 C/C++/ASM Symbols loaded.
nt!KiSystemServiceHandler+0x7c C/C++/ASM Symbols loaded.
nt!RtlpExecuteHandlerForException+0xd C/C++/ASM Symbols loaded.
nt!RtlDispatchException+0x430 C/C++/ASM Symbols loaded.
nt!KiDispatchException+0x144 C/C++/ASM Symbols loaded.
nt!KiExceptionDispatch+0xce C/C++/ASM Symbols loaded.
nt!KiPageFault+0x4f3 C/C++/ASM Symbols loaded.
nt!MmCopyToCachedPage+0xbc C/C++/ASM Symbols loaded.
nt!CcMapAndCopyInToCache+0x4ae C/C++/ASM Symbols loaded.
nt!CcCopyWriteEx+0x10b C/C++/ASM Symbols loaded.

ZFSin!fs_write+0x4a9
[c:\src\zfsin\zfsin\zfs\module\zfs\zfs_vnops_windows.c @ 3389] C/C++/ASM
Symbols loaded.
ZFSin!fsDispatcher+0xfa1
[c:\src\zfsin\zfsin\zfs\module\zfs\zfs_vnops_windows.c @ 4630] C/C++/ASM
Symbols loaded.
ZFSin!dispatcher+0x1b9
[c:\src\zfsin\zfsin\zfs\module\zfs\zfs_vnops_windows.c @ 4728] C/C++/ASM
Symbols loaded.
nt!IofCallDriver+0x59 C/C++/ASM Symbols loaded.
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x1a3 C/C++/ASM
Symbols loaded.
FLTMGR!FltpDispatch+0xb6 C/C++/ASM Symbols loaded.
nt!IofCallDriver+0x59 C/C++/ASM Symbols loaded.
nt!IopSynchronousServiceTail+0x19e C/C++/ASM Symbols loaded.
nt!NtWriteFile+0x8b0 C/C++/ASM Symbols loaded.
nt!KiSystemServiceCopyEnd+0x13 C/C++/ASM Symbols loaded.
ntdll!NtWriteFile+0x14 C/C++/ASM Symbols loaded.

Clearly I am doing something wrong, but I am unsure what. The only variable
that isn’t from the given IRP, is the “SystemBuffer” that I pass in, but it
does have a valid address, which came from MmGetSystemAddressForMdlSafe().

If I delete the .exe it copies about 6% more, then dies inside a .pack file
from git. So it isn’t just executables (as if it was page permissions).

Obviously this is far too little information for anyone to be able to help
directly, and nobody wants to go through all the code I have written. But
are there any suggestions as to what it could be, and where I should look next?

Also, is there a write up about adding cache support? Where it outlines the
functions to call, say in IRP_CREATE, and CLEANUP etc… perhaps I missed
crucial code in another IRP.

Sincerely,

Lund


Jorgen Lundman |
Unix Administrator | +81 (0)90-5578-8500
Shibuya-ku, Tokyo | Japan

A common cause of CcCopyWrite failing like that is if the lengths aren’t
correct as far as Cc is concerned…

Rod Widdowson wrote:
> A common cause of CcCopyWrite failing like that is if the lengths aren’t
> correct as far as Cc is concerned…
>

Nice, spot on!

CcSetFileSizes: alloc 0 Valid 230 FileSize 230

Mainly as I wasn’t too sure what to set AllocationSize to, since in ZFS it
can be smaller than the file. But for now, I will just use
P2ROUNDUP(filesize, PAGE_SIZE);

Cheers!

Lund


Jorgen Lundman |
Unix Administrator | +81 (0)90-5578-8500
Shibuya-ku, Tokyo | Japan

> Mainly as I wasn’t too sure what to set AllocationSize to,

As a FU here. Allocation size is almost (but not quite) as confusing a VDL.

P2ROUNDUP(filesize, PAGE_SIZE);

I gave up putting what the filesystem says into Cc some time ago and
standardized on that.

PS ZFS on Windows sounds quite exciting.