Windows 7 BSOD 24 NTFS Windows 7

[bsfinkel]

I am seeing multiple NTFS BSOD (24) occurrences on my Windows 7 Professional 32-bit system. I have many mini-dumps and full dumps. Is there anyone on this forum who has experience with these and can assist in determining what is happening? What documentation do you need? Thanks.

 

[Neemobeer]

Link Removed

 

[bsfinkel]

Here is more detail on my NTFS BSODs. I have a SATA disk as my C-drive, andI get lots of EventID 55 (NTFS) in the System Log. That EventId says that the C-drive is corrupt and needs a chkdsk. Windows schedules and runs a 12-minute "chkdsk c:" at reboot, and it always says "no problems found". After a BSOD the chkdsk finds index errors, which it corrects. Once, in 2013, I rebooted into XP ), and the chkdsk that ran said, "correcting errors in the upercase file". It did not tell me what errors were corrected, and I have no idea what the "uppercase file" is. The C-drive does not remain "clean" for long. Sometimes after a BSOD (Friday night or Saturday morning - more below), the system waits for me to logon. When I logon Saturday night I sometimes see that the C-drive has become dirty while the system was waiting for my login. When I start an incremental backup, I get an almost immediate EventID 55; when I start a full MSE scan on Friday night I also get an EventID 55. I did purchase and install SpinRite. I ran it at level 4 (16+ hours), and it reported no problems. Therefore I conclude that my SATA c-drive disk has no hardware problems.

Now on to the NTFS BSODs. I get these usually Friday night or Saturday morning during the full MSE scans. I have seen six so far his year and seven in 2018. I have full dumps and minidumps for each, and for each I have the output of windbg "!analyze -f -v". I obviously do not have the source code for ntfs.sys, and I do not know enough about the internals of Windows 7 to be able to do anything more with windbg and the dumps.

I hope that I have all of the desired information in the attached ZIP file.

Thanks.

 

[Neemobeer]

This could be a problem with the hard drive itself or just corruption.

I would run chkdsk on the disk, SFC /SCANNOW and possible run a drive fitness test.


*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 24, {1904fb, b2c0357c, b2c03160, 8348b133}

Probably caused by : ntkrpamp.exe ( nt!RtlAppendUnicodeStringToString+43 )

Followup: MachineOwner
---------

1: kd> .exr b2c0357c
ExceptionAddress: 8348b133 (nt!memmove+0x00000033)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 006e0069
Attempt to read from address 006e0069
1: kd> .exr 8348b133
ExceptionAddress: 00000003
ExceptionCode: 24ffa5f3
ExceptionFlags: 48b24c95
NumberParameters: 1912924547
Parameter[0]: 03e0830c
Parameter[1]: 24ffc803
Parameter[2]: 48b16085
Parameter[3]: 8d24ff83
Parameter[4]: 8348b25c
Parameter[5]: 8d24ff90
Parameter[6]: 8348b1e0
Parameter[7]: 48b17090
Parameter[8]: 48b19c83
Parameter[9]: 48b1c083
Parameter[10]: 8ad12383
Parameter[11]: 8a078806
Parameter[12]: 47880146
Parameter[13]: 02468a01
Parameter[14]: 8802e9c1

1: kd> .cxr b2c03160
eax=006e0096 ebx=b6b1f370 ecx=0000000b edx=00000001 esi=006e0069 edi=b6b1f370
eip=8348b133 esp=b2c03644 ebp=b2c0364c iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!memmove+0x33:
8348b133 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
1: kd> kb b2c03160
Requested number of stack frames (0xffffffffb2c03160) is too large! The maximum number is 0xffff.
^ Range error in 'kb b2c03160'
1: kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr Args to Child
00 b2c0364c 834f7906 b6b1f370 006e0069 0000002d nt!memmove+0x33
01 b2c0366c 8c89fdc2 89d20460 0000002d b2c03ab0 nt!RtlAppendUnicodeStringToString+0x43
02 b2c036a8 8c8a161c 893c1b58 8d783920 c10d6c20 Ntfs!NtfsConstructFilePath+0x1e0
03 b2c036f0 8c911d5c b2c03ab0 00000100 c10d6c20 Ntfs!NtfsAttachRepairInfoPriv+0x170
04 b2c03764 8c927578 b2c03ab0 8ade20d0 c10d6c20 Ntfs!NtfsReadMftRecord+0x1d7
05 b2c03790 8c91a50d b2c03ab0 8ade20d0 c10d6c20 Ntfs!NtfsReadFileRecord+0x31
06 b2c037c0 8c8f1135 b2c03ab0 c10d6c18 c10d6c20 Ntfs!NtfsLookupInFileRecord+0x11f
07 b2c039cc 8c915386 b2c03ab0 c10d6c18 89d20278 Ntfs!NtfsQueryStreamsInfo+0xc2
08 b2c03a38 8c92388d b2c03ab0 893c1938 3e4bf01c Ntfs!NtfsCommonQueryInformation+0x5c4
09 b2c03a9c 8c9239a4 b2c03ab0 893c1938 00000001 Ntfs!NtfsFsdDispatchSwitch+0x17b
0a b2c03bd0 83488f47 8ade2018 893c1938 893c1938 Ntfs!NtfsFsdDispatchWait+0x1c
0b b2c03be8 8c618562 8a4cf528 893c1938 00000000 nt!IofCallDriver+0x63
0c b2c03c0c 8c618721 b2c03c2c 8a4cf528 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2b0
0d b2c03c44 83488f47 8a4cf528 893c1938 00000000 fltmgr!FltpDispatch+0xc5
0e b2c03c5c 836b3c37 9bcdb017 0000678c 16b3db40 nt!IofCallDriver+0x63
0f b2c03d18 8348fa6a 01629dd2 16b3db54 00b3db6c nt!NtQueryInformationFile+0x794
10 b2c03d18 77456c04 01629dd2 16b3db54 00b3db6c nt!KiSystemServicePostCall

 

[bsfinkel]

I did an "sfc /scannow", and I am not sure what are the error lines. What I see now (and what I have seen ssince my first run of this command years ago) is "Cannot repair member file [l:22{11}]"odfox32.dll of Microsoft-Windows-Microsoft-Data-Access-Components-(MDAC)-ODBC-Jet ...", and the same for odpdx.dll .

The minidump you analyzed is the one from 07/13/2019 02:11.

The output of "!analyze -f -v"on that minidump has this text:

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.

When I look at the STACK_TEXT I do NOT see NtfsExceptionFilter, so I do not know what a .cxr on the third parameter and then a kb shows. I do not know the internals of Windows 7, so I do not know what this output tells me. And in the new stack trace I do not see NtfsExceptionFilter.

As for the suggestion "I would run chkdsk on the disk, ..., and possible run a drive fitness test." - I have this response. I know that I cannot run a "chkdsk c:" on a running system, as it may report false errors. If I were to run that command (with the "repair" option) at the next reboot, I am CONVINCED that no problems would be reported; this has happened NUMEROUS times. That command might be fixing something and not telling me that it did (and what it fixed). I know that that command will turn off the DIRTY bit. And I am not sure what a "drive fitness test" is. As I wrote previously, I ran Gibson SpinRite at level 4, and it found no errors.

 

[Neemobeer]

fltmgr is the file system filter manager which calls and loads the NTFS file system driver which basically is a filter driver for ntfs file system structures.

Running db esp-1000 esp+1000 you can see what it's trying to read when it crashes

a5803e68 00 00 00 00 00 00 00 00-41 54 41 5c 55 73 65 72 ........ATA\User
a5803e78 73 5c 42 61 72 72 79 46-55 00 73 00 65 00 72 00 s\B....FU.s.e.r.
a5803e88 73 00 5c 00 42 00 61 00-72 00 72 00 79 00 46 00 s.\.B......F.
a5803e98 69 00 6e 00 6b 00 65 00-6c 00 5c 00 44 00 6f 00 i.n.k.e.l.\.D.o.
a5803ea8 63 00 75 00 6d 00 65 00-6e 00 74 00 73 00 5c 00 c.u.m.e.n.t.s.\.
a5803eb8 46 00 61 00 6d 00 69 00-6c 00 79 00 20 00 54 00 F.a.m.i.l.y. .T.
a5803ec8 72 00 65 00 65 00 20 00-4d 00 61 00 6b 00 65 00 r.e.e. .M.a.k.e.
a5803ed8 72 00 5c 00 42 00 61 00-00 00 00 00 00 00 00 00 r.\.B.a

Omitted first name from the dump.

It's possible since the issue is happening at memcopy that it's being inspected or corrupted by another filter driver such as security software.

 

[bsfinkel]

Is there any command I have to run before the "d esp-1000 esp+1000 " command? I ran that command in windbg on both the minidump and full dump from last weekend, and I do not get the text above. Your output begins at a5803e68 , mine starts at b2c01fe8. And I get different output in the mindump and full dump; which dump should I trust?

 

[Neemobeer]

Depends what context record your in. The file name is in the original context when you open the dump.

 

[bsfinkel]

In the windbg - mindump 071319-63109-01.dmp - I did

!analyze -f -v
d esp-1000 esp+1000

And the display begins at address b2c01f38.

In the windbg - full dump memory.190713.0211.dmp (which I renamed from memory.dmp) - I did

!analyze -f -v
d esp-1000 esp+1000

The display begins at the same address, but the display is different. The minidump has

b2c01fe8 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????

and the full dump has

b2c01fe8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ...............

So I am not sure which to trust. But this discussion is a sidebar, as I really want to know exactly what caused the BSOD. I do not know enough about the internals of Windows 7 to know for what to look in the minidump/full dump. And the MS documentation is incomplete, as I have posted before. "If xxx is on the stack, then ..." The doc does not say what to do if xxx is not on the stack.

 

[bsfinkel]

I had another similar BSOD Friday night while MSE was doing a full scan. Is there any more information that can be gathered from the mini-dump I submitted to help me determine what is happening? I believe that there is a bug in ntfs.sys, but I do not have enough knowledge of the internals of Windows 7, nor do I have the source code for that module to be able to prove anything.