Here are the other two - one is similar one is different. Any help would be
greatly appreciated.
TR
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
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.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f7b9b93c, The address that the exception occurred at
Arg3: b63b8c30, Exception Record Address
Arg4: b63b892c, Context Record Address
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
referenced memory at "0x%08lx". The memory could not be "%s".
FAULTING_IP:
Ntfs!LfsFindLastLsn+2e1
f7b9b93c 83780801 cmp dword ptr [eax+8],1
EXCEPTION_RECORD: b63b8c30 -- (.exr 0xffffffffb63b8c30)
ExceptionAddress: f7b9b93c (Ntfs!LfsFindLastLsn+0x000002e1)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00181008
Attempt to read from address 00181008
CONTEXT: b63b892c -- (.cxr 0xffffffffb63b892c)
eax=00181000 ebx=00000000 ecx=87b811f0 edx=b63b8d54 esi=e5e0ada0
edi=b63b8d54
eip=f7b9b93c esp=b63b8cf8 ebp=b63b8d04 iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Ntfs!LfsFindLastLsn+0x2e1:
f7b9b93c 83780801 cmp dword ptr [eax+8],1
ds:0023:00181008=????????
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced
memory at "0x%08lx". The memory could not be "%s".
READ_ADDRESS: 00181008
BUGCHECK_STR: 0x7E
EXCEPTION_STR: 0x0
LAST_CONTROL_TRANSFER: from 8080fb63 to f7b9b93c
STACK_TEXT:
b63b8d04 8080fb63 e5e0ada0 00000001 808a3ff0 Ntfs!LfsFindLastLsn+0x2e1
b63b8d40 808127a2 882de238 808ae5c0 8a3911e0 nt!CcSetVacbLargeOffset+0x1a5
b63b8d80 8088043d 8a3911e0 00000000 882de238
nt!FsRtlFastCheckLockForRead+0x3a
b63b8dac 80949b7c 8a3911e0 00000000 00000000 nt!VerifierIrqlData+0x3d
b63b8ddc 8088e062 80880352 80000000 00000000 nt!CmpPrefetchHiveFile+0x4e
b63b8e84 00000000 00000000 00000000 00000000 nt!IoReadPartitionTable+0x1f2
FOLLOWUP_IP:
Ntfs!LfsFindLastLsn+2e1
f7b9b93c 83780801 cmp dword ptr [eax+8],1
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: Ntfs!LfsFindLastLsn+2e1
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Ntfs
IMAGE_NAME: Ntfs.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 45d6a04b
STACK_COMMAND: .cxr 0xffffffffb63b892c ; kb
FAILURE_BUCKET_ID: 0x7E_Ntfs!LfsFindLastLsn+2e1
BUCKET_ID: 0x7E_Ntfs!LfsFindLastLsn+2e1
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***
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: 00000005, memory referenced
Arg2: d0000002, IRQL
Arg3: 00000000, 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: 8080f5db, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 00000005
CURRENT_IRQL: d0000002
FAULTING_IP:
nt!CcGetVacbLargeOffset+1d
8080f5db ?? ???
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 8080f5db to 8088c963
STACK_TEXT:
f78d2c1c 8080f5db badb0d00 00000000 8a1bb7a0 nt!FsRtlNotifyCleanup+0x47
f78d2cfc 8080fc56 899cee2c 00000000 00000001 nt!CcGetVacbLargeOffset+0x1d
f78d2d40 808127a2 8a394b40 808ae5c0 8a3911e0 nt!CcReferenceFileOffset+0x5c
f78d2d80 8088043d 8a3911e0 00000000 8a394b40
nt!FsRtlFastCheckLockForRead+0x3a
f78d2dac 80949b7c 8a3911e0 00000000 00000000 nt!VerifierIrqlData+0x3d
f78d2ddc 8088e062 80880352 00000000 00000000 nt!CmpPrefetchHiveFile+0x4e
f78d2e84 00000000 00000000 00000000 00000000 nt!IoReadPartitionTable+0x1f2
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!CcGetVacbLargeOffset+1d
8080f5db ?? ???
SYMBOL_STACK_INDEX: 1
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 45ec0a19
SYMBOL_NAME: nt!CcGetVacbLargeOffset+1d
FAILURE_BUCKET_ID: 0xA_nt!CcGetVacbLargeOffset+1d
BUCKET_ID: 0xA_nt!CcGetVacbLargeOffset+1d
Followup: MachineOwner
---------
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Travis Rabe
Sent: Thursday, October 11, 2007 8:18 AM
To: [email protected]
Subject: RE: [IMail Forum] OT: Easy way to read a .dmp file
All,
Starting a few weeks ago on my mail server I get various mini dumps here
and there. Is there a good way to read .dmp files? I found a KB article at
MS, but it took way too long to do and it didn't; really yield anything
useful.
Any ideas?
[Travis Rabe]
OK here is what I have form one of the dump files - any ideas as to what is
causing this?
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***
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: cc2c2b1c, memory referenced
Arg2: d0000002, IRQL
Arg3: 00000000, 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: 8080f5b6, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: cc2c2b1c
CURRENT_IRQL: d0000002
FAULTING_IP:
nt!CcGetBcbListHeadLargeOffset+13c
8080f5b6 ?? ???
CUSTOMER_CRASH_COUNT: 3
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 8080f5b6 to 8088c963
STACK_TEXT:
f78dac1c 8080f5b6 badb0d00 00000000 87b58bf8 nt!FsRtlNotifyCleanup+0x47
f78dacfc 8080fc56 8864a224 00000000 00000001
nt!CcGetBcbListHeadLargeOffset+0x13c
f78dad40 808127a2 8a394660 808ae5c0 8a3880b0 nt!CcReferenceFileOffset+0x5c
f78dad80 8088043d 8a3880b0 00000000 8a394660
nt!FsRtlFastCheckLockForRead+0x3a
f78dadac 80949b7c 8a3880b0 00000000 00000000 nt!VerifierIrqlData+0x3d
f78daddc 8088e062 80880352 00000000 00000000 nt!CmpPrefetchHiveFile+0x4e
f78dae84 00000000 00000000 00000000 00000000 nt!IoReadPartitionTable+0x1f2
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!CcGetBcbListHeadLargeOffset+13c
8080f5b6 ?? ???
SYMBOL_STACK_INDEX: 1
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 45ec0a19
SYMBOL_NAME: nt!CcGetBcbListHeadLargeOffset+13c
FAILURE_BUCKET_ID: 0xA_nt!CcGetBcbListHeadLargeOffset+13c
BUCKET_ID: 0xA_nt!CcGetBcbListHeadLargeOffset+13c
Followup: MachineOwner
TR
