Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


robeson

i havd a BlueScreen sometimes on VISTAx64(uploaded memory.dmp)

By robeson, in Windows Vista

Recommended Posts

robeson    0

robeson
Posted (edited)

THIS IS dmp DEBUG who can help me thanks a lot

Microsoft ® Windows Debugger Version 6.11.0001.404 AMD64

Copyright © Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\Mini061309-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*d:\temp*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) MP (2 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 6002.18005.amd64fre.lh_sp2rtm.090410-1830

Machine Name:

Kernel base = 0xfffff800`01e09000 PsLoadedModuleList = 0xfffff800`01fcddd0

Debug session time: Sat Jun 13 23:38:31.319 2009 (GMT+8)

System Uptime: 0 days 0:11:09.088

Loading Kernel Symbols

...............................................................

................................................................

...................................

Loading User Symbols

Loading unloaded module list

..........

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {28, 2, 0, fffff80001e40204}

Probably caused by : memory_corruption ( nt!MiFindNodeOrParent+0 )

Followup: MachineOwner

---------

0: kd> !analyze -v

*******************************************************************************

* *

* 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: 0000000000000028, memory referenced

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000000, 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: fffff80001e40204, address which referenced memory

Debugging Details:

------------------

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002030080

0000000000000028

CURRENT_IRQL: 2

FAULTING_IP:

nt!MiFindNodeOrParent+0

fffff800`01e40204 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: svchost.exe

TRAP_FRAME: fffffa601849d5c0 -- (.trap 0xfffffa601849d5c0)

NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.

rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000

rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000

rip=fffff80001e40204 rsp=fffffa601849d758 rbp=0000000000000002

r8=fffffa601849d7a0 r9=fffffa800acc2780 r10=0000058000000000

r11=000000000003b4a0 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei ng nz na po nc

nt!MiFindNodeOrParent:

fffff800`01e40204 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h ds:07ff:00000000`00000028=????????????????

Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80001e631ee to fffff80001e63450

STACK_TEXT:

fffffa60`1849d478 fffff800`01e631ee : 00000000`0000000a 00000000`00000028 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx

fffffa60`1849d480 fffff800`01e620cb : 00000000`00000000 fffffa80`09fd0570 00000000`00000000 fffffa80`0acc27c8 : nt!KiBugCheckDispatch+0x6e

fffffa60`1849d5c0 fffff800`01e40204 : fffff800`01e40267 00000000`000018c0 fffff800`01f9b160 00000000`00000200 : nt!KiPageFault+0x20b

fffffa60`1849d758 fffff800`01e40267 : 00000000`000018c0 fffff800`01f9b160 00000000`00000200 fffff800`01f3df07 : nt!MiFindNodeOrParent

fffffa60`1849d760 fffff800`01e3e5ff : 00000000`0412ec01 00000000`00137b23 fffffa80`08123000 fffff800`01e2d213 : nt!MiLocateAddressInTree+0x17

fffffa60`1849d790 fffff800`01eeb070 : fffff880`0a672ae0 fffffa80`0acc2780 fffffa80`08123610 fffff800`01f9b160 : nt!MiGetSharedProtos+0x4f

fffffa60`1849d7c0 fffff800`01f055fc : 00000000`0003b4a0 fffffa80`08123610 fffffa80`0aafa700 00000000`00000000 : nt!MiIdentifyPfn+0x820

fffffa60`1849d860 fffff800`021f6d65 : fffffa80`08123000 fffffa60`1849dca0 fffffa60`1849d928 00000000`00000000 : nt!MmQueryPfnList+0x13c

fffffa60`1849d8a0 fffff800`0213be7c : fffffa80`00000000 00000000`00000000 fffffa80`08123000 00000000`06824f01 : nt!PfpPfnPrioRequest+0x115

fffffa60`1849d8f0 fffff800`020d2d5b : 00000000`00000000 00000000`06824ff0 00000000`0412ec80 fffff800`021f6d01 : nt! ?? ::NNGAKEGL::`string'+0x4b22a

fffffa60`1849d960 fffff800`01e62ef3 : fffffa80`0aafa700 00000000`06824ff0 00000000`0a71fe00 00000000`00000000 : nt!NtQuerySystemInformation+0xe4b

fffffa60`1849dc20 00000000`76f4707a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13

00000000`0412ebd8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76f4707a

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!MiFindNodeOrParent+0

fffff800`01e40204 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!MiFindNodeOrParent+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 49e0237f

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: X64_0xA_nt!MiFindNodeOrParent+0

BUCKET_ID: X64_0xA_nt!MiFindNodeOrParent+0

Followup: MachineOwner

---------

Mini061309_01.zip

Edited by robeson

Share this post

Link to post
Share on other sites

robeson    0

robeson
Posted

YES, I have pass the Memory Diagnostics Tool and some other menmry test tool , all can passed, I alse have changed one memory ,but bluescreen again ,now i droped one memory and only have one 2G. LOOKS fine as yet

Share this post

Link to post
Share on other sites

CoffeeFiend    0

CoffeeFiend
Posted

I haven't bothered looking at the minidump (I really doubt there will be anything worthwhile in a 32KB zip file, especially when we can already see stack corruption). But right off the bat, you can notice "DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT" -- that's already a good clue. And IRQL_NOT_LESS_OR_EQUAL is often caused by faulty drivers too.

Have you upgraded anything lately? Updated drivers? What's your hardware? ...

You can setup your machine for a full memory dump, something that will contain valuable infos. Then compress it up upload that somewhere and give us the link, we'll have a look.

Share this post

Link to post
Share on other sites

robeson    0

robeson
Posted
I haven't bothered looking at the minidump (I really doubt there will be anything worthwhile in a 32KB zip file, especially when we can already see stack corruption). But right off the bat, you can notice "DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT" -- that's already a good clue. And IRQL_NOT_LESS_OR_EQUAL is often caused by faulty drivers too.

Have you upgraded anything lately? Updated drivers? What's your hardware? ...

You can setup your machine for a full memory dump, something that will contain valuable infos. Then compress it up upload that somewhere and give us the link, we'll have a look.

when i drop one of my memory, It doesn't blue until now, and the memory.dmp has deleted automatically, Now i'm testing 2G memory, when it blue again, i will upload the completed dmp soon.

Share this post

Link to post
Share on other sites

cluberti    5

cluberti
Posted

Honestly, the crash stack I'm seeing (again, this is cursory - I won't know more until I see a real full .dmp file) seems to indicate you have bad RAM. Sometimes, *sometimes* (I can't emphasize enough how infrequent this is in my experience) a prototype PFE via PFN lookup failure is due to a bad driver somewhere on the system - but the VAST majority of the time I see this type of error, you have a bad stick (or more) of RAM, or the mobo memory controller's started to go bad, or both. I'd consider that removing a stick of RAM giving you some stability may indicate you've got some bad memory there.

Share this post

Link to post
Share on other sites

RJARRRPCGP    5

RJARRRPCGP
Posted (edited)
THIS IS dmp DEBUG who can help me thanks a lot

Microsoft ® Windows Debugger Version 6.11.0001.404 AMD64

Copyright © Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\Mini061309-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*d:\temp*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) MP (2 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 6002.18005.amd64fre.lh_sp2rtm.090410-1830

Machine Name:

Kernel base = 0xfffff800`01e09000 PsLoadedModuleList = 0xfffff800`01fcddd0

Debug session time: Sat Jun 13 23:38:31.319 2009 (GMT+8)

System Uptime: 0 days 0:11:09.088

Loading Kernel Symbols

...............................................................

................................................................

...................................

Loading User Symbols

Loading unloaded module list

..........

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {28, 2, 0, fffff80001e40204}

Probably caused by : memory_corruption ( nt!MiFindNodeOrParent+0 )

Followup: MachineOwner

---------

0: kd> !analyze -v

*******************************************************************************

* *

* 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: 0000000000000028, memory referenced

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000000, 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: fffff80001e40204, address which referenced memory

Debugging Details:

------------------

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002030080

0000000000000028

CURRENT_IRQL: 2

FAULTING_IP:

nt!MiFindNodeOrParent+0

fffff800`01e40204 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: svchost.exe

TRAP_FRAME: fffffa601849d5c0 -- (.trap 0xfffffa601849d5c0)

NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.

rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000

rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000

rip=fffff80001e40204 rsp=fffffa601849d758 rbp=0000000000000002

r8=fffffa601849d7a0 r9=fffffa800acc2780 r10=0000058000000000

r11=000000000003b4a0 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei ng nz na po nc

nt!MiFindNodeOrParent:

fffff800`01e40204 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h ds:07ff:00000000`00000028=????????????????

Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80001e631ee to fffff80001e63450

STACK_TEXT:

fffffa60`1849d478 fffff800`01e631ee : 00000000`0000000a 00000000`00000028 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx

fffffa60`1849d480 fffff800`01e620cb : 00000000`00000000 fffffa80`09fd0570 00000000`00000000 fffffa80`0acc27c8 : nt!KiBugCheckDispatch+0x6e

fffffa60`1849d5c0 fffff800`01e40204 : fffff800`01e40267 00000000`000018c0 fffff800`01f9b160 00000000`00000200 : nt!KiPageFault+0x20b

fffffa60`1849d758 fffff800`01e40267 : 00000000`000018c0 fffff800`01f9b160 00000000`00000200 fffff800`01f3df07 : nt!MiFindNodeOrParent

fffffa60`1849d760 fffff800`01e3e5ff : 00000000`0412ec01 00000000`00137b23 fffffa80`08123000 fffff800`01e2d213 : nt!MiLocateAddressInTree+0x17

fffffa60`1849d790 fffff800`01eeb070 : fffff880`0a672ae0 fffffa80`0acc2780 fffffa80`08123610 fffff800`01f9b160 : nt!MiGetSharedProtos+0x4f

fffffa60`1849d7c0 fffff800`01f055fc : 00000000`0003b4a0 fffffa80`08123610 fffffa80`0aafa700 00000000`00000000 : nt!MiIdentifyPfn+0x820

fffffa60`1849d860 fffff800`021f6d65 : fffffa80`08123000 fffffa60`1849dca0 fffffa60`1849d928 00000000`00000000 : nt!MmQueryPfnList+0x13c

fffffa60`1849d8a0 fffff800`0213be7c : fffffa80`00000000 00000000`00000000 fffffa80`08123000 00000000`06824f01 : nt!PfpPfnPrioRequest+0x115

fffffa60`1849d8f0 fffff800`020d2d5b : 00000000`00000000 00000000`06824ff0 00000000`0412ec80 fffff800`021f6d01 : nt! ?? ::NNGAKEGL::`string'+0x4b22a

fffffa60`1849d960 fffff800`01e62ef3 : fffffa80`0aafa700 00000000`06824ff0 00000000`0a71fe00 00000000`00000000 : nt!NtQuerySystemInformation+0xe4b

fffffa60`1849dc20 00000000`76f4707a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13

00000000`0412ebd8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76f4707a

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!MiFindNodeOrParent+0

fffff800`01e40204 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!MiFindNodeOrParent+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 49e0237f

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: X64_0xA_nt!MiFindNodeOrParent+0

BUCKET_ID: X64_0xA_nt!MiFindNodeOrParent+0

Followup: MachineOwner

---------

"IRQL_NOT_LESS_OR_EQUAL" usually is your processor core generating errors.

It's a classic sign of your processor core being overclocked too much or not enough vcore.

You can get that error code when the Linpack test fails. (When the Intel Burn test fails when testing your CPU)

In fact, I gotten that a while ago, when running Linpack, because I was required to increase the Vcore and/or CPU GTL Ref to get 2.90 Ghz on my E2180 ;)

Edited by RJARRRPCGP

Share this post

Link to post
Share on other sites

robeson    0

robeson
Posted

MY COMPUTER BLUE AGAIN ,now i only have one 2G memory

but the reason was different, i think there is some relation between them

Microsoft ® Windows Debugger Version 6.11.0001.404 AMD64

Copyright © Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]

Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*d:\temp*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) MP (2 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 6002.18005.amd64fre.lh_sp2rtm.090410-1830

Machine Name:

Kernel base = 0xfffff800`01e1f000 PsLoadedModuleList = 0xfffff800`01fe3dd0

Debug session time: Thu Jun 18 12:10:24.763 2009 (GMT+8)

System Uptime: 0 days 1:35:39.821

Loading Kernel Symbols

...............................................................

................................................................

.....................................

Loading User Symbols

Loading unloaded module list

....

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a039d8998a551c, b3b7465eec072260, fffff8000218eeb0, 1}

Probably caused by : memory_corruption

Followup: memory_corruption

---------

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)

This bugcheck is generated when the kernel detects that critical kernel code or

data have been corrupted. There are generally three causes for a corruption:

1) A driver has inadvertently or deliberately modified critical kernel code

or data. See http://www.microsoft.com/whdc/driver/kerne...itPatching.mspx

2) A developer attempted to set a normal kernel breakpoint using a kernel

debugger that was not attached when the system was booted. Normal breakpoints,

"bp", can only be set if the debugger is attached at boot time. Hardware

breakpoints, "ba", can be set at any time.

3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.

Arguments:

Arg1: a3a039d8998a551c, Reserved

Arg2: b3b7465eec072260, Reserved

Arg3: fffff8000218eeb0, Failure type dependent information

Arg4: 0000000000000001, Type of corrupted region, can be

0 : A generic data region

1 : Modification of a function or .pdata

2 : A processor IDT

3 : A processor GDT

4 : Type 1 process list corruption

5 : Type 2 process list corruption

6 : Debug routine modification

7 : Critical MSR modification

Debugging Details:

------------------

BUGCHECK_STR: 0x109

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80001e79450

STACK_TEXT:

fffffa60`01bdc698 00000000`00000000 : 00000000`00000109 a3a039d8`998a551c b3b7465e`ec072260 fffff800`0218eeb0 : nt!KeBugCheckEx

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt

fffff80001ec5828 - nt!DbgPrint

[ 4c:c3 ]

fffff8000218ef15 - nt!PoQueueShutdownWorkItem+65

[ 0e:06 ]

2 errors : !nt (fffff80001ec5828-fffff8000218ef15)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

Followup: memory_corruption

---------

Share this post

Link to post
Share on other sites

nitroshift    31

nitroshift
Posted 

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

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See [url="http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx"]http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx[/url]
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d8998a551c, Reserved
Arg2: b3b7465eec072260, Reserved
Arg3: fffff8000218eeb0, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

followed by

MODULE_NAME: nt

FAULTING_MODULE: fffff80001e1f000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  49e0237f

BUGCHECK_STR:  0x109

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff80001e79450

which means either you have an outdated driver (try updating ALL drivers for your system) or your RAM is bad (try different RAM sticks or check them with memtest).

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Go To Topic Listing Windows Vista

  • Recently Browsing   0 members

    No registered users viewing this page.

×