PCen restarter seg random, hjelp?

[Starcraft_RULES]

Hei.

Har ganske ny PC men blir innimellom plaget av merkelige restarter, i begynnelsen trodde jeg det bare var i spill (ble for varm) for da restartet den seg en god del.

Men det viser seg at den innimellom restarter seg uten noen grunn også.

 

Noe den gjorde nettopp. Event viewer: Error:

\SystemRoot\SysWow64\drivers\MTictwl.sys has been blocked from loading due to incompatibility with this system. Please contact your software vendor for a compatible version of the driver.

 

og

 

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID

 

Vet ikke om det har noe å si.

Men når den restartet seg så jeg blå skjerm i et sekund.

 

PC:

Xp 64, Core2 quad, Gigabyte 6-quad x38-dq6, GT8800 Gainward,Corsair 620W, Crucial DDR2 BallistiX PC8500

 

Edit: så i tråden under om C:windows:Minidump; der er det 6 småfiler.

Endret 29. mars 2008 av Starcraft_RULES

[fenderebest]

Om den lager minidump filer når den restarter kan du feilsøke disse med Windbg!

[Starcraft_RULES]

Jeg finner ikke Windbg..

åååhh.. må lastes ned ja.

Endret 30. mars 2008 av Starcraft_RULES

[RoXx]

En enkel sjekk er å underklokke systemet fullstendig og peise igang f.eks 3Dmark i loop.

 

Det kan være ganske problematisk å feilsøke en cpu som blir for varm, fordi den gir ikke nødvendigvis samme feilen.

 

F.eks , spiller du et spill og cpu`n gir opp, så gir den kanskje skylda på en random dll fil som var i bruk da pcn ble trist.

 

Opplever at mange kjøper seg ei "custom" vifte og ikke helt får festet den godt nok til prosessoren som da resulterer i random krasj. (har også hendt undertegnede som brukte slepne 2 dager på å finne feilen)

 

Si ifra hvis du finner ut om det kan være feilen, og sjekk på hardware monitor i bios om temperaturen på cpu`n er festlig. Rett etter den har kræsja selvfølgelig;)

[Starcraft_RULES]

 

Microsoft ® Windows Debugger Version 6.8.0004.0 AMD64

Copyright © Microsoft Corporation. All rights reserved.

 

 

Loading Dump File [C:\WINDOWS\Minidump\Mini033008-01.dmp]

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

 

Symbol search path is: *** Invalid ***

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

* Symbol loading may be unreliable without a symbol search path. *

* Use .symfix to have the debugger choose a symbol path. *

* After setting your symbol path, use .reload to refresh symbol locations. *

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

Executable search path is:

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

* Symbols can not be loaded because symbol path is not initialized. *

* *

* The Symbol Path can be set by: *

* using the _NT_SYMBOL_PATH environment variable. *

* using the -y <symbol_path> argument when starting the debugger. *

* using .sympath and .sympath+ *

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

Unable to load image ntoskrnl.exe, Win32 error 0n2

*** WARNING: Unable to verify timestamp for ntoskrnl.exe

*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe

Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`011d5100

Debug session time: Sun Mar 30 00:09:38.953 2008 (GMT+1)

System Uptime: 0 days 1:23:16.698

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

* Symbols can not be loaded because symbol path is not initialized. *

* *

* The Symbol Path can be set by: *

* using the _NT_SYMBOL_PATH environment variable. *

* using the -y <symbol_path> argument when starting the debugger. *

* using .sympath and .sympath+ *

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

Unable to load image ntoskrnl.exe, Win32 error 0n2

*** WARNING: Unable to verify timestamp for ntoskrnl.exe

*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe

Loading Kernel Symbols

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

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

Loading User Symbols

Loading unloaded module list

.........

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

* *

* Bugcheck Analysis *

* *

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

 

Use !analyze -v to get detailed debugging information.

 

BugCheck 109, {a3a03a382bec1548, 0, bbe6fafe3328ed11, 101}

 

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

 

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!_KPRCB ***

*** ***

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

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!KPRCB ***

*** ***

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

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!_KPRCB ***

*** ***

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

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!KPRCB ***

*** ***

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

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!_KPRCB ***

*** ***

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

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!_KPRCB ***

*** ***

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

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!_KPRCB ***

*** ***

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

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

*** ***

*** ***

*** Your debugger is not using the correct symbols ***

*** ***

*** In order for this command to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** work. ***

*** ***

*** Type referenced: nt!_KPRCB ***

*** ***

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

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

* Symbols can not be loaded because symbol path is not initialized. *

* *

* The Symbol Path can be set by: *

* using the _NT_SYMBOL_PATH environment variable. *

* using the -y <symbol_path> argument when starting the debugger. *

* using .sympath and .sympath+ *

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

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

* Symbols can not be loaded because symbol path is not initialized. *

* *

* The Symbol Path can be set by: *

* using the _NT_SYMBOL_PATH environment variable. *

* using the -y <symbol_path> argument when starting the debugger. *

* using .sympath and .sympath+ *

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

Probably caused by : ntoskrnl.exe ( nt+2e950 )

 

Followup: MachineOwner

---------

 

 

Sier dette noe?

 

Har lastet ned 3dmark06 skal teste den.

Viften er den som fulgte med, skal prøve å sjekke det også

Endret 30. mars 2008 av Starcraft_RULES

[fenderebest]

Du må sette opp en symbol-bane i Windbg for å produsere noe leselig.

 

CTRL+S skriv inn : srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

CTRL+I skriv inn :

srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

 

Deretter kjører du !analyze -v i kommandolinjen.

[Starcraft_RULES]

 

3: 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: a3a03a382bec1548, Reserved

Arg2: 0000000000000000, Reserved

Arg3: bbe6fafe3328ed11, Failure type dependent information

Arg4: 0000000000000101, 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

 

CUSTOMER_CRASH_COUNT: 1

 

DEFAULT_BUCKET_ID: DRIVER_FAULT

 

PROCESS_NAME: System

 

CURRENT_IRQL: 0

 

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff8000102e950

 

STACK_TEXT:

fffffadf`9108d858 00000000`00000000 : 00000000`00000109 a3a03a38`2bec1548 00000000`00000000 bbe6fafe`3328ed11 : nt!KeBugCheckEx

 

 

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: BAD_STACK

 

Followup: MachineOwner

---------

 

3: 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: a3a03a382bec1548, Reserved

Arg2: 0000000000000000, Reserved

Arg3: bbe6fafe3328ed11, Failure type dependent information

Arg4: 0000000000000101, 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

 

CUSTOMER_CRASH_COUNT: 1

 

DEFAULT_BUCKET_ID: DRIVER_FAULT

 

PROCESS_NAME: System

 

CURRENT_IRQL: 0

 

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff8000102e950

 

STACK_TEXT:

fffffadf`9108d858 00000000`00000000 : 00000000`00000109 a3a03a38`2bec1548 00000000`00000000 bbe6fafe`3328ed11 : nt!KeBugCheckEx

 

 

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: BAD_STACK

 

Followup: MachineOwner

 

 

ok, da tror jeg jeg gjorde rett?

[RoXx]

Hohoi! Finfin feilmelding... som kan bety... alt mulig:)

 

Som jeg nevnte tidligere , så er dette en tungvint måte å gjøre det på.

 

At minne kommer opp som "feilen" gjør det veldig ofte, da programmene som skriver til minnet krasjer... og minnet får skylda

 

et program som heter memtest86 (tror jeg hvis jeg husker riktig) kan sjekke om minnet er på syre eller er litt lei seg.

 

Men, nå det er sagt. Jeg mistenker at noe er varmt i systemet ditt.

 

Litt info hadde vært greit , som f.eks : har du nettopp skifta cpu,skjermkort,minne?

 

Og gjerne si ifra om du har fått underklokka pcn og den viser tegn til stabilitet, det ville eliminert sinnsvakt mye. Hvis systemet er varmt så får du random feil hele tia som er umulig å feilsøke.

 

Samme med minnet forsåvidt, er det på tryne så kan du få en hel festival av feil;)

Endret 30. mars 2008 av RoXx

[fenderebest]

Det der så ikke helt bra ut, du bør sjekke det fysiske minnet ditt.

 

Roxx bør forresten ikke prate om ting uten å sette seg skikkelig inn i det først

Endret 30. mars 2008 av fenderebest

[RoXx]

Men da er det jo bra vi har en ekspert som deg her da vettu;)

 

Da kan du jo bare løse hele greia og forklare feilen;)

 

Fantastisk!

 

fyr løs!

Endret 30. mars 2008 av RoXx

[fenderebest]

Den feilen kan ikke forårsakes av hverken drivere eller programmer på et x64 system ei heller det sannsynlig at dette forårakes av varme.

 

Dette er forårsaket av korrupsjon i det fysiske minnet. Sett deg inn i hvordan Windows fungerer og lær deg litt assembler så kan vi snakke

[RoXx]

Så du mener at korrupsjon i annen hardware forårsaket av f.eks varme ikke kan lede

til feilmelding av denne typen (korrupsjon i minnet)?

 

Og for den saks skyld, en driver...

Endret 30. mars 2008 av RoXx

[fenderebest]

Når prosessoren går varm kan det begynne å referere til gale addresser den vil ikke kunne korrputere disse regionene av det fysiske minnet da den rett og slett ikke har tilgang til det og dette da ville "trigge" en helt annen feil.

 

Samme med drivere de har ikke tilgang til dette området og kan derfor ikke skrive noe som kan korruptere det.

 

Se feks her på et eksempel av hvordan minnet oppfører seg når prosessoren går varm.

Endret 30. mars 2008 av fenderebest

[RoXx]

Sjekket ut diverse forum angående CRITICAL_STRUCTURE_CORRUPTION (109)

 

Og i flere tilfeller har du rett angående at minnet kan ha tatt kvelden, skal gi deg den;)

 

Jeg vet når jeg har tapt, og må nok smekke igjen den store kjeften min.

 

Jeg gikk etter det han selv nevnte om at pcn ga seg i spill (høy prosessorbruk gfx etc)

og den var ikke konsis i feilene... Det luktet varmgang i systemet for å si det sånn.

 

Jeg studerte vel feilmeldinga altfor fort tyvârr.

 

uansett så har underklokking av systemet og kjøring av alt på fullstendig "failsafe" eliminert ganske mye... det kan jo hende han har feil settings på ram hastigheten:P

[Starcraft_RULES]

Takk for mange svar, selv om jeg ikke forstår alt her.

Men at minnet er problemet tror jeg kan være rett.

KJørte 3Dmar05 2 ganger og PCen klikket veldig raskt. Jeg overvåket CPUen og 55grader var det på det høyeste.

 

Prøvde også litt på Memtest86, men fikk det ikke til.

Så hvordan finner jeg ut sikkert at det er minnet?

lær meg litt assembler??

 

Edit: PCen har jeg bygget i Juletiden, så alt er "nytt".

Endret 30. mars 2008 av Starcraft_RULES

[Starcraft_RULES]

Så da bytter jeg minnet?

[fenderebest]

Om du har noen brikker til overs så kan du jo teste dette, om du bruker flere minnebrikker kan du prøve en og en brikke. Sjekk også i BIOS at de får den spenningen de skal ha.

 

Ikke at jeg er noen ekspert i memtest men det er da bare å boote fra en cd med memtest på og kjøre noen runder?

[Starcraft_RULES]

ok. skal prøve å sjekke det.

Brukte memtest med Daemom tools, må kanskje brenne ut en cd.

[Starcraft_RULES]

Fikk til MemTest og får error med en gang:

Pair 51929237 does not store values accurately. Memtest has detected that your computer cannot accurately store data in RAM, You need ta fix this.

 

EDIT: Så i BIOS nå og alt står på normal eller auto.

Skal jeg se etter noe spesielt?

Endret 30. mars 2008 av Starcraft_RULES

[Starcraft_RULES]

Nå har jeg tatt ut en og en RAM-brikke og først når det bare var en igjen (1024) fikk jeg null feil i Memtest og klarte å kjøre hele 3Dmark05 (13322 3DMarks)

 

Da forteller det meg?