Hi All,
Down below you will see documentation on a preliminary analysis of a memory
dump I received recently.
It looks the File Object is getting corrupted. I do not have the proper
debug symbols for this OS (Japanese NT4 Server w/SP5) but the one's I have
gotten so far seem to be close enough if I use a little guess work.
Here is what I see:
a.. nt!NtQueryDirectoryFile is called and setups local storage.
b.. nt!NtQueryDirectoryFile passes pointers to those storage locations in
addition to all the parameters that is received to the function
nt!BuildQueryDirectoryIrp.
c.. nt!BuildQueryDirectoryIrp returns.
d.. nt!NtQueryDirectoryFile passes the values in the local storage
location to nt!IopSynchronousServiceTail.
e.. nt!IopSynchronousServiceTail uses one of the values passed as a
pointer and throws the exception because the pointer is bad.
nt!NtQueryDirectoryFile got a bad pointer from nt!BuildQueryDirectoryIrp.
Why?
I looked at the parameters passed into nt!NtQueryDirectoryFile.
I see that the handle is not pointing to a valid object.
Obviously, I do not know if the object was valid when it got passed to
nt!NtQueryDirectoryFile. My guess is that it was not.
I analyzed the object and it looks like a file object with at least bad type
data. Maybe the header got corrupted?
Since we filter the file system, I have to assume we corrupted the file
object. However, we are not in the stack on this dump and our filtering is
minimal. It is mostly read only. I know NT4 SP5 has issues. Is it
possible that this is an OS issue? I looked at the problems NT4 SP6/Sp6a
fixed and did not see anything.
Anyone have any additional ideas or comments on what my next action should
be? (We already told the customer they should upgrade their OS.)
Best Regards,
Joe
---------------------------------------- Dump
Analysis ---------------------------------------------------------------
Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\work\dump0622\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available
Symbol search path is:
D:\nt4symbols\free\sp5\symbols;D:\nt4symbols\free\japanese\nt4srvr\SYMBOLS;D
:\work\testfix
Executable search path is:
*** WARNING: symbols timestamp is wrong 0x3746fa44 0x371cd6a1 for
ntkrnlmp.exe
Windows NT 4 Kernel Version 1381 (Service Pack 5) MP (2 procs) Free x86
compatible
Product: Server
Kernel base = 0x80100000 PsLoadedModuleList = 0x80154010
Debug session time: Fri Jun 18 16:16:38 2004
System Uptime: 0 days 0:13:54.501
*** WARNING: symbols timestamp is wrong 0x3746fa44 0x371cd6a1 for
ntkrnlmp.exe
Loading Kernel Symbols
.............................................
Loading unloaded module list
No unloaded module list present
Loading User Symbols
............
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***
Use !analyze -v to get detailed debugging information.
BugCheck 1E, {c0000005, 80172b6d, 0, 53}
*** WARNING: Unable to verify checksum for ntdll.dll
*** WARNING: Unable to verify checksum for KERNEL32.dll
*** WARNING: symbols timestamp is wrong 0x374ddd87 0x36fae498 for CMD.exe
Probably caused by : ntkrnlmp.exe ( nt!IopSynchronousServiceTail+15 )
Followup: MachineOwner
0: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 80172b6d, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 00000053, Parameter 1 of the exception
Debugging Details:
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
referenced memory at "0x%08lx". The memory could not be "%s".
FAULTING_IP:
nt!IopSynchronousServiceTail+15
80172b6d 8b7e50 mov edi,[esi+0x50]
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 00000053
READ_ADDRESS: 00000053
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x1E
LAST_CONTROL_TRANSFER: from 8016e4a2 to 80172b6d
TRAP_FRAME: f12f1e14 -- (.trap fffffffff12f1e14)
ErrCode = 00000000
eax=00000000 ebx=8016e444 ecx=0000003d edx=00000001 esi=00000003
edi=f12f1f04
eip=80172b6d esp=f12f1e88 ebp=f12f1e9c iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
nt!IopSynchronousServiceTail+0x15:
80172b6d 8b7e50 mov edi,[esi+0x50]
ds:0023:00000053=????????
Resetting default scope
STACK_TEXT:
f12f1e9c 8016e4a2 00000001 00000003 80a451a8
nt!IopSynchronousServiceTail+0x15
f12f1ed0 80140db9 00000068 00000000 00000000 nt!NtQueryDirectoryFile+0x5a
f12f1ed0 77f57cb7 00000068 00000000 00000000 nt!KiSystemService+0xd9
00120f08 77edcda3 00000068 00000000 00000000 ntdll!NtQueryDirectoryFile+0xb
00121204 77edc668 00129750 00000000 0012127c
KERNEL32!FindFirstChangeNotificationA+0x9
0012123c 01376caa 01376ad6 00129750 00000027 KERNEL32!FindNextFileW+0xa4
00121258 01373905 00129750 00000027 0012127c CMD!Start+0x264
FOLLOWUP_IP:
nt!IopSynchronousServiceTail+15
80172b6d 8b7e50 mov edi,[esi+0x50]
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!IopSynchronousServiceTail+15
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 3746fa44
STACK_COMMAND: .trap fffffffff12f1e14 ; kb
BUCKET_ID: 0x1E_nt!IopSynchronousServiceTail+15
Followup: MachineOwner
====================================================
This what is on the stack at the time of the crash.
Stack:
ebp retaddr ebp-8h
0010:f12f1e98 00000003 f12f1ed0 8016e4a2 00000001
ebp-0ch ebp-10h const ebp-1
0010:f12f1ea8 00000003 80a451a8 00000001 2f1f0401
ebp-2 const lv10h lv0ch
0010:f12f1eb8 1f040100 00000002 80a451a8 00000003
lv08h lv04h ebp retaddr
0010:f12f1ec8 00000001 01004021 f12f1f04 80140db9
handle event ApcRtn ApcCtx
0010:f12f1ed8 00000068 00000000 00000000 00000000
IoStBk FilInfo length FIClass
0010:f12f1ee8 001211d4 00120f48 00000268 00000003
RtnSE FN RstScan
0010:f12f1ef8 00000001 001211f4 00000000 f13d9f6c
0010:f12f1f08 f12a34fc 80ab30f0 80ab3040 80f8eb20
0010:f12f1f18 80ab3020 00c1d768 00000000 00000000
0010:f12f1f28 00000000 0000c004 00000000 00000000
0010:f12f1f38 00000023 00000023 00000000 00d20000
0010:f12f1f48 00001000 00000b01 ffffffff 00000038
0010:f12f1f58 00000000 0013cde8 001211d4 00121204
0010:f12f1f68 00000000 77f57cb7 0000001b 00000246
0010:f12f1f78 00120f0c 00000023 8014564e f12ce940
0010:f12f1f88 e1e84788 00000000 0000027f 00000000
0010:f12f1f98 0000ffff 00000000 00000000 00000000
0010:f12f1fa8 00000000 00000040 00000000 00000000
0010:f12f1fb8 00e8d338 77da9ca2 00000108 00e8d32c
0010:f12f1fc8 00000000 02000000 00e8d7fc 00e8eca4
0010:f12f1fd8 00e8d7fc 00000000 001c001a 000a1f86
0010:f12f1fe8 ffffffff 00e8d358 70981aeb 00000108
0010:f12f1ff8 000a1f86 00000000 ???????? ????????
nt!NtQueryDirectoryFile:
8016e444 55 push ebp
8016e445 8bec mov ebp,esp
8016e447 83ec10 sub esp,0x10
8016e44a 8d45ff lea eax,[ebp-0x1]
8016e44d 8d4df0 lea ecx,[ebp-0x10]
8016e450 50 push eax
; Pointer to lv0ch being passed to nt!BuildQueryDirectoryIrp
8016e451 8d55f4 lea edx,[ebp-0xc]
8016e454 51 push ecx
8016e455 8d45f8 lea eax,[ebp-0x8]
8016e458 52 push edx ;lv0ch
8016e459 8d4dfe lea ecx,[ebp-0x2]
8016e45c 50 push eax
8016e45d 51 push ecx
8016e45e 6a01 push 0x1
8016e460 ff7530 push dword ptr [ebp+0x30]
8016e463 ff752c push dword ptr [ebp+0x2c]
8016e466 ff7528 push dword ptr [ebp+0x28]
8016e469 ff7524 push dword ptr [ebp+0x24]
8016e46c ff7520 push dword ptr [ebp+0x20]
8016e46f ff751c push dword ptr [ebp+0x1c]
8016e472 ff7518 push dword ptr [ebp+0x18]
8016e475 ff7514 push dword ptr [ebp+0x14]
8016e478 ff7510 push dword ptr [ebp+0x10]
8016e47b ff750c push dword ptr [ebp+0xc]
8016e47e ff7508 push dword ptr [ebp+0x8]
call nt!BuildQueryDirectoryIrp
8016e481 e8dcfaffff call nt!NtUnlockFile+0x378 (8016df62)
8016e486 85c0 test eax,eax
8016e488 7c18 jl nt!NtQueryDirectoryFile+0x5a (8016e4a2)
8016e48a 6a02 push 0x2
8016e48c ff75fe push dword ptr [ebp-0x2]
8016e48f ff75ff push dword ptr [ebp-0x1]
8016e492 6a01 push 0x1
8016e494 ff75f0 push dword ptr [ebp-0x10]
; Pointer to lv0ch being passed to nt!IopSynchronousServiceTail
8016e497 ff75f4 push dword ptr [ebp-0xc] ;lv0ch
8016e49a ff75f8 push dword ptr [ebp-0x8]
call nt!IopSynchronousServiceTail
8016e49d e8b4460000 call nt!IopSynchronousApiServiceTail+0xba
(80172b56)
8016e4a2 8be5 mov esp,ebp
8016e4a4 5d pop ebp
8016e4a5 c22c00 ret 0x2c
nt!IopSynchronousServiceTail:
80172b56 55 push ebp
80172b57 b901000000 mov ecx,0x1
80172b5c 8bec mov ebp,esp
80172b5e 83ec08 sub esp,0x8
80172b61 53 push ebx
80172b62 56 push esi
80172b63 57 push edi
80172b64 ff1550681480 call dword ptr [nt!_imp_KfRaiseIrql (80146850)]
80172b6a 8b750c mov esi,[ebp+0xc] ;lv0ch
80172b6d 8b7e50 mov edi,[esi+0x50] ;BOOM!
Handle:
0068: Object: 80a451a8 GrantedAccess: 00100001
KD: 80a451a8: Not a valid object (ObjectType invalid)
80a451a8 is an invalid File Object
0: kd> dd 80a451a8
80a451a8 00700005 80e04b70 80e04ae8 e22a9dd0
80a451b8 e22a9f10 80a66dd0 00000000 00000000
80a451c8 00000000 00010000 01000100 00044042
80a451d8 00780044 e1f51688 00000000 00000000
80a451e8 ffffffff 00000001 00000000 00040001
80a451f8 00000001 80a451fc 80a451fc 00040000
80a45208 00000000 80a4520c 80a4520c 00000000
80a45218 00000000 80a45000 03010005 61436d4d
80e04b70 looks like a valid Device Object.
0: kd> !object 80e04b70
Object: 80e04b70 Type: (80f72f40) Device
ObjectHeader: 80e04b58
HandleCount: 0 PointerCount: 3
Directory Object: 80e70770 Name: Partition2
0: kd> dd 80e04b70
80e04b70 01b00003 000001aa 80e70930 80e04dd0
80e04b80 00000000 00000000 00000000 00000050
80e04b90 00000000 80e04ae8 80e04c28 00000007
80e04ba0 00000002 00000000 00000000 00000000
80e04bb0 00000000 00000000 00000000 00000000
80e04bc0 00000000 00000000 00000000 00000000
80e04bd0 00140014 80e04bd4 80e04bd4 00000000
80e04be0 00000000 00000000 00000000 00000000
And 80e04ae8 looks like a valid VPB. We can see
that the VPB RealDeviceObject points to the
Device Object.
VPB:
0: kd> dd 80e04ae8
80e04ae8 0058000a 00080001 80d9e020 80e04b70
80e04af8 102fdc9b 000001a7 004f0054 004c004f
80e04b08 00000000 00000000 00000000 00000000
80e04b18 00000000 00000000 00000000 00000000
80e04b28 00000000 00000000 00000000 00000000
80e04b38 00000000 00000000 10010003 e9766544
80e04b48 80e70770 00140014 e15e6288 00000000
80e04b58 00000003 00000000 80f72f40 12000010
VPB DeviceObject:
0: kd> !object 80d9e020
Object: 80d9e020 Type: (80f72f40) Device
ObjectHeader: 80d9e008
HandleCount: 0 PointerCount: 1
VPB RealDeviceObject:
0: kd> !object 80e04b70
Object: 80e04b70 Type: (80f72f40) Device
ObjectHeader: 80e04b58
HandleCount: 0 PointerCount: 3
Directory Object: 80e70770 Name: Partition2
The Device Object also point to a valid Driver Object
and a valid next Device Object.
Driver Object:
0: kd> !object 80e70930
Object: 80e70930 Type: (80f72e40) Driver
ObjectHeader: 80e70918
HandleCount: 0 PointerCount: 1
Directory Object: 80f73090 Name: Disk
Next Device Object:
0: kd> !object 80e04dd0
Object: 80e04dd0 Type: (80f72f40) Device
ObjectHeader: 80e04db8
HandleCount: 0 PointerCount: 4
Directory Object: 80e70770 Name: Partition1
If we look at the Driver Object we should see our
Device Object. It looks like the Device Object in
this Driver Object is a duplicate Device Object.
0: kd> dd 80e70930
80e70930 00a80004 80e042d0 00000000 00000000
80e70940 00000000 00000000 80e709d8 00180018
80e70950 e15d1e48 801c5af8 00000000 8001c300
80e70960 00000000 00000000 802382a6 80115b66
80e70970 802382a6 802382da 802382da 80115b66
80e70980 80115b66 80115b66 80115b66 80239a08
80e70990 80115b66 80115b66 80115b66 80115b66
80e709a0 8023959a 80239b6c 80239a08 80115b66
0: kd> !object 80e042d0
Object: 80e042d0 Type: (80f72f40) Device
ObjectHeader: 80e042b8
HandleCount: 0 PointerCount: 3
Directory Object: 80e70690 Name: Partition2