Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info: https://www.osr.com/fesf

Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 5  
16 Mar 17 00:12
John
xxxxxx@gmail.com
Join Date: 10 May 2014
Posts To This List: 30
Isolation filter related crash

It doesn't happen all the time but I've been getting some system crashes when my isolation filter is loaded and the system resumes from hibernate. My filter isn't in the call stack so I'm not sure how to debug the problem. The only thing I can think of is that I may be missing a FileObject which then makes its way down the stack but the call stack doesn't show that. Here's an !analyze-v output from a Windows 8.1 system. 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: ffffe000c2286ee0, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, 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: fffff80373b3db5a, address which referenced memory Debugging Details: ------------------ DUMP_CLASS: 1 DUMP_QUALIFIER: 402 BUILD_VERSION_STRING: 9600.18505.amd64fre.winblue_ltsb.160930-0600 SYSTEM_MANUFACTURER: Gateway SYSTEM_PRODUCT_NAME: NE56R SYSTEM_SKU: NE56R_0649_V2.01 SYSTEM_VERSION: V2.01 BIOS_VENDOR: Gateway BIOS_VERSION: V2.01 BIOS_DATE: 08/06/2012 BASEBOARD_MANUFACTURER: Gateway BASEBOARD_PRODUCT: EG50_HC_HR BASEBOARD_VERSION: Type2 - Board Version DUMP_TYPE: 0 BUGCHECK_P1: ffffe000c2286ee0 BUGCHECK_P2: 2 BUGCHECK_P3: 1 BUGCHECK_P4: fffff80373b3db5a WRITE_ADDRESS: ffffe000c2286ee0 Nonpaged pool CURRENT_IRQL: 2 FAULTING_IP: nt!MiClearFilePointer+62 fffff803`73b3db5a 48832000 and qword ptr [rax],0 CPU_COUNT: 2 CPU_MHZ: 704 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 2a CPU_STEPPING: 7 CPU_MICROCODE: 6,2a,7,0 (F,M,S,R) SIG: 28'00000000 (cache) 28'00000000 (init) DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV PROCESS_NAME: System TRAP_FRAME: ffffd001e3d307e0 -- (.trap 0xffffd001e3d307e0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=ffffe000c2286ee0 rbx=0000000000000000 rcx=0000000080000000 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80373b3db5a rsp=ffffd001e3d30970 rbp=0000000000000000 r8=0000000000000000 r9=0000000000000001 r10=0000007ffffffff8 r11=0000098000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc nt!MiClearFilePointer+0x62: fffff803`73b3db5a 48832000 and qword ptr [rax],0 ds:ffffe000`c2286ee0=???????????????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80373bdbee9 to fffff80373bd03a0 STACK_TEXT: ffffd001`e3d30698 fffff803`73bdbee9 : 00000000`0000000a ffffe000`c2286ee0 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx ffffd001`e3d306a0 fffff803`73bda73a : 00000000`00000001 00000000`00000000 ffffe000`c2701800 fffff803`00000003 : nt!KiBugCheckDispatch+0x69 ffffd001`e3d307e0 fffff803`73b3db5a : 00000000`00000001 00000000`00000000 00000000`00000001 fffff803`73b1851c : nt!KiPageFault+0x23a ffffd001`e3d30970 fffff803`73b3b3d5 : ffffe000`c1ea9750 ffffe000`c1ea9750 00000000`00000002 ffffe000`c1ea97c8 : nt!MiClearFilePointer+0x62 ffffd001`e3d309a0 fffff803`73b3b321 : ffffe000`c1ea97c8 00000000`00000000 ffffe000`c1ea9750 00001f80`00000001 : nt!MiCheckForControlAreaDeletion+0x45 ffffd001`e3d309d0 fffff803`73b3af54 : fffffa80`0481c230 ffffd001`e3d30b10 ffffd001`e3600000 fffffa80`03f481e0 : nt!MiDereferenceControlAreaPfn+0x95 ffffd001`e3d30a10 fffff803`73b97783 : fffffa80`0481c230 fffffa80`0481c230 00000000`00000000 fffff803`73dd7288 : nt!MiRestoreTransitionPte+0x20c ffffd001`e3d30b50 fffff803`73b975a9 : fffffa80`04816a70 fffff803`73dd72d8 00000000`00000000 00000000`0018078d : nt!MiRemoveLowestPriorityStandbyPage+0x1b7 ffffd001`e3d30be0 fffff803`73b973f1 : fffff803`73b973e4 ffffe000`be9a4880 fffff803`73d55858 ffffe000`be9a4880 : nt!MiPurgeTransitionList+0x81 ffffd001`e3d30c20 fffff803`73ac0d6f : fffff803`73f02d78 ffffe000`be9a49c0 ffffe000`be9a4880 00000000`00000000 : nt!MiFinishResume+0xd ffffd001`e3d30c50 fffff803`73ab2f34 : fffff803`73dd6e02 ffffe000`be9a4880 00000000`00000080 ffffe000`be9a4880 : nt!ExpWorkerThread+0x69f ffffd001`e3d30d00 fffff803`73bd69c6 : ffffd001`e8241180 ffffe000`be9a4880 ffffe000`c27f3880 00000000`00000000 : nt!PspSystemThreadStartup+0x58 ffffd001`e3d30d60 00000000`00000000 : ffffd001`e3d31000 ffffd001`e3d2b000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16
  Message 2 of 5  
16 Mar 17 08:15
Gabriel Bercea
xxxxxx@gmail.com
Join Date: 03 Mar 2008
Posts To This List: 293
Isolation filter related crash

Is there anything you can decipher from the FO that is being torn down ? Is it the same one everytime ? If yes then maybe you can investigate. Check also your defrag paths in the filter. FSCTL_MOVE_FILE for example uses a handle in the MOVE_FILE_DATA and that could potentially pass down and ruin everything. Cheers, Gabriel. www.kasardia.com On Thu, Mar 16, 2017 at 5:12 AM, <xxxxx@gmail.com> wrote: > It doesn't happen all the time but I've been getting some system crashes > when my isolation filter is loaded and the system resumes from hibernate. > My filter isn't in the call stack so I'm not sure how to debug the > problem. The only thing I can think of is that I may be missing a > FileObject which then makes its way down the stack but the call stack > doesn't show that. Here's an !analyze-v output from a Windows 8.1 system. > > IRQL_NOT_LESS_OR_EQUAL (a) > An attempt was made to access a pageable (or completely invalid) address > at an <...excess quoted lines suppressed...> -- Bercea. G. --
  Message 3 of 5  
18 Mar 17 14:11
John
xxxxxx@gmail.com
Join Date: 10 May 2014
Posts To This List: 30
Isolation filter related crash

Thanks Gabe. I found the FO is one of mine and the MiClearFilePointer function is checking the SectionObjectPointers. When I try to examine the address the SOP points to, it's not found obviously hence the crash. Because this is one of my FO's, this means that my filter has already released the memory for the SOP structure or else this wouldn't crash. In my filter, the SOP release is only done during the STREAM_CONTEXT cleanup routine. I was under the impression that the context cleanup is called sometime after IRP_MJ_CLOSE is called. So if that's the case, I don't really understand how or why my FO got to this point. If it already made it through CLOSE then there shouldn't be any more references correct? With this being on the hibernation resume code path, are there any specific FSCTL's I may be missing that allows one of my FO's to sneak through? I would assume though that I would get the NtfsDecode BSOD instead of this error.
  Message 4 of 5  
19 Mar 17 11:00
rod widdowson
xxxxxx@steadingsoftware.com
Join Date: 11 Sep 2006
Posts To This List: 825
Isolation filter related crash

If you haven't I'd fire up verifier because this sort of situation is made for "!verifier 80. > Because this is one of my FO's, this means that my filter has already > released the memory for the SOP structure or else this wouldn't crash. As a sanity check can you navigate from your fscontext to your SOPs without issue? > In my filter, the SOP release is only done during the STREAM_CONTEXT > cleanup routine. Which one? upper or lower? What are you pinning the lower file objects with. I could see a situation in which a dismount might cause FLTMGR to do a forced teardown on the STREAM_CONTEXT - your file object will be about but the stream context won't be.
  Message 5 of 5  
21 Mar 17 14:15
John
xxxxxx@gmail.com
Join Date: 10 May 2014
Posts To This List: 30
Isolation filter related crash

<Quote>If you haven't I'd fire up verifier because this sort of situation is made for "!verifier 80.</Quote> The offending address is not found with !verifier 80 <Quote>As a sanity check can you navigate from your fscontext to your SOPs without issue?</Quote> The FsContext is pointing to invalid memory. That too is not found with !verifier 80. The FsContext2 does point to valid memory but it looks like it's was already reallocated by something else. <Quote>Which one? upper or lower?</Quote> Upper <Quote>What are you pinning the lower file objects</Quote> Another file on the same volume I haven't been able to recreate this crash and again it doesn't make a lot of sense to me about how it's happening. I was thinking that I might have an issue with reference counting but I would assume verifier would pick that up. Related to that, and your point about the forced teardown made me think of it, should an isolation filter be allowed to unload? Because if an app opens a file and a SFO is created but then the driver is unloaded and FLTMGR forces an unload, as soon as that app does any operation on that outstanding FO, it'll BSOD with the NtfsDecode error. Or will the driver not unload until all FOs are closed (which can take a long time).
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 16:16.


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