Mot normalt stabil PC - går i bakken (tar seg auto restart)

[G]

Fikk noe som ble kalt for blåskjerm (uten å se blåskjermen). Systemet kalte det for det etter det kom opp igjen, og spurte om jeg ønsket melde det inn til Microsoft. Så gjorde det.

 

På maskinen har jeg Windows 7, 64-bit

 

Jeg har også et Rollback Rx som gjør at jeg kan gå tilbake i tid og sette maskinen til der. Noe jeg nå vurderer å gjøre.

 

Her er hva jeg tenker om det opplevde:

- Jeg har latt maskinen stå døgnet rundt

- Jeg har hatt oppe mange vinduer både i Chrome som er min primære nettleser og i Firefox som er min sekundære nettleser. IE bruker jeg omtrent aldri.

 

- Jeg har ved mange stunder vært timevis bak PC'en uten at dette har skjedd på denne innstallasjonen før, noensinne.

 

- Selvfølgelig kan det ha skjedd midt på natten når jeg sover. Men, det er litt søkt at ved så mange timer "bak rattet" på maskinen, at det ikke har skjedd mens jeg bruker den.

 

- Sitter å lurer litt på om maskinen er kompromittert av noe. Men da har det ihvertfall vært svært lydløse og usynlige inntrengere.

 

- Det jeg har merket meg er at når jeg har mange vinduer oppe samtidig, så kan ting til slutt virke litt sirup. Men, maskinen gir tilbake kontroll alltid.

 

- Nettresponsen har også vært litt småsirup, selv på fiber. Men, jeg tror det må være relatert enten til en dårlig DIR-655, eller til maskinen selv (på det forrige nevnte) hvor jeg har mange nettleservinduer gående.

 

 

Jeg vet ikke helt hva jeg skal tenke. Man kan jo ikke gjøre seg alt for paranoid heller. Men jeg tenker å ta en Rollback nå, for sikkerhetsskyld !

Det gjør jeg vel helst i tilfelle maskinen skulle være kompromittert nå. En ulempe er jo at jeg da sletter en del spor og logger.

 

Jeg vil ha det enkelt, og at det skal virke. Clean install, er det svaret !?

Alltid en kjip prosess å foreta seg.

 

Her er hva jeg fant i Windows:

 

 

 

 

 

Jeg er flink til å ofte nok tilbakestille "Baseline", fordi om det vokser seg en 5 - 6 snapshots stort, så går det også utover PC'ens ytelse:

 

 

Det man kan klø seg i hode over, er at det på så korte uker siden, skal ha vokst 7,5 Gigabyte på systemdisken. Ikke har jeg flyttet noen virtuelle gjeste-OS (for VMware) heller dit. De ligger på egne partisjoner, slik at Rollback Rx ikke skal gå helt bananas.

Endret 31. oktober 2013 av G

[G]

Oppfølger:

 

Ja vel, så lenge varte det før det skjedde igjen, selv med en Rollback en god stund tilbake i tid. 31. oktober - 9. november.

 

Om det fortsetter slik, med at det skjer meg hver niende dag, så blir det en lite hyggelig bruk av denne PC'en. Reformattering og nyinnstallasjon er jo en løsning, men det er alltid lite hyggelig. Jeg får forsøke å være tålmodignok og avvente litt til.

 

Men, jeg er rett og slett jævlig lite fornøyd med hvordan Microsoft har bygget opp dette feilsøkingsopplegget sitt. Man klikker på "la maskinen lete etter en løsning", og den jobber noen sekunder (halvt minutt kanskje) og gir null tilbakemelding.

 

Jeg er ingen Windows "power-user", og har ikke spesielle tanker om å bli det heller. For er det noe som er virkelig kjipt, så er det å skulle lære seg alt mulig rart om et så kjipt OS. Jeg ønsker heller bruke store deler av livet mitt framover på å nyte de andre mulighetene det gir, enn å skulle sitte nedgravd i ulogiske Microsoft programvare.

 

En tanke kan være å ta i bruk et alternativt OS, som ikke så lett lar seg ødelegge over lang tids bruk. Windows er ikke bra nok blitt enda. Her er de stupide feilmeldingene Windows 7 gir en med den feilen jeg opplevde:

 

Men selvfølgelig skriver jeg jo her i håp om at de som er "power users" kan trø til og lære meg det jeg trenger her og nå.

 

 

 

 

 

Og ved denne dialogboksen så ender ALL HJELP som Windows 7 selv kan gi en.

[G]

Fy faen. For en suppe det debuggingsopplegget er:

 

http://msdn.microsoft.com/library/windows/hardware/ff551063(v=vs.85).aspx

 

( http://support.microsoft.com/kb/315263 kilde til lenken ovenfor, krøkkete å lese og krøkkete å finne riktig lenke)

 

NÅ, les følgende:

 

 

 

Windows 7 Debugging Tools for Windows

To debug code running on Windows XP or Windows Server 2003, get the Windows 7 Debugging Tools for Windows package, which is included in the Microsoft Windows Software Development Kit (SDK) for Windows 7 and .NET Framework 4.0. If you want to download only Debugging Tools for Windows, install the SDK, and, during the installation, select the Debugging Tools for Windows box and clear all the other boxes.

Note You might have to uninstall Microsoft Visual C++ 2010 Redistributable components before you install the SDK. For more information, see the Microsoft Support website.

 

Dette er værre en "supperådet" for en amatør eller normal bruker av Windows OS.

[G]

Ok, ser ingen 2010-variant, kun en 2008-variant på min Windows 7:

 

[G]

Nå begynner vel de værste stegene for en amatør (tipper jeg), å skulle ta i bruk debug-verktøyet, som ser ut å være kommando-basert. Æsj.

 

 

 

 

Valget som anbefales til denne type bruk:

 

 

 

HÆ. Hva har Rollback sitt system med dette verktøyet å gjøre? Virkelig rart (ihvertfall for en amatør)

 

Eller heter det Rollback i Windows også, og at jeg kun blander med RollBack Rx programvaren jeg har innstallert på systemet?

 

 

Endret 9. november 2013 av G

[sveinsel]

Ligner på feil som skyldes strømnettet.

Dette er en stasjonær maskin uten batteri?

[Chavalito]

Kanskje du kan laste opp et par dmp filer så noen her kan ta en titt?

[G]

Jeg er jo nokså grønn på dette, men ser ut til at jeg greide meg så langt som dette med pek og klikk:

 

 

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 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 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0xfffff800`0324e000 PsLoadedModuleList = 0xfffff800`034916d0
Debug session time: Sat Nov 9 13:05:20.510 2013 (UTC + 1:00)
System Uptime: 0 days 0:00:14.289
*********************************************************************
* 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 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
Mini Kernel Dump does not contain unloaded driver list
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa8007d0a8f8, 0, 0}

***** 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!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
Unable to load image PSHED.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for PSHED.dll
*** ERROR: Module load completed but symbols could not be loaded for PSHED.dll
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_SECTION_DESCRIPTOR ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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 ***
*** ***
*************************************************************************
Probably caused by : hardware

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

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

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa8007d0a8f8, Address of the WHEA_ERROR_RECORD structure.
Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

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

***** 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!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_SECTION_DESCRIPTOR ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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 ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

FAULTING_MODULE: fffff8000324e000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUGCHECK_STR: 0x124_GenuineIntel

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 0

STACK_TEXT:
fffff880`035d36f0 fffffa80`07d0a8f8 : 00000000`00000001 00000000`00000000 fffffa80`07d0c5e0 fffffa80`07d0a8f8 : nt+0x4adb3c
fffff880`035d36f8 00000000`00000001 : 00000000`00000000 fffffa80`07d0c5e0 fffffa80`07d0a8f8 00000000`00000000 : 0xfffffa80`07d0a8f8
fffff880`035d3700 00000000`00000000 : fffffa80`07d0c5e0 fffffa80`07d0a8f8 00000000`00000000 00000000`00000000 : 0x1


STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hardware

IMAGE_NAME: hardware

BUCKET_ID: WRONG_SYMBOLS

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

 

 

Hvor jeg ikke er sikker på om det er nødvendig å paste alle data inn, eller om noe av det er støy. Derfor alt i en spoiler ovenfor for spesiellt interesserte, og bunn-utklippet nedenfor her, fra de samme data som man finner i spoiler:

 

ADDITIONAL_DEBUG_TEXT:

Use '!findthebuild' command to search for the target build information.

If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

FAULTING_MODULE: fffff8000324e000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUGCHECK_STR: 0x124_GenuineIntel

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 0

STACK_TEXT:

fffff880`035d36f0 fffffa80`07d0a8f8 : 00000000`00000001 00000000`00000000 fffffa80`07d0c5e0 fffffa80`07d0a8f8 : nt+0x4adb3c

fffff880`035d36f8 00000000`00000001 : 00000000`00000000 fffffa80`07d0c5e0 fffffa80`07d0a8f8 00000000`00000000 : 0xfffffa80`07d0a8f8

fffff880`035d3700 00000000`00000000 : fffffa80`07d0c5e0 fffffa80`07d0a8f8 00000000`00000000 00000000`00000000 : 0x1

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hardware

IMAGE_NAME: hardware

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

---------

Endret 9. november 2013 av G

[G]

Ligner på feil som skyldes strømnettet.

Dette er en stasjonær maskin uten batteri?

 

Jo, det er ikke noe batteri, og det er en Stasjonær variant. Dump fil lastet inn nå. Går det an å få mer informasjon ut av den med verktøyet. REF, det markert i rødt i forrige innlegget mitt? Fant ut at det egentlig var en windows-variant der etter innstallasjon, slik at man slapp kommando-verktøy:

 

Endret 9. november 2013 av G

[sveinsel]

Du må skaffe deg en ordentlig UPS gjerne en APC 650.

 

Så må du ta en ny installasjon, dette kommer du ingen vei med.

[Chavalito]

Det var ikke debug jeg mente, men selve dmp filen som du finner i C:\Windows\MInidump. Etter som du mangler symbolene vil ikke analysen bli rett.

[G]

Da har jeg sendt dumpfilen til Chavalito, dersom det kan være noe hjelp i. Jeg er som sagt ganske grønn på temaet debugging. Gi lyd dersom det ikke var noe interessant å finne der. Takk for at dere gidder bruke tid på dette. Men, det er jo derfor man har forumet, noen ganger hjelper "du" noen, og andre ganger er det "du" som får hjelp tilbake.

 

[G]

Du må skaffe deg en ordentlig UPS gjerne en APC 650.

 

Så må du ta en ny installasjon, dette kommer du ingen vei med.

 

Jeg har en skåltom Powerware 9120 (dyr sak, 700 VA modellen) med tilnærmet ekte sinuskurve på. Men, den hadde jeg tenkt å kjøpe nye blysyrebatterier,

 

til bruk en gang på eventuelle server, NAS, eller noe sånn. Støynivået på Powerware'n er litt for høyt til å ha under skrivepulten, IMHO.

 

Det kunne jo være greit å slippe skjøteledning "bort til/ned til/opp til" PC'en man bruker ved skrivepulten, så kanskje jeg burde kjøpe en sånn rimelig sak som du nevner. Ser den koster opp til kr 700 her:

 

http://www.pricegrabber.com/computers/upss++10306-back-ups-es-650va-desktop-650-va-390-wdesktop-0-07-hour-0-26-hou/m-66039286/

Endret 9. november 2013 av G

[froggyler]

Du bruker tydligvis maskina mye, jeg erfarte at problemet med plutselige restarter uten meningsfulle feilmeldinger forsvant etter en runde med støvfjerning på hovedkortet, spesielt mellom ram brikkene.

[Chavalito]

Som jeg sa, mente du skulle laste opp dmp filen, så tok meg den frihet å laste den opp slik at andre kan se på den. Er på arbeids PC og her har jeg dessverre mange restiksjoner osv.

 

110913-45255-01.zip

 

Men det ser ut som det er ntoskrnl.exe som krasjet med det lille jeg kunne finne ut. Men det ser også ut til at det er en hardware feil da det dukker opp WHEA_UNCORRECTABLE_ERROR (124) også. Men uten å debugge dmp filen kommer jeg ikke langt, noe jeg ikke kan gjøre på arbeid.

 

Hardware feil kan være skjermkort, hovedkort, CPU etc.

[sveinsel]

Har litt bedre tid:

I Norge har vi to forskjellige strømnettverk, det er IT- varianten der 0 punktet i generatoren (og dermed transformatoren) ikke er jordet.

Så har vi TT varianten (som også er europeisk standard), der dette 0 punktet ER jordet.

Strømleverandøren har både planlagte, og ikke planlagte utkoblinger. Linjer kobler ut og inn. Vi merker ikke alt dette rotet på lyset for koblingene skjer så fort. Etter tilkoblingene får man også en del spenningspulser.

Dette er "drepen" for datamaskiner for de "oppdager" svingningene og blir slått av under utkoblingene.

Den beste måten for å verge seg mot dette er å gjemme seg bak batterier, for de absorberer spenningspulsene!!

Utstyret i seg selv er blitt bedre med tiden, og jeg ser at f.ex. strømadaptere er beregnet for 100-240 V inn og gir jevn 12V ut.

Endret 9. november 2013 av sveinsel

[G]

Har litt bedre tid:

I Norge har vi to forskjellige strømnettverk, det er IT- varianten der 0 punktet i generatoren (og dermed transformatoren) ikke er jordet.

Så har vi TT varianten (som også er europeisk standard), der dette 0 punktet ER jordet.

Strømleverandøren har både planlagte, og ikke planlagte utkoblinger. Linjer kobler ut og inn. Vi merker ikke alt dette rotet på lyset for koblingene skjer så fort. Etter tilkoblingene får man også en del spenningspulser.

Dette er "drepen" for datamaskiner for de "oppdager" svingningene og blir slått av under utkoblingene.

Den beste måten for å verge seg mot dette er å gjemme seg bak batterier, for de absorberer spenningspulsene!!

Utstyret i seg selv er blitt bedre med tiden, og jeg ser at f.ex. strømadaptere er beregnet for 100-240 V inn og gir jevn 12V ut.

 

Jeg ser du henger på med strømteori fremdeles. Og det er ikke en helt uaktuell problemstilling faktisk. Men, hvordan tolker du det til å være det som er reell feil hos meg? Jeg lurer litt på det.

 

Jeg hadde lynnedslag for ikke så lenge lenge siden. Det tok knekken på Viasat paraboldekoderen. Og jeg måtte ta av strømmen og på igjen og det tok litt tid før den fikk summet seg tilbake, og TV-bilde igjen kom opp og gikk.

 

MEN, den stod beskyttet bak et mellomvern av en ganske kraftig variant i sikringsskapet, men likevel plantet altså pulsen seg til TV-oppsettet mitt.

 

Jeg gikk siden inn på rommet der datamaskinen står og surrer 24/7 (normalt sett), men den var like levende og responsiv på tross av strømforstyrrelsen. Men, jeg et billig finvern på den stasjonære PC'en, og et dyrere finvern der trådløs router står og surrer. Det har nok vært årsaken til at PC'en tålte dette bedre.

 

Så, ja du har innertier på at det kan være en strømrelatert ting.

 

EDIT: korrigert uttrykket grovvern til mellomvern

Endret 1. august 2014 av G

[sveinsel]

"En uventet omstart" synes jeg er en "vakker skildring" av fenomenet. Jeg tenker tilbake på tiden med to floppydisker der man omtrent måtte "save" tankerekken før man fikk den ned på tastaturet.

Det ene er når tilfellene "bare" forårsaker at maskinen blir tregere etter hvert, til de slår ut hele BIOS.

 

Til lykke med farsdagen!

[G]

Da skjedde det igjen, omtrent 1 døgn etterpå. Mens, jeg satt og forfattet et innlegg i nettopp denne tråden. Ok, så jeg deler ikke det jeg hadde skrevet på ny. Men:

 

Jeg er enda litt usikker på om man kan konkludere med lynnedslag. Dersom skade er skjedd, så får jeg nesten håpe komponenten dør.

 

Sannsynligvis er det ikke disken, fordi jeg har aldri opplevd de gangene jeg har sett PC'er knele at disken har tatt skade. Så da krysser jeg fingrene for at disken min er sånn noenlunde trygg inntil videre.

 

 

 

 

 

 

Ny minidump-fil:

111013-38610-01.zip

 

[G]

Du bruker tydligvis maskina mye, jeg erfarte at problemet med plutselige restarter uten meningsfulle feilmeldinger forsvant etter en runde med støvfjerning på hovedkortet, spesielt mellom ram brikkene.

 

Jeg kan forsøke å lete etter støv og hybelkaniner der inne. Et helt ok forslag

 

Sammenlikner litt på dialogmeldingene for "unexpected shutdown"

 

BCP2 (9.november): FFFFFA8007D0A8E8

 

BCP2 (10.november): FFFFFA8007D6E038

Endret 10. november 2013 av G