[QUESTION]How To Proceed Debugging a NTFS_FILE_SYSTEM (24) Bugcheck?

blueelvis

blueelvis

BSOD Kernel Dump Senior Analyst
Joined
Apr 14, 2014
Posts
970
Location
India
So, I am working on a case in which the user is getting random bugchecks related to File System. I asked him to run the Driver Verifier as well but it failed on catching any bad drivers. The user's system crashed only twice during a whole week only but it did not reveal any specific information as well. So, I requested him a complete memory Dump file which can be found over **HERE**.

Code: 
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: 000000b500190637
Arg2: [COLOR=#0000FF]ffffd0002040eae8[/COLOR]
Arg3: [COLOR=#FF0000]ffffd0002040e2f0[/COLOR]
Arg4: fffff801541540bb

Now, in this complete dump file, the bug check is the NTFS_FILE_SYSTEM (24). Below is a stack trace -
Code: 
2: kd> k
Child-SP          RetAddr           Call Site
ffffd000`2040d918 fffff801`5420b9a5 nt!KeBugCheckEx
ffffd000`2040d920 fffff801`54203ea1 Ntfs+0xa9a5
ffffd000`2040dae0 fffff800`22fbad56 Ntfs+0x2ea1
ffffd000`2040db20 fffff801`5420c462 nt!_C_specific_handler+0x86
ffffd000`2040db90 fffff800`22fd31ed Ntfs+0xb462
ffffd000`2040dbc0 fffff800`22f603a5 nt!RtlpExecuteHandlerForException+0xd
ffffd000`2040dbf0 fffff800`22f5f25f nt!RtlDispatchException+0x1a5
ffffd000`2040e2c0 fffff800`22fd78c2 nt!KiDispatchException+0x61f
ffffd000`2040e9b0 fffff800`22fd6014 nt!KiExceptionDispatch+0xc2
ffffd000`2040eb90 fffff801`541540bb nt!KiPageFault+0x214
ffffd000`2040ed20 fffff801`54151302 fltmgr!FltpSetUpIrpCallControl+0x5b
ffffd000`2040ed70 fffff800`22eb1a8a fltmgr!FltpPreFsFilterOperation+0x352
ffffd000`2040ee40 fffff800`2328f978 nt!FsFilterPerformCallbacks+0x12a
ffffd000`2040ee90 fffff800`22f8603a nt!FsRtlAcquireFileForCcFlushEx+0xec
ffffd000`2040f140 fffff800`22ef0ac7 nt!MmFlushSection+0xce
ffffd000`2040f200 fffff800`22f7ea51 nt!CcFlushCachePriv+0x68f
ffffd000`2040f310 fffff801`542a7f04 nt!CcFlushCache+0x11
ffffd000`2040f350 fffff801`5432d1a2 Ntfs+0xa6f04
ffffd000`2040f3d0 fffff801`54229c10 Ntfs+0x12c1a2
ffffd000`2040f520 fffff801`5421effd Ntfs+0x28c10
ffffd000`2040f5c0 fffff801`5421f36c Ntfs+0x1dffd
ffffd000`2040f760 fffff801`5414ecf8 Ntfs+0x1e36c
ffffd000`2040f810 fffff801`5414d0b6 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x258
ffffd000`2040f8b0 fffff800`23252c9a fltmgr!FltpDispatch+0xb6
ffffd000`2040f910 fffff800`22fd74b3 nt!NtReadFile+0x7ca
ffffd000`2040fa90 00007fff`c69d16da nt!KiSystemServiceCopyEnd+0x13
00000078`7cc9d628 00000000`00000000 0x00007fff`c69d16da

Now, we know that the Second & Third Parameter would be Exception Record & Context Record if NTFSExceptionFilter is present on the stack but as we can see, it is not there and still WINDbg has utilized the second and thirds parameter and provided me with the below output -
Code: 
EXCEPTION_RECORD:  ffffd0002040eae8 -- (.exr 0x[COLOR=#0000FF]ffffd0002040eae8[/COLOR])
ExceptionAddress: fffff801541540bb (fltmgr!FltpSetUpIrpCallControl+0x000000000000005b)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000040000028
Attempt to read from address 0000000040000028
CONTEXT:  ffffd0002040e2f0 -- (.cxr 0x[COLOR=#FF0000]ffffd0002040e2f0[/COLOR];r)
rax=ffffe0000f4887f0 rbx=ffffe000114efdb8 rcx=0000000000000000
rdx=ffffe000098a2770 rsi=ffffe000098a2770 rdi=0000000040000000
rip=fffff801541540bb rsp=ffffd0002040ed20 rbp=ffffd0002040ed00
 r8=ffffd0002040edd8  r9=00000000000000fb r10=ffffe0000fd1c270
r11=7ffffffffffffffc r12=00000000000000fb r13=ffffe00010187a80
r14=ffffd0002040edd8 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
fltmgr!FltpSetUpIrpCallControl+0x5b:
fffff801`541540bb 488b4f28        mov     rcx,qword ptr [rdi+28h] ds:002b:00000000`40000028=????????????????
Last set context:
rax=ffffe0000f4887f0 rbx=ffffe000114efdb8 rcx=0000000000000000
rdx=ffffe000098a2770 rsi=ffffe000098a2770 rdi=0000000040000000
rip=fffff801541540bb rsp=ffffd0002040ed20 rbp=ffffd0002040ed00
 r8=ffffd0002040edd8  r9=00000000000000fb r10=ffffe0000fd1c270
r11=7ffffffffffffffc r12=00000000000000fb r13=ffffe00010187a80
r14=ffffd0002040edd8 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
fltmgr!FltpSetUpIrpCallControl+0x5b:
fffff801`541540bb 488b4f28        mov     rcx,qword ptr [rdi+28h] ds:002b:00000000`40000028=????????????????
So, WinDBG is doing something wrong here? Since, the NTFSExceptionFilter is not available on the stack?

Now, I read the below thread as well -
https://www.sysnative.com/forums/bs...tion]-debugging-an-ntfs_file_system-dump.html

I am at the same condition Patrick was at in the post :p

I hope someone is able to help me out on this one ^_^
 
Hi Pranav,

Code: 
BugCheck 24, {b500190637, [COLOR=#0000cd]ffffd0002040eae8[/COLOR], [COLOR=#008000]ffffd0002040e2f0[/COLOR], fffff801541540bb}

2nd argument is exception record address, 3rd argument is the context record address.

Code: 
2: kd> .exr ffffd0002040eae8
ExceptionAddress: fffff801541540bb ([COLOR=#800080]fltmgr!FltpSetUpIrpCallControl+0x000000000000005b[/COLOR])
   ExceptionCode: [COLOR=#ff0000]c0000005 (Access violation)[/COLOR]
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000040000028
Attempt to read from address 0000000040000028

We can see first of all the crash occurred because we hit an access violation regarding FltpSetUpIrpCallControl, likely an undocumented function of the Windows file system filter manager.

Code: 
2: kd> .cxr ffffd0002040e2f0
rax=ffffe0000f4887f0 rbx=ffffe000114efdb8 rcx=0000000000000000
rdx=ffffe000098a2770 rsi=ffffe000098a2770 [COLOR=#ff8c00]rdi=0000000040000000[/COLOR]
rip=fffff801541540bb rsp=ffffd0002040ed20 rbp=ffffd0002040ed00
 r8=ffffd0002040edd8  r9=00000000000000fb r10=ffffe0000fd1c270
r11=7ffffffffffffffc r12=00000000000000fb r13=ffffe00010187a80
r14=ffffd0002040edd8 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
[COLOR=#ff0000]fltmgr!FltpSetUpIrpCallControl+0x5b[/COLOR]:
fffff801`541540bb 488b4f28        [COLOR=#0000cd]mov[/COLOR]     [COLOR=#800080]rcx[/COLOR],qword ptr [[COLOR=#008000]rdi+28h[/COLOR]] ds:002b:00000000`40000028=????????????????

By running the .cxr command (display context record) followed by the 3rd argument address, we instruct the debugger to use the specified context record as the register context.

We can see that the immediate cause of the access violation within the instruction regarding FltpSetUpIrpCallControl was the attempt to move value stored at memory address contained in the rdi register + 28h to the rcx register.

The rcx register is null which is actually ok considering this is an x64 box, and rcx is a volatile register. This quite simply means that it's most likely going to be destroyed across a call, given its a scratch register. We're more interested in rdi's address contents:

Code: 
2: kd> !pte 0000000040000000
                                           VA 0000000040000000
PXE at FFFFF6FB7DBED000    PPE at FFFFF6FB7DA00008    PDE at FFFFF6FB40001000    PTE at FFFFF68000200000
contains 0180000129047867  contains 02C00001A18DB867  contains 0000000000000000
pfn 129047    ---DA--UWEV  pfn 1a18db    ---DA--UWEV  [COLOR=#ff0000]not valid[/COLOR]

So we can see that rdi was completely invalid (if 0000000040000000 wasn't obvious enough as invalid).

Code: 
2: kd> .formats 0000000040000000
Evaluate expression:
  Hex:     00000000`40000000
  Decimal: [COLOR=#ff0000]1073741824[/COLOR]
  Octal:   0000000000010000000000
  Binary:  00000000 00000000 00000000 00000000 01000000 00000000 00000000 00000000

Have the user test their hard disk with Chkdsk/Seatools, or update the firmware if it's an SSD.

Regards,

Patrick
 
HonorGamer said:
Wow. I never thought I could learn more in one post than I just did.
Click to expand...

That's the best of Patrick ;)

@Patrick -

Like I said Patrick, there is no presence of NtfsExceptionFilter in the Stack but still we can say that the second and third parameter are the Exception Record and the Context Record respectively. Could you please answer this as well?

Thanks as well for providing me with a clear cut explanation. I have asked the user to run the Hardware Diagnostics. Now, awaiting his reply.

By the way how are you? Long time no contact. Heard that you are planning to move to college soon?

-Pranav
 
Like I said Patrick, there is no presence of NtfsExceptionFilter in the Stack but still we can say that the second and third parameter are the Exception Record and the Context Record respectively.
Click to expand...

Correct, and yes. I am unsure as to why NtfsExceptionFilter isn't in some 0x24 call stacks, but I believe NtfsExceptionFilter is on an original stack when the output of .exr > .cxr > k will generate a more informative stack than the call stack that !analyze -v manages to display. In our case with this dump here, the original call stack that was already that of which we'd get if we ran .exr > .cxr > k.

By the way how are you? Long time no contact. Heard that you are planning to move to college soon?
Click to expand...

I am well, thank you for asking. I have been rather busy lately and don't have as much time as I did for forum stuff. I still make all the time I can for it, just a bit difficult lately.

Heard that you are planning to move to college soon?
Click to expand...

Whenever I manage to conquer student loans :r1:
 
Correct, and yes. I am unsure as to why NtfsExceptionFilter isn't in some 0x24 call stacks, but I believe NtfsExceptionFilter is on an original stack when the output of .exr > .cxr > k will generate a more informative stack than the call stack that !analyze -v manages to display. In our case with this dump here, the original call stack that was already that of which we'd get if we ran .exr > .cxr > k.
Click to expand...
Sure thing.
I am well, thank you for asking. I have been rather busy lately and don't have as much time as I did for forum stuff. I still make all the time I can for it, just a bit difficult lately.
Click to expand...
Well life can get busy. Let's see what you say when you have to submit assignments once you join college :P . You would understand the joy of last day submissions :D
I am hoping that you manage to conquer the student loans and join college soon ^_^.

I will update this thread once I get back a reply from the user. Let's hope he doesn't abandon the thread :grin1:
 
Nice work from Patrick I see.
I would have helped but I've been so busy recently, sorry about that.

I plan on going to University at the end of 2015 although staying in the accommodation seems, unlikely as my parents earn a lot and therefore I get very little in terms of maintenance loans.
The tution loans are part of the course which are £9,000 per year, so I can afford to join the course but not stay in the accommodation. However, if I can get a part time job soon and save up then I should be able to afford it.

As for the exception filter; AFAIK it's a method of handling the exception and continue execution without executing the exception handler code, the filter clears the exception, returns a value of -1 and continues execution where it left off.
If this is the case, then I'm wondering why it would actually crash in the first place if the exception was dealt with, that maybe why I hardly ever see the exception filter on the callstack.

If I'm wrong then feel free to correct me but AFAIK that's how it is dealt with.
 
Don't worry Jared. It is alright ^_^.

Seems like I would be graduating first then most likely Patrick and then Jared provided Harry is not in the race of completing graduation xD

It is a fun experience in the University. That's a lot of money per year. For my university it costs around 2000 GBP per year.

Your explanation seems interesting. On searching a bit using Google, I came across this following piece of code which is Copyright of Microsoft -

http://hf-2011.googlecode.com/svn/trunk/ntfs/seinfo.c

If you search for the NtfsExceptionFilter, you would see that it is taking the arguments as IrpContext and ExcepptionInfo. Below is the comment which explains this function -

Code: 
 //
            //  We had some trouble trying to perform the requested
            //  operation, so we'll abort the I/O request with
            //  the error status that we get back from the
            //  execption code
            //
 
Thanks Harry for looking into it. I will take a look at them once I am back from college today.

So basically, this routine is used to catch all the exceptions which couldn't be caught by a try-catch block? o.O
 
Did the system that the 0x24 dump come from have an SSD?

If so, was firmware up-to-date?

If no SSD, did SeaTools HDD diag pass?
 
jcgriff2 said:
Did the system that the 0x24 dump come from have an SSD?

If so, was firmware up-to-date?

If no SSD, did SeaTools HDD diag pass?
Click to expand...


The user hasn't replied till now :(

This is the worst part of the analysis. I do not like when people do not respond to the posts for which we spend the time in analysis :(
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top