Crash dump

A

Andy

This is a windbg loading of my crash dump that gave me the blue screen.

It's greek to me.

Andy

Code:
Loading Dump File [D:\Documents and Settings\\Local Settings\Temp\WER1a19.dir00\Mini021313-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*DownstreamStore*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Wed Feb 13 18:08:02.453 2013 (UTC - 6:00)
System Uptime: 0 days 3:09:51.130
Loading Kernel Symbols
................................................................
.................................................................
...
Loading User Symbols
Loading unloaded module list
................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007F, {8, ba338d70, 0, 0}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: ba338d70
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


BUGCHECK_STR:  0x7f_8

CUSTOMER_CRASH_COUNT:  3

DEFAULT_BUCKET_ID:  DRIVER_FAULT

UNALIGNED_STACK_POINTER:  5a58de13

LAST_CONTROL_TRANSFER:  from 00000000 to 603c21ce

STACK_TEXT:
0ed9b214 00000000 00000000 00000000 00000000 0x603c21ce


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

BUCKET_ID:  INVALID_KERNEL_CONTEXT

Followup: MachineOwner
 
P

Paul

Andy said:
This is a windbg loading of my crash dump that gave me the blue screen.

It's greek to me.

Andy

Code:
Loading Dump File [D:\Documents and Settings\\Local Settings\Temp\WER1a19.dir00\Mini021313-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*DownstreamStore*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Wed Feb 13 18:08:02.453 2013 (UTC - 6:00)
System Uptime: 0 days 3:09:51.130
Loading Kernel Symbols
...............................................................
................................................................
..
Loading User Symbols
Loading unloaded module list
...............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007F, {8, ba338d70, 0, 0}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: ba338d70
Arg3: 00000000
Arg4: 00000000[/QUOTE]

The information shown, shows exactly what happened.

There was a double fault. An attempt to access a particular location
failed. That's the first fault. If the computer was still "sane" at that
point, a trap handler would have printed an intelligible error
number in place of "UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)".

If the trap handler is also insane, and the first access to memory
there also was inaccessible (like the mapping in the TLB was nuts),
then there would be a second attempt to trap. And at that point,
you've really lost all context, since the trap handler can't
do stuff like record the stack or whatever.

The reason a double fault has to be treated differently, is
so the CPU doesn't stay in a permanent loop of faults,
jumping all over the address space and doing God knows what.
There's less damage to information on the computer, if it
simply stops at this point.

On the processors I used to work with, a double fault meant a
"freeze" and you'd have to press reset. So the fact it was
able to log this much info, is quite impressive.

Something like this might be caused by a memory problem or
memory corruption (like, the kernel or a driver overwrote
something it shouldn't have, or a hardware DMA overwrite
some part of memory). While you could blame it on a driver,
as the driver is in Ring0, we don't have anything I can see
in the above log, to implicate a particular driver. All we
could go on is inference, like that driver you installed
ten minutes ago when the system was stable :-) Consider what
you just changed on the system, in an attempt to resolve it.

You can boot a Linux LiveCD, if you want to verify the
hardware still works. Ubuntu will do in a pinch, but other
distros may be more useful to you (easier to understand interface).

Paul
 
A

Andy

Andy said:
This is a windbg loading of my crash dump that gave me the blue screen.
It's greek to me.
Code:
[/QUOTE]

Loading Dump File [D:\Documents and Settings\\Local Settings\Temp\WER1a19.dir00\Mini021313-03.dmp][/QUOTE]
[QUOTE]
Mini Kernel Dump File: Only registers and stack trace are available 

Symbol search path is: srv*DownstreamStore*http://msdl.microsoft.com/download/symbols[/QUOTE]
[QUOTE]
Executable search path is:[/QUOTE]
[QUOTE]
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible[/QUOTE]
[QUOTE]
Product: WinNt[/QUOTE]
[QUOTE]
Built by: 2600.xpsp.080413-2111[/QUOTE]
[QUOTE]
Machine Name:[/QUOTE]
[QUOTE]
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720[/QUOTE]
[QUOTE]
Debug session time: Wed Feb 13 18:08:02.453 2013 (UTC - 6:00)[/QUOTE]
[QUOTE]
System Uptime: 0 days 3:09:51.130[/QUOTE]
[QUOTE]
Loading Kernel Symbols 



Loading User Symbols[/QUOTE]
[QUOTE]
Loading unloaded module list 


*                                                                             *[/QUOTE]
[QUOTE]
*                        Bugcheck Analysis                                    *[/QUOTE]
[QUOTE]
*                                                                             * 


Use !analyze -v to get detailed debugging information. 

BugCheck 1000007F, {8, ba338d70, 0, 0} 

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE ) 

Followup: MachineOwner 


0: kd> !analyze -v 

*                                                                             *[/QUOTE]
[QUOTE]
*                        Bugcheck Analysis                                    *[/QUOTE]
[QUOTE]
*                                                                             * 


UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)[/QUOTE]
[QUOTE]
This means a trap occurred in kernel mode, and it's a trap of a kind[/QUOTE]
[QUOTE]
that the kernel isn't allowed to have/catch (bound trap) or that[/QUOTE]
[QUOTE]
is always instant death (double fault).  The first number in the[/QUOTE]
[QUOTE]
bugcheck params is the number of the trap (8 = double fault, etc)[/QUOTE]
[QUOTE]
Consult an Intel x86 family manual to learn more about what these[/QUOTE]
[QUOTE]
traps are. Here is a *portion* of those codes:[/QUOTE]
[QUOTE]
If kv shows a taskGate[/QUOTE]
[QUOTE]
use .tss on the part before the colon, then kv.[/QUOTE]
[QUOTE]
Else if kv shows a trapframe[/QUOTE]
[QUOTE]
use .trap on that value 

.trap on the appropriate frame will show where the trap was taken[/QUOTE]
[QUOTE]
(on x86, this will be the ebp that goes with the procedure KiTrap) 

kb will then show the corrected stack. 

Arg1: 00000008, EXCEPTION_DOUBLE_FAULT[/QUOTE]
[QUOTE]
Arg2: ba338d70[/QUOTE]
[QUOTE]
Arg3: 00000000[/QUOTE]
[QUOTE]
Arg4: 00000000[/QUOTE]



The information shown, shows exactly what happened.



There was a double fault. An attempt to access a particular location

failed. That's the first fault. If the computer was still "sane" at that

point, a trap handler would have printed an intelligible error

number in place of "UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)".



If the trap handler is also insane, and the first access to memory

there also was inaccessible (like the mapping in the TLB was nuts),

then there would be a second attempt to trap. And at that point,

you've really lost all context, since the trap handler can't

do stuff like record the stack or whatever.



The reason a double fault has to be treated differently, is

so the CPU doesn't stay in a permanent loop of faults,

jumping all over the address space and doing God knows what.

There's less damage to information on the computer, if it

simply stops at this point.



On the processors I used to work with, a double fault meant a

"freeze" and you'd have to press reset. So the fact it was

able to log this much info, is quite impressive.



Something like this might be caused by a memory problem or

memory corruption (like, the kernel or a driver overwrote

something it shouldn't have, or a hardware DMA overwrite

some part of memory). While you could blame it on a driver,

as the driver is in Ring0, we don't have anything I can see

in the above log, to implicate a particular driver. All we

could go on is inference, like that driver you installed

ten minutes ago when the system was stable :-) Consider what

you just changed on the system, in an attempt to resolve it.



You can boot a Linux LiveCD, if you want to verify the

hardware still works. Ubuntu will do in a pinch, but other

distros may be more useful to you (easier to understand interface).



Paul[/QUOTE]

I ran memtesta86 and it said my ram was fine.

I recently installed kerio personal firewall and tried out a ram disk program.

I have removed both and am waiting to see if any more blue screens occur.

I also had problems with nero and another CD writer program.

They would write to a CD, but then I found nothing on the cd.

I used the windows erase cd function and then reran the cd writer.

I have puppy linux on a pen drive.

I will try it and see if all the hardware works under it.

If the hardware works under Linux, I will suspect maybe a driver conflict.

Andy
 
Y

Yousuf Khan

This is a windbg loading of my crash dump that gave me the blue screen.

It's greek to me.

Andy

I learned how to step through the WinDbg program a long time ago, and
then I discovered this program instead, BlueScreenView:

Blue screen of death (STOP error) information in dump files.
http://www.nirsoft.net/utils/blue_screen_view.html

It automates most of the steps of debugging and lists the final
information for you. I found it's just as accurate as WinDbg, just a lot
easier to use.

Yousuf Khan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top