Windows 7 BSOD 24 NTFS Windows 7

bsfinkel

New Member
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.
 
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.
 

Attachments

  • W7F_17-07-2019.zip
    4.4 MB · Views: 317
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
 
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.
 
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.
 
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?
 
Depends what context record your in. The file name is in the original context when you open the dump.
 
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.
 
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.
 
Back
Top