i am working on my own customized file system driver based on fat architecture.
I am facing some problem only in win 7 64 bit os when i enable driver verifier "force irql " option.
What is happening inside my Create call it is raising error when i am trying to use “CcCopyread” with paged memory for reading some metadata
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff98011462fd0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80006685d00, address which referenced memory
>>In This Extent is allocated in pageable memory and CcCopyRead is also not recommended to run at Dispatch level.
But my question is…
why this is coming exclusively on Win 7 64 bit os when it is not raising any error on vista(32/64) win 7 32 bit OS.
will it be Ok if i just come out after checking that irql level is = Dispatch level from IRP_MJ_CREATE call??? <<
Well, they change verifier from time to time. For example, in Vista you have disk integrity checks (always was attracting my attention because of false positive bsods), while in 7 you don’t have this check.
You shoud:
a) check for irql level before calling api functions which can only work at passive level
b) mark the whole function as paged if you expect it to be run only in passive level to catch these problems earlier
Speaking about verifier things. Just yesertday, in my qa lab we got a BSOD in Vista, PFN_LIST_CORRUPT, clean OS, SP2, x32, and verifying afd.sys
i am working on my own customized file system driver based on fat architecture.
I am facing some problem only in win 7 64 bit os when i enable driver verifier "force irql " option.
What is happening inside my Create call it is raising error when i am trying to use “CcCopyread” with paged memory for reading some metadata
IRP_MJ_CREATE is not called at DISPATCH_LEVEL. Therefore, since you are
running at dispatch, YOU must be doing something to raise the IRQL.
Have you grabbed a spinlock? Is this KMDF or WDM?
In This Extent is allocated in pageable memory and CcCopyRead is also not recommended to run at Dispatch level.But my question is…
why this is coming exclusively on Win 7 64 bit os when it is not raising any error on vista(32/64) win 7 32 bit OS.
Remember that it doesn’t cause a blue screen to touch pagable memory at
a raised IRQL, unless that memory happens to be paged out. The blue
screen happens when you try to handle a page fault. So, the crash
depends on the the current state of physical memory, and that is a very
difficult thing to model. It would probably fail sooner or later on the
other operating systems.
will it be Ok if i just come out after checking that irql level is = Dispatch level from IRP_MJ_CREATE call???
What you need to do is figure out WHY you are at dispatch level, if you
did not expect to be there.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
–>as u can check that it is KesyncronizationExecution APi which is increasing the level.
from my side i am calling CcCopyread at right IRQL level( Otherwise i guess CcCopyread would have crashed at Dispatch_level, as it is not recommended at dispatch_level)
the problem comes when i try to make 100 directories using automated script then after making several folders same chunk of code crashes (same code routine already run many times)…
You are not in KeSynchronizeExecution, you are instead in the page
fault handler, as expected. Your symbols seem a bit wrong. However if
you disassemble CcScheduleReadAhead you will indeed see that it
acquires and releases spinlocks - it will raise to dispatch level.
Presumably it does so knowing what it is doing. What is of interest is
the object paged out that caused the bugcheck - what is that memory
used for and should it actually be pageable?
Mark Roddy
On Fri, Nov 19, 2010 at 8:23 AM, wrote: > Thank you Volodymyr & Tim for your quick replies… > > i just did debuging and to the xetent of my disbelief i found some info –> > ?In my call i am not raising the status , i used Paged_code macro > > PAGED_CODE(); > ?if(!CcCopyRead(FileObject, > ? ? ? ? ? ? ? ? ? (PLARGE_INTEGER)(&(Extent->Lba)), > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Extent->Length, > ? ? ? ? ? ? ? ? ? ?BooleanFlagOn(IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT), > ? ? ? ? ? ? ? ? ? ? ? ?(PVOID)((PUCHAR)Buffer + Extent->Offset), > ? ? ? ? ? ? ? ? ? ? ? ?&IoStatus)) > > > > > 0342a060 0000000000000065 fffff800028b3314 : nt!DbgBreakPointWithStatus<br>> fffff880055c39e0 fffff8000296b4be : 0000000000000003 0000000000000000 fffff800028afee0 000000000000000a : nt!HeadlessDispatch+0x192<br>> fffff880055c3a40 fffff80002875004 : fffff98002446e50 fffff9800c546ca0 7ff0000000000000 fffff800028f26a2 : nt!KeEnterKernelDebugger+0x76e<br>> fffff880055c4110 fffff80002874469 : 000000000000000a fffff9800c3d4fd0 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104<br>> fffff880055c4150 fffff800028730e0 : 000000000000d280 000000000000d280 fffffa800344e8c0 fffffa800344e750 : nt!KeSynchronizeExecution+0x3d59<br>> fffff880055c4290 fffff80002836d00 : fffff88003ad2438 0000000000000003 fffff9800c57cb80 fffff88003ad2438 : nt!KeSynchronizeExecution+0x29d0<br>> fffff880055c4420 fffff80002b8f708 : fffffa8003444220 fffff9800c3d4fd0 0000000000000200 fffff88000000000 : nt!CcScheduleReadAhead+0x1c0<br>> fffff880055c44c0 fffff88003ac2fdb : fffff98000000000 fffff980025b2dd0 0000000000000080 0000000000000001 : nt!CcCopyRead+0x278<br>> fffff880055c4580 fffff88003ac351e : fffff9800c588f80 fffff980025b2dd0 fffffa8002949f20 0000000000000080 : fat!fatReadOrMap+0x14b [d:\fat_16112010\fat_16112010\cachesup.c @ 1022]<br>> fffff880055c45f0 fffff88003ac3d46 : fffff9800c588f80 fffff980025b2dd0 fffffa8002949f20 fffff980094d6ef0 : fat!ProcessBlockDir+0x19e [d:\fat_16112010\fat_16112010\cachesup.c @ 1194]<br>> fffff880055c46c0 fffff88003b29944 : fffff9800c588f80 fffff980025b2dd0 fffffa8002949f20 fffff980094d6ef0 : fat!fatDir2GetDent+0x396 [d:\fat_16112010\fat_16112010\cachesup.c @ 1474]<br>> fffff880055c47f0 fffff88003b2888e : fffff9800c588f80 fffff9800c57cb80 fffffa8003120260 fffffa8003444220 : fat!fatQueryDirectory+0xff4 [d:\fat_16112010\fat_16112010\dirctrl.c @ 873]<br>> fffff880055c4bf0 fffff88003b28757 : fffff9800c588f80 fffff9800c57cb80 0000000000000010 fffff88003b28700 : fat!fatCommonDirectoryControl+0xee [d:\fat_16112010\fat_16112010\dirctrl.c @ 154]<br>> fffff880055c4c30 fffff80002d1ac16 : fffffa8003444060 fffff9800c57cb80 fffff8a002eacb40 00000000`00000000 : fat!fatFsdDirectoryControl+0x57 > > –>as u can check that it is KesyncronizationExecution APi which is increasing the level. > from my side i am calling CcCopyread at right IRQL level( Otherwise i guess CcCopyread would have crashed at Dispatch_level, as it is not recommended at dispatch_level) > > the problem comes when i try to make 100 directories using automated script then after making several folders same chunk of code crashes (same code routine already run many times)… > > i am puzzled what to do??? > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer >
In Win7 64 bit (only with verifier ) i am facing this issue. I think “Force IRQl Check” in verifier is paging out all paging memory. CcCopyread is used for reading here with pageable buffer.
“Extent” is taken from pageable memory . CcCopyread will guarntee read the data if wait flag is set(In my crash case it is set 1) so pagefault occurence seems pretty normal then why it is so upset about pageable memory (On win 7-32 bit, vista 64 bit no problem seems with verifier ON)
i think u r write , pagefault do occur because (0000000000000200 fffff88000000000 : nt!CcScheduleReadAhead+0x1c0) i cannot see any direct call from “CcScheduleReadAhead+0x1c0” address to “nt!KeSynchronizeExecution+0x29d0” routine…
Thank you to all. Although i couldnt find the root cause of Win 7 64 bit behaviour but i just solved the problem by taking Offset and length parameters on stack (rather then on paged memory).
Now with verifier it works fine.
> Thank you to all. Although i couldnt find the root cause of Win 7 64 bit behaviour but i just solved the problem by taking Offset and length parameters on stack (rather then on paged memory). > Now with verifier it works fine.
