Jump-start your project by learning from devs who
write Windows drivers and file systems every day.
Take an OSR seminar!

OSR is Hiring! Click here to find out more.

Upcoming OSR Seminars:
Windows Internals & Software Drivers Lab, Santa Clara, CA 5-9 August, 2013
Kernel Debugging & Crash Analysis for Windows Lab, Santa Clara, CA 9-13 September, 2013
Writing WDF Drivers for Windows Lab, Boston, MA 7-11 October, 2013
Developing File Systems for Windows, Seattle, WA 5-8 November, 2013


Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 9  
29 Jun 12 09:17
adnan
xxxxxx@gmail.com
Join Date: 08 Mar 2012
Posts To This List: 113
CcFastCopyRead

Hi All, I have a BSOD on CcFastCopyRead The File is < 4GB It reads the file well, but when I get a call with IoStackLocation->Parameters.Read.Length that is not usual (and greater then usual 1000) it is 20000. Normally the PageCount is 1 or 2. But in this case it is 0x21. (Found using ADDRESS_AND_SIZE_TO_SPAN_PAGES). The same code works fine for CcCopyRead, and I never found this unusual length.
  Message 2 of 9  
01 Jul 12 13:53
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 23 Feb 2000
Posts To This List: 3966
Re: CcFastCopyRead

> I have a BSOD on CcFastCopyRead Where is the stack? -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 3 of 9  
02 Jul 12 03:15
adnan
xxxxxx@gmail.com
Join Date: 08 Mar 2012
Posts To This List: 113
RE: CcFastCopyRead

Stack is as follows: WARNING: Stack unwind information not available. Following frames may be wrong. nt!DbgBreakPointWithStatus+0x4 nt!KeBugCheckEx+0xc7b nt!KeBugCheckEx+0x1e nt!CcCopyRead+0x17b nt!CcFastCopyRead+0x28 MyDriver!ReadFile+0x87c MyDriver!Read+0x162 MyDriver!DispatchRequest+0x84 MyDriver!IRPDispatcher+0x138 nt!IofCallDriver+0x64 nt!NtQueryInformationThread+0x5cd8 nt!NtReadFile+0x64e nt!ZwYieldExecution+0xb62 ntdll!KiIntSystemCall+0x6 0xbadb0d00 0x201d7b4 kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* CACHE_MANAGER (34) See the comment for FAT_FILE_SYSTEM (0x23) Arguments: Arg1: 000001f4 Arg2: c0000420 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------ ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ADDITIONAL_DEBUG_TEXT: Use '!findthebuild' command to search for the target build information. If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols. MODULE_NAME: MyDriver FAULTING_MODULE: 8282c000 nt DEBUG_FLR_IMAGE_TIMESTAMP: 4fed8969 EXCEPTION_RECORD: c0000420 -- (.exr 0xffffffffc0000420) ExceptionAddress: 0e6ad867 ExceptionCode: 06b9c867 ExceptionFlags: 069dd867 NumberParameters: 238483559 Parameter[0]: 0e72e867 Parameter[1]: 0e570867 Parameter[2]: 06c1b867 Parameter[3]: 06dde867 Parameter[4]: 0699d867 Parameter[5]: 0bd22867 Parameter[6]: 06285867 Parameter[7]: 06244867 Parameter[8]: 0d3e9847 Parameter[9]: 0d9ea847 Parameter[10]: 0d3e8867 Parameter[11]: 0d3e7867 Parameter[12]: 0e472867 Parameter[13]: 0e874867 Parameter[14]: 0eebc867 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x34 CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from 828ff055 to 82884cf0 STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 9623460c 828ff055 00000003 843fcb90 96234a4c nt!DbgBreakPointWithStatus+0x4 962349d0 828fe3f8 00000034 000001f4 c0000420 nt!KeBugCheckEx+0xc7b 962349f4 82a85194 00000034 000001f4 c0000420 nt!KeBugCheckEx+0x1e 96234a2c 829cd759 843f96e8 96234a4c 00020000 nt!CcCopyRead+0x17b 96234a54 909cb2fc 843f96e8 00000000 00020000 nt!CcFastCopyRead+0x28 96234b84 909cb832 843b35c0 843f96e8 850207a0 MyDriver!ReadFile+0x87c [read.c @ 572] 96234be0 909c85d4 843b35c0 00000003 850206e8 MyDriver!Read+0x162 [read.c @ 743] 96234bfc 909c8aa8 843b35c0 06bee1a1 843f96e8 MyDriver!DispatchRequest+0x84 [irp.c @ 1110] 96234c44 8285b012 850206e8 843fcc08 843fcc08 MyDriver!IRPDispatcher+0x138 [irp.c @ 1285] 96234c5c 82a30a5d 843fcc08 843fcde0 843f96e8 nt!IofCallDriver+0x64 96234c7c 82a31944 850206e8 843f96e8 00000001 nt!NtQueryInformationThread+0x5cd8 96234d08 8286185a 850206e8 843fcc08 00000000 nt!NtReadFile+0x64e 96234d34 77bb70a6 badb0d00 0201d7b4 00000000 nt!ZwYieldExecution+0xb62 96234d38 badb0d00 0201d7b4 00000000 00000000 ntdll!KiIntSystemCall+0x6 96234d3c 0201d7b4 00000000 00000000 00000000 0xbadb0d00 96234d40 00000000 00000000 00000000 00000000 0x201d7b4 STACK_COMMAND: kb FOLLOWUP_IP: MyDriver!ReadFile+87c [read.c @ 572] 909cb2fc c745fc00000000 mov dword ptr [ebp-4],0 FAULTING_SOURCE_CODE: 566: CcFastCopyRead(pFileObject, 567: (ULONG)nBytesOffset.QuadPart, 568: nLength, 569: nPageCount, 570: pBuffer, 571: &Irp->IoStatus); > 572: } 573: __except(MyDriverExceptionHandler(GetExceptionCode())) { 574: DbgPrint(DRIVER_NAME ": Caught Exception\n"); 575: nStatus = Irp->IoStatus.Status; 576: __leave; 577: } SYMBOL_STACK_INDEX: 5 SYMBOL_NAME: MyDriver!ReadFile+87c FOLLOWUP_NAME: MachineOwner IMAGE_NAME: MyDriver.sys BUCKET_ID: WRONG_SYMBOLS Followup: MachineOwner ---------
  Message 4 of 9  
02 Jul 12 03:29
rod widdowson
xxxxxx@steadingsoftware.com
Join Date: 11 Sep 2006
Posts To This List: 612
Re: CcFastCopyRead

I don't *know* that this is relevant, but: > Arg2: c0000420 // An assertion failure has occurred. // #define STATUS_ASSERTION_FAILURE ((NTSTATUS)0xC0000420L) // winnt Are you running a checked kernel? Have you tried with a debugger attached?
  Message 5 of 9  
02 Jul 12 04:25
adnan
xxxxxx@gmail.com
Join Date: 08 Mar 2012
Posts To This List: 113
RE: CcFastCopyRead

I'm running a virtual kernel with debugger attached. By the way, the same code work fine when I use CcCopyRead instead of CcFastCopyRead. I just recently found CcFastCopyRead is faster version of CcCopyRead. So I thought to use it.
  Message 6 of 9  
02 Jul 12 11:14
Tony Mason
xxxxxx@osr.com
Join Date:
Posts To This List: 2356
List Moderator
RE: RE:CcFastCopyRead

How can CcFastCopyRead be *faster* than CcCopyRead if the former just calls the latter? And faster by what measure? I/O performance? CPU cycles? My best guess (based upon the very limited information you've been willing to divulge) is that you haven't set something up properly or you passed in an invalid parameter to CcFastCopyRead. But without more detailed information, it's almost impossible to suggest what you are doing wrong. Tony OSR
  Message 7 of 9  
03 Jul 12 04:20
adnan
xxxxxx@gmail.com
Join Date: 08 Mar 2012
Posts To This List: 113
RE: CcFastCopyRead

How can CcFastCopyRead be *faster*. Good question. I am also looking the the call stack, CcFastCopyRead calls CcCopyRead internally. But see the following http://msdn.microsoft.com/en-us/library/windows/hardware/ff539067(v=vs.85).aspx and http://www.osronline.com/ShowThread.cfm?link=147538 Now question is, i'm not using anything silly. The limitations are just < 4GB for CcFastCopyRead, nothing else. Seems documentation missing or something else. What else information you need, please let me know.
  Message 8 of 9  
04 Jul 12 09:27
Tony Mason
xxxxxx@osr.com
Join Date:
Posts To This List: 2356
List Moderator
RE: RE:CcFastCopyRead

The documentation is likely just suspect in this area - I suspect the documentation writer read the code comments and documented based upon them. You will need to do some debugger work to figure out why the call to CcFastCopyRead fails and the call to CcCopyRead works. Tony OSR
  Message 9 of 9  
05 Jul 12 02:32
rod widdowson
xxxxxx@steadingsoftware.com
Join Date: 11 Sep 2006
Posts To This List: 612
Re: CcFastCopyRead

FWIW I have always assumed that the the 'Fast' in CcFastCopyRead means "targetted for FastIo". I see from your stack that you are in the IRP dispatch path. My suspicion has long been that, the way that processors have moved forward (particularly the processor speed/memory speed split) since the early 90's (late 80s?) that FastIO and its related RTL is mostly not worth the effort... But that just a suspicion..
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 08:07.


Copyright ©2012, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license