PC instabiel , 5850 das Problem ?

so hier ich hoffe das is so richtig :

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\030611-22838-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16695.amd64fre.win7_gdr.101026-1503
Machine Name:
Kernel base = 0xfffff800`0284f000 PsLoadedModuleList = 0xfffff800`02a8ce50
Debug session time: Sun Mar 6 17:26:00.514 2011 (UTC + 2:00)
System Uptime: 0 days 3:06:16.538
Loading Kernel Symbols
...............................................................
................................................................
..................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 18, {fffffa8006a55200, fffffa80081209a0, 1, fffffffeffffffff}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+463ba )

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

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

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8006a55200, Object type of the object whose reference count is being lowered
Arg2: fffffa80081209a0, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: fffffffeffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.

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


CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x18

PROCESS_NAME: MOM.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002856f85 to fffff800028bf740

STACK_TEXT:
fffff880`078c7ad8 fffff800`02856f85 : 00000000`00000018 fffffa80`06a55200 fffffa80`081209a0 00000000`00000001 : nt!KeBugCheckEx
fffff880`078c7ae0 fffff800`02bd3354 : fffffa80`09150b30 00000000`00000000 fffffa80`097ff3f0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x463ba
fffff880`078c7b40 fffff800`02bd3254 : 00000000`0000080c fffffa80`09150b30 fffff8a0`0280c720 00000000`0000080c : nt!ObpCloseHandleTableEntry+0xc4
fffff880`078c7bd0 fffff800`028be993 : fffffa80`097ff3f0 fffff880`078c7ca0 00000000`1ae6ec70 fffffa80`097fc7f0 : nt!ObpCloseHandle+0x94
fffff880`078c7c20 00000000`7703f7aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`1ae6e838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7703f7aa


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+463ba
fffff800`02856f85 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+463ba

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4cc791bd

FAILURE_BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

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

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

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8006a55200, Object type of the object whose reference count is being lowered
Arg2: fffffa80081209a0, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: fffffffeffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.

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


CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x18

PROCESS_NAME: MOM.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002856f85 to fffff800028bf740

STACK_TEXT:
fffff880`078c7ad8 fffff800`02856f85 : 00000000`00000018 fffffa80`06a55200 fffffa80`081209a0 00000000`00000001 : nt!KeBugCheckEx
fffff880`078c7ae0 fffff800`02bd3354 : fffffa80`09150b30 00000000`00000000 fffffa80`097ff3f0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x463ba
fffff880`078c7b40 fffff800`02bd3254 : 00000000`0000080c fffffa80`09150b30 fffff8a0`0280c720 00000000`0000080c : nt!ObpCloseHandleTableEntry+0xc4
fffff880`078c7bd0 fffff800`028be993 : fffffa80`097ff3f0 fffff880`078c7ca0 00000000`1ae6ec70 fffffa80`097fc7f0 : nt!ObpCloseHandle+0x94
fffff880`078c7c20 00000000`7703f7aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`1ae6e838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7703f7aa


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+463ba
fffff800`02856f85 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+463ba

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4cc791bd

FAILURE_BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

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

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

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8006a55200, Object type of the object whose reference count is being lowered
Arg2: fffffa80081209a0, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: fffffffeffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.

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


CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x18

PROCESS_NAME: MOM.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002856f85 to fffff800028bf740

STACK_TEXT:
fffff880`078c7ad8 fffff800`02856f85 : 00000000`00000018 fffffa80`06a55200 fffffa80`081209a0 00000000`00000001 : nt!KeBugCheckEx
fffff880`078c7ae0 fffff800`02bd3354 : fffffa80`09150b30 00000000`00000000 fffffa80`097ff3f0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x463ba
fffff880`078c7b40 fffff800`02bd3254 : 00000000`0000080c fffffa80`09150b30 fffff8a0`0280c720 00000000`0000080c : nt!ObpCloseHandleTableEntry+0xc4
fffff880`078c7bd0 fffff800`028be993 : fffffa80`097ff3f0 fffff880`078c7ca0 00000000`1ae6ec70 fffffa80`097fc7f0 : nt!ObpCloseHandle+0x94
fffff880`078c7c20 00000000`7703f7aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`1ae6e838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7703f7aa


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+463ba
fffff800`02856f85 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+463ba

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4cc791bd

FAILURE_BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

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

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

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8006a55200, Object type of the object whose reference count is being lowered
Arg2: fffffa80081209a0, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: fffffffeffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.

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


CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x18

PROCESS_NAME: MOM.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002856f85 to fffff800028bf740

STACK_TEXT:
fffff880`078c7ad8 fffff800`02856f85 : 00000000`00000018 fffffa80`06a55200 fffffa80`081209a0 00000000`00000001 : nt!KeBugCheckEx
fffff880`078c7ae0 fffff800`02bd3354 : fffffa80`09150b30 00000000`00000000 fffffa80`097ff3f0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x463ba
fffff880`078c7b40 fffff800`02bd3254 : 00000000`0000080c fffffa80`09150b30 fffff8a0`0280c720 00000000`0000080c : nt!ObpCloseHandleTableEntry+0xc4
fffff880`078c7bd0 fffff800`028be993 : fffffa80`097ff3f0 fffff880`078c7ca0 00000000`1ae6ec70 fffffa80`097fc7f0 : nt!ObpCloseHandle+0x94
fffff880`078c7c20 00000000`7703f7aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`1ae6e838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7703f7aa


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+463ba
fffff800`02856f85 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+463ba

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4cc791bd

FAILURE_BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

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

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

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8006a55200, Object type of the object whose reference count is being lowered
Arg2: fffffa80081209a0, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: fffffffeffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.

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


CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x18

PROCESS_NAME: MOM.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002856f85 to fffff800028bf740

STACK_TEXT:
fffff880`078c7ad8 fffff800`02856f85 : 00000000`00000018 fffffa80`06a55200 fffffa80`081209a0 00000000`00000001 : nt!KeBugCheckEx
fffff880`078c7ae0 fffff800`02bd3354 : fffffa80`09150b30 00000000`00000000 fffffa80`097ff3f0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x463ba
fffff880`078c7b40 fffff800`02bd3254 : 00000000`0000080c fffffa80`09150b30 fffff8a0`0280c720 00000000`0000080c : nt!ObpCloseHandleTableEntry+0xc4
fffff880`078c7bd0 fffff800`028be993 : fffffa80`097ff3f0 fffff880`078c7ca0 00000000`1ae6ec70 fffffa80`097fc7f0 : nt!ObpCloseHandle+0x94
fffff880`078c7c20 00000000`7703f7aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`1ae6e838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7703f7aa


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+463ba
fffff800`02856f85 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+463ba

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4cc791bd

FAILURE_BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

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

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

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8006a55200, Object type of the object whose reference count is being lowered
Arg2: fffffa80081209a0, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: fffffffeffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.

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


CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x18

PROCESS_NAME: MOM.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002856f85 to fffff800028bf740

STACK_TEXT:
fffff880`078c7ad8 fffff800`02856f85 : 00000000`00000018 fffffa80`06a55200 fffffa80`081209a0 00000000`00000001 : nt!KeBugCheckEx
fffff880`078c7ae0 fffff800`02bd3354 : fffffa80`09150b30 00000000`00000000 fffffa80`097ff3f0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x463ba
fffff880`078c7b40 fffff800`02bd3254 : 00000000`0000080c fffffa80`09150b30 fffff8a0`0280c720 00000000`0000080c : nt!ObpCloseHandleTableEntry+0xc4
fffff880`078c7bd0 fffff800`028be993 : fffffa80`097ff3f0 fffff880`078c7ca0 00000000`1ae6ec70 fffffa80`097fc7f0 : nt!ObpCloseHandle+0x94
fffff880`078c7c20 00000000`7703f7aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`1ae6e838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7703f7aa


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+463ba
fffff800`02856f85 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+463ba

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4cc791bd

FAILURE_BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

BUCKET_ID: X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+463ba

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

3: kd> analyze -v
 
Google mal nach "MOM.exe".
Normalerweise ist sie ein Teil vom CCC, es gibt aber leider auch Trojaner, die sich als Mom.exe tarnen.

Also:

1. Zunächst über Systemsteuerung+Software den Catalys-Install-Manager deinstallieren und die Express-Deinstallation auswählen.
2. Alle ATI-Ordner/ProgramFiles löschen.
3. C:\Users\USERNAME\AppData\Local alle ATI-Ordner löschen (d.h. in den Papierkorb).
4. C:\Users\USERNAME\AppData\Roaming alle ATi-Ordner löschen.
5. Soweit dort vorhanden C:\ProgramData alle ATi-Ordner löschen.
(XP und Vista bzw. Windows 7 haben eine andere Ordnerstrutur. XP-SP3 hat keine AppData mehr, sondern Anwendungsdaten und lokale Einstellungen. Dann dort die ATi-Ordner löschen)

6. Mit "Regedit" in die Registry.
a. Hot_Key_Current User+Software alle AMD und ATI-Einträge löschen.
b. Hot_Key_Local_Machine+Software ebenfalls alle ATI-Einträge löschen.
c. Hot_Key_Users+Software ATi-Einträge löschen.
(danke an HeinzNeu für´s vorschreiben)


Wenn das alles gemacht ist, installierst du bitte nur den Treiber, also ohne CCC.
Fertig? Gut!

Tritt der Fehler wieder/immer noch auf?

Eine Lüftersteuerung, falls es dir jetzt zu laut ist, lässt sich hervorragend mit MSI Afterburner bewerkstelligen. :)
 
Okay das werde ich mal angehen :) danke dir hoffe damit ist es behoben aber eine frage habe ich noch was genau ist denn jetzt das Problem ? nur der Treiber oder was ? . Und warum nur den Treiber und nicht das CCC geht das überhaupt ohne ? .

MFG Haffke
 
Es scheint am CCC zu liegen und ja, du brauchst nur den Treiber. Das CCC ist eine Beigabe. :)
 
okay dann bedanke ich mich erst mal an dieser stelle wenn es wider Fehler geben sollte nachdem ich alles gemacht habe werde ich mich wider melden :)
Ergänzung ()

Hey hat leider nicht geklapt also hier der Bug report :



Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\041011-21886-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16695.amd64fre.win7_gdr.101026-1503
Machine Name:
Kernel base = 0xfffff800`02a49000 PsLoadedModuleList = 0xfffff800`02c86e50
Debug session time: Sun Apr 10 11:09:20.749 2011 (UTC + 2:00)
System Uptime: 0 days 0:13:30.419
Loading Kernel Symbols
...............................................................
................................................................
.................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {fffff87fe4ac0ac0, 8, fffff87fe4ac0ac0, 5}

Unable to load image \SystemRoot\system32\DRIVERS\atikmdag.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for atikmdag.sys
*** ERROR: Module load completed but symbols could not be loaded for atikmdag.sys

Could not read faulting driver name
Probably caused by : atikmdag.sys ( atikmdag+3fe63a )

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

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

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff87fe4ac0ac0, memory referenced.
Arg2: 0000000000000008, value 0 = read operation, 1 = write operation.
Arg3: fffff87fe4ac0ac0, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000005, (reserved)

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


Could not read faulting driver name

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80002cf10e0
fffff87fe4ac0ac0

FAULTING_IP:
+6566323266343464
fffff87f`e4ac0ac0 ?? ???

MM_INTERNAL_CODE: 5

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x50

PROCESS_NAME: Ruse.exe

CURRENT_IRQL: 0

TRAP_FRAME: fffff88008ed0100 -- (.trap 0xfffff88008ed0100)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000a4c8aa32 rbx=0000000000000000 rcx=fffffa8006f5d8c0
rdx=00000000000003fd rsi=0000000000000000 rdi=0000000000000000
rip=fffff87fe4ac0ac0 rsp=fffff88008ed0298 rbp=fffffa8007662340
r8=0000000003da0000 r9=00000000000017ee r10=00000000000017ee
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
fffff87f`e4ac0ac0 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002b388c1 to fffff80002ab9740

STACK_TEXT:
fffff880`08ecff98 fffff800`02b388c1 : 00000000`00000050 fffff87f`e4ac0ac0 00000000`00000008 fffff880`08ed0100 : nt!KeBugCheckEx
fffff880`08ecffa0 fffff800`02ab782e : 00000000`00000008 00000000`a4c8aa32 00000000`00000000 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x40e8b
fffff880`08ed0100 fffff87f`e4ac0ac0 : fffff880`04ac163a 00000000`a4c8aa32 00000000`00000000 00000000`c0000001 : nt!KiPageFault+0x16e
fffff880`08ed0298 fffff880`04ac163a : 00000000`a4c8aa32 00000000`00000000 00000000`c0000001 fffff880`03c4530f : 0xfffff87f`e4ac0ac0
fffff880`08ed02a0 00000000`a4c8aa32 : 00000000`00000000 00000000`c0000001 fffff880`03c4530f fffff8a0`00007403 : atikmdag+0x3fe63a
fffff880`08ed02a8 00000000`00000000 : 00000000`c0000001 fffff880`03c4530f fffff8a0`00007403 00012400`00012001 : 0xa4c8aa32


STACK_COMMAND: kb

FOLLOWUP_IP:
atikmdag+3fe63a
fffff880`04ac163a ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: atikmdag+3fe63a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: atikmdag

IMAGE_NAME: atikmdag.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d7702d1

FAILURE_BUCKET_ID: X64_0x50_atikmdag+3fe63a

BUCKET_ID: X64_0x50_atikmdag+3fe63a

Followup: MachineOwner
---------
 
Also es ist ja jetzt schon ne lange zeit ins Land gegangen . Der Fehler ist immer noch da und ein paar neue Sachen gibt es auch , ich fange einfach ma an .

1 . Seit neustem meldet Windows während dem spielen das der anzeige Treiber abgestützt ist und wieder hergestellt werden muss .

2. Ich habe einen 24´h Test mit Einstein @ home durchgeführt Test Durchlauf nicht ganz bestanden er ist einmal abgestürzt aber hat alle Pakete zu 100% richtig berechnet .

3. Ich habe mir den 11.5 Treiber von ATI/AMD geladen Probleme mit abstürzten und Display Treiber abstürzten bleiben weiterhin .

so das war es bis jetzt erst mal . Ich hoffe mir kann jemand noch ein paar Tipps geben oder sagen was ich noch machen kann .

MFG Haffke
 
Wenn der Treiber öfter abstürzt würd ich mal auf eine defekte Karte tippen.

Abgestürzt ist mir der Treiber bisher nur bei zu hohem übertakten oder bei defekten Karten.
 
Hmm... aber in Furmark unter voll Auslastung funzt sie perfekt da gibt es so was nicht und die temps sind auch i.o könnte es an einem defektem NT liegen ?
 
Eine zu schwache 12V Leitung kann durchaus Probleme solcher Art verursachen, glaube ich aber in deinem Fall weniger.
Der Treiber kann es sein, eine langsam dahin siechende GraKa ebenso. Ihr BIOS kann eine Anwendung zum richtigen Zeitpunkt nicht richtig steuern, der VRAM hat Probleme mit dem Takten (gern gesehen bei übertakteten Karten) usw. Toll wäre hier natürlich ein Kumpel umme Ecke, der dir seine GraKa mal ausleiht. ;)

Probier doch mal (aus Spass an der Freude :D) den 11.4. oder gar 11.3. Was passiert dann?

Ach ja, und poste doch bitte mal die Karteireiter "Mainboard" und "Memory" mit/von CPU-Z. Möchte mal was gucken.

North-/Southbridge Treiber aktuell? SB sollte ja mit jedem neueren Treiber aktualisiert werden, aber ...
Schau doch mal auf der Seite des MB-Herstellers, ob es da was neues gibt.
--- "Oh, sehe gerade, das hast du wohl schon getan. :)" ---

BIOS ist aktuell? Onboard-Grafik ist deaktiviert?
Ein alter, oder fehlerhafter, Soundtreiber kann auch solche Probleme verursachen.

Irgendwelche USB Geräte/zusätzliche Soundkarten, die man mal abstöpseln könnte?

Last but not least, hast du schon mal einen MemTest86 Durchlauf durchgeführt?
 
Zuletzt bearbeitet:
bin gerade am handy on .

also memtest kann ich gern nochmal machen habe ich vor ne monat oder so das letzte mal gemacht , meinste 24h reichen da aus ? .


das mit dem treiber , muss ich da einfach fen alten drüber bûgrln ? oder mit irgent nem cliner wegmachen ? .


die bilder von cpu z werde ich dir erst am freitag geben können wir die woche ûber beim bund .

zum treiber noch , ich habe in wie vorher schon ohne ccc runtergeladen nur zum verständnis :)


usb geräte habe ich nur tasta und maus und halt ne externe die aber meistens ab is mal abgesehn davon hab ich die erst seit ner woche :)

und wie finde ich raus ob die graka dahin geht ?

noch als kleine info BBC2 kann ich ganz gut zokken bis es meistens nach 30 min oder aber 2h+ abkakt . ansonsten zokke ich noch NFS undergrund 2 und das kakt fast nie ab wobei ich da nicht sagen kann ob es am spiel selbst liegt oder am pc .

mfg Haffke :)
 
, meinste 24h reichen da aus
Japp, pro Riegel ^^

... muss ich da einfach fen alten drüber bûgrln ? oder mit irgent nem cliner wegmachen
Am besten so, um sicher zu gehen:
- PC im abgesicherten Modus starten, alten Treiber sowie alle Treiberreste deinstallieren , löschen (auch von Hand) alle AMD Ordner, die sich so auf C: rumlümmeln (bspw. C:\Users\USERNAME\AppData\Local) und (... Roaming) sowie die Registry auch nochmal putzen mit CCleaner, dann (immer noch im abgesicherten Modus) mit "Regedit" in die Registry.

1) Hot_Key_Current User + Software (alle AMD bzw. ATI - Einträge löschen).
2) Hot_Key_Local_Machine + Software (ebenfalls alle AMD/ATI - Einträge löschen).
3) Hot_Key_Users + Software AMD/ATI-Einträge löschen.

Und frei nach HeinzNeu:
Mit dem Pfad C:\Windows\assembly\ alle Dateien mit der Bezeichnung 90ba9c70f846762e
ausnahmslos löschen. Sodann Papierkorb leeren.

- Dann neu starten, danach den neuen (ggf. einen älteren) Treiber installieren.


die bilder von cpu z werde ich dir erst am freitag geben
- Nur keine Hektik. ;)

und wie finde ich raus ob die graka dahin geht
- Kannst ja mal versuchen, sie mit Furmark zu stressen.

- Last but not least würde mich dein NT interessieren. Genaue Marke u. Spezifikation büdde. :)
(Edith sagt: Die 12V Leitungen wären interessant, und auch das Alter)
 
Zuletzt bearbeitet:
also furmark test habe ich ja schon gemacht ein parr stunden wie gesagt :)

ansonsten zum NT es ist ein cooler master real power m620 und wurde zusammen mit allem anderen ende 2009 gekauft so gegen november wenn mich nicht alles teuscht ^^ . okay das mit dem treiber werde ich dann am we ma angehn :) .


24h pro riegel ? o.O oha okay das muss ich dann im urlaub machen bei 4 riegepn dauerd das en bissi ^^
 
Also ich hatte auch so meine Probleme mit dem ATI-Treiber (Sapphire HD 5770). Habe einige BSOD's mit atimdag.sys gehabt.

Habe jetzt den ATI-Treiber v10.11 installiert. Rechner läuft seit 08 Stunden 55 Minuten fehlerfrei (toi toi toi *auf Holz klopf*)
 
ich glaube aber nicht das wir das selbe problem haben ;) . weil die blusxrens die ich bekomme spuken bei jedem scren en anderen fehler aus ^^
 
Hier schon mal die bilder von CPU-Z die du haben wolltest .

KLIK

KLIK
 
Ok, danke. :)

Hast du schon eine Installation versucht, so wie in post 32 beschrieben?
Und den Memtest? Oder machst du den jetzt am Wochenende?

Was ich in deinen CPU-Z Screens sehe ...

a) Dein BIOS ist vom 19.11.2009 und trägt die Versionnummer 2303. Mit der Version 2503 wurde die Systemstabilität enorm erhöht. Kann sein, dass es dir hilft, muss aber nicht. Mittlerweile gibt es für dein Board die Version 3406.
Ein Update wäre ein guter Versuch. Mit diesem Update Tool geht das kinderleicht. :cool_alt:

Und lass dir nicht einreden, dass ein BIOS Update vom USB-Stick sicherer sei als wie mit einem solchen Tool. Solange der Strom nicht ausfällt während der Prozedur ... :evillol:

b) Was auch nicht schaden kann, wäre der Versuch, dann im BIOS mal die Timings bei gleicher Spannung auf 8-8-8-24 zu stellen. Wirkt bei Asus Boards und AMD CPUs manchmal wahre Wunder. "2T" in der CR steht ja schon, passt also. :)
 
Mem Test mache ich noch . Das mit der Installation habe ich auch schon mal gemacht wenn du dich erinnerst ;) nur dabei ging es darum das control Center weg zu bekommen . Okay meinste wirklich das update hilft ? . Denn ich habe so was noch nie gemacht und habe angst was kaputt zu machen .

In wie fern verschlechtert sich denn meine Performance wenn ich die Timing's so einstelle ? .

soll ich dann gleich die BIOS Version 3406 nehmen ?
 
In wie fern verschlechtert sich denn meine Performance wenn ich die Timing's so einstelle
Die liegen allerhöchstens hauchdünn im messbaren Bereich. Du wirst keinen Unterschied bemerken.

soll ich dann gleich die BIOS Version 3406 nehmen
Japp, selbstredend. Wenn schon, denn schon.

:)
 
So BIOS Update ist vollzogen ging doch einfacher als ich dachte ^^ .

Ich werde jetzt versuchen einen Blue Scren zu reproduzieren

Nachtrag .


nach 5 min's Spielzeit In RUSE Stürzte das Spiel ab und führte mich auf den Desktop zurück mit einem Crash Report . Ich konnte noch ein Bild machen bevor sich mein PC wieder in einem Bluescren verabschiedete .

KLIK

Ich werde jetzt Die timins meines rams umstellen und danach memtest durchlaufen lassen .
 
Zuletzt bearbeitet:
Zurück
Oben