BSODs door kapotte hardeschijf?

[Gropah]

Ik heb recentelijk mijn desktop, dezelfde als van een eerder probleem topic, geupgrade van windows 7 naar windows 10. Update aangaande de problemen die ik had: die zijn soort van spontaan opgehouden. De desktop leek goed te draaien, maar ik kreeg helaas last van BSODs en heb dus te maken met een instabiel systeem. De linux die op een andere schrijf draait loopt echter nog steeds even lekker, ook onder full load voor langere tijd.

Deze BSODs zijn random in tijd (soms 20 minuten, soms 2 uur, maar nooit veel korter) en hebben allemaal de melding: INTERNAL_POWER_ERROR. Omdat ik initieel dacht dat het problemen waren met de NVIDIA driver heb ik gebruik gemaakt van de nieuwe functie van Windows 10 om de systeem schijf te formatteren en zichzelf naar een manifacturer default te zetten, waarna ik de nieuwste stabiele drivers voor windows 10 heb gepakt. Dit heeft echter niet geholpen.

Ik ben vervolgens nogmaals met BlueScreenView gaan kijken naar de minidumps die windows heeft gemaakt. Deze geven een redelijk eentonig beeld.

Zoals je kunt zien, een aantal BSODs met als hoofdoorzaak spaceport.sys, welke na wat Google-werk gelinkt blijkt te zijn aan Windows volume management. Dit zou kunnen betekenen dat mijn bootschijf kapot zou kunnen zijn. Dit zou verklaren waarom mijn Linux nog wel goed werkt, terwijl windows om de haverklap uit valt. Ik ben echter verder wezen kijken, omdat ik er een beetje moeite mee heb dat een update van OS een SSD zou kunnen vernachelen, en daarbij ben ik wat verder gaan kijken naar de foutmeldingen, zoals ook te zien in het volgende plaatje:



Hierbij staan dus zowel ntoskrnl.exe als spaceport.sys roodgekleurd, waardoor ik denk af te lezen dat dat de schuldigen zijn. Spaceport heb ik eerder benoemd, maar ntoskrnl.exe niet. Wat ik hier over heb kunnen vinden is dat het proces de planner is van verschillende resources inclusief cache, geheugen en de kernel. Het zou kunnen dat dit gelinked is aan de kapotte hardeschijf, maar dus ook aan het RAM. Verder staat er nog mcupdate_AuthenticAMD.dll tussen. Helaas kon ik hier niet extreem veel over vinden. Ik kwam op 2 dingen uit: iets met McAffee, de virusscanner, die ik niet gebruik en AMD drivers. Er zijn in ieder geval geen videokaart drivers aanwezig, maar mijn PC heeft wel een Phenom 2 X6 er in zitten, dus het zou prima kunnen dat het daar van komt.

Dus wat heb ik al gedaan om te het te fixen/probleem te achterhalen? Zoals gezegd, mijn linux distro draait gewoon, zelfs onder load, dus het is niet een issue met de gedeelde componenten, anders zou Linux er denk ik ook wel uit knallen. Ik heb Windows dus opnieuw geinstalleerd (inclusief drivers). Verder heb ik de beide kabels van de SSD herplugd aan beide kanten. Ook heb ik de RAM bankjes geherinstalleerd, just in case.

Ik ben zelf dus een beetje ten einde raad, behalve dat mijn SSD kapot zou kunnen zijn. Ik zou het echter wel iets te toevallig vinden als mijn SSD stuk gaat tijdens een upgrade naar windows 10. Wie-o-wie kan mij helpen/een zetje in de goede richting geven?

[rikadoo]

Zou je misschien een screenshot kunnen maken van SMART waardes van de HDD/SSD waar windows/linux opstaat? Dit kan met CrystalDiskInfo of HDTune.

[johnkeates]

Wat zijn de specs, en wat zijn de SMART waardes van je disks? Als Windows-bestanden als boosdoener aangeduid worden is het meestal een hardware defect en niet een defect in het Windows-bestand, met SFC kan je zeker zijn dat je systeembestanden OK zijn;

[Gropah]

Dat ik daar zelf nog niet opgekomen was...

Met behulp van CrystalDiskInfo:



De schijf zelf lijkt dus nog wel goed te zijn als ik dit zo snel zie

edit: wait, wut? Hij zegt goed, maar bij bijna alle rijen is het zo dat de current value hoger is dan de threshold? Of lees ik het verkeerd af?

edit: Gaat dus om pricewatch: Kingston SSDNow V+100 SVP100S2B/96GR (upgrade bundle kit) 96GB

[ Voor 53% gewijzigd door Gropah op 10-09-2015 21:16 ]

[rikadoo]

Ziet er idd goed uit. Je zou even een memory check kunnen doen en die een paar uur laten draaien omdat ook uit te sluiten. (memtest86)

[Verwijderd]

Mja, dit soort SSDs zijn inherent onbetrouwbaar. Ze hebben geen beveiliging tegen niet-netjes afsluiten. Gevolg is dat de SSD zelf maar acties gaat ondernemen om de mapping tables weer consistent te maken, met als gevolg lichte datacorruptie. De SSD zal blijven werken, maar corruptie nu en dan is normaal met dit soort SSDs.

Tip: koop voortaan een echte SSD. Je zult nooit kunnen verifiëren of dit inderdaad de oorzaak is. Maar je wilt dit soort gezeik niet. Dus koop een echte SSD zoals Crucial M500/M550/MX100/MX200 of een Intel 320/S3500/S3700. SSDs zoals Samsung hebben een softwarematige bescherming in de vorm van journaling op de mapping tables. Dat werkt ook afdoende voor desktops, maar kan ook problemen geven als de SSD in RAID arrays wordt geplaatst of andere vormen van complexe opslag.

[Gropah]

rikadoo schreef op donderdag 10 september 2015 @ 21:17:
Ziet er idd goed uit. Je zou even een memory check kunnen doen en die een paar uur laten draaien omdat ook uit te sluiten. (memtest86)

Heb het net een kleine 2 uur gedraaid en gaf geen fouten. Gezien SMART niets aangaf en memtest ook niet, moet de fout ergens anders gezocht worden? Of kan het alsnog de SSD zijn?

Verwijderd schreef op donderdag 10 september 2015 @ 21:51:
Mja, dit soort SSDs zijn inherent onbetrouwbaar. Ze hebben geen beveiliging tegen niet-netjes afsluiten. Gevolg is dat de SSD zelf maar acties gaat ondernemen om de mapping tables weer consistent te maken, met als gevolg lichte datacorruptie. De SSD zal blijven werken, maar corruptie nu en dan is normaal met dit soort SSDs.

Tip: koop voortaan een echte SSD. Je zult nooit kunnen verifiëren of dit inderdaad de oorzaak is. Maar je wilt dit soort gezeik niet. Dus koop een echte SSD zoals Crucial M500/M550/MX100/MX200 of een Intel 320/S3500/S3700. SSDs zoals Samsung hebben een softwarematige bescherming in de vorm van journaling op de mapping tables. Dat werkt ook afdoende voor desktops, maar kan ook problemen geven als de SSD in RAID arrays wordt geplaatst of andere vormen van complexe opslag.

Ik moet eerlijk zeggen dat ik niet genoeg over SSD's weet om precies te weten waar het fout zou zijn gegaan, maar aangenomen dat de SSD die ik heb inderdaad niet goed tegen verkeerd afsluiten kan dan zou er inderdaad data corruptie/verlies op lange termijn uit kunnen maken. Echter, na een format van de SSD zou het toch gewoon weer naar zijn begin stand moeten zijn gezet en dus schoon zonder corruptie/verlies? En dat is wat er is gebeurd met de herinstallatie van windows 10 die ik al heb gedaan.

Overigens: hoe moet ik het verschil zien tussen een SSD en een "echte" SSD? AFAIK betekend een SSD niet meer dan dat er flash-achtig geheugen word gebruikt voor opslag, welke erg snel te benaderen.

[Ketho]

Gropah schreef op donderdag 10 september 2015 @ 21:13:
edit: wait, wut? Hij zegt goed, maar bij bijna alle rijen is het zo dat de current value hoger is dan de threshold? Of lees ik het verkeerd af?

Weet niet of het al gezegd is of dat het al duidelijk is. De value is hoe lager hoe slechter oid

[Verwijderd]

Flash heeft inherent nadelen. Namelijk extreem trage write performance als er bestaande data staat op dezelfde plek. Die moet eerst worden gewist en wissen kan alleen in blokken van 512K of groter. De eerste SSDs zoals Mtron en MemoRight, waren wel snel met lezen en sequential write, maar langzamer dan hardeschijven op het gebied van random writes precies om deze reden.

Vanaf de Intel X25-M ontstond de moderne SSD die trucjes toepast om dit nadeel te verzachten/verdoezelen: redirected writes. Dat betekent dat de SSD eigenlijk naar een andere plek schrijft, en onthoudt waar de host (je computer/windows/NTFS-filesystem) denkt dat de informatie is opgeslagen. Dus die tabel moet aanwezig zijn want zonder die tabel weer de SSD niet welke data op de NAND flash overeenkomt met waar Windows denkt dat het opgeslagen is. En daar wringt het schoentje: als die mapping tables niet kloppen (niet consistent met de data) dan kan de hele SSD stuk/onbruikbaar worden - in elk geval tijdelijk. Dit gebeurde ook massaal bij bijvoorbeeld SSDs van OCZ waar 9 van de 10 geretourneerde SSDs precies dit euvel had: de hardware was fysiek in orde maar de mapping tables zijn niet meer consistent waardoor de SSD intern niet meer goed werkt. Een softwarematige defect.

Dan kreeg je twee soorten SSDs: zij die de data maar aanpassen aan de mapping tables; en dan heb je dus (lichte) corruptie die voor blauwe schermen cq. bootproblemen kan zorgen, ofwel SSDs die het netjes doen en een beveiliging inbouwen voor dit probleem. Een dergelijke beveiliging kan hardwarematig (power-safe capacitors) of softwarematige gebeuren; zoals Samsung doet met journaling op de mapping tables. Bij dat laatste gaat de SSD terug in de tijd. De firmware moet helemaal ontworpen zijn om dit mogelijk te maken; bestaande data ook al is die niet meer nodig, mag niet meer zomaar worden overschreven omdat deze wel door de oudere versie gebruikt wordt.

Hardwarematige bescherming is natuurlijk superieur. Dan kom je op de Intel 320 die volledige bescherming heeft dankzij de interne SRAM buffercache. Of andere SSDs die de DRAM-chip gebruiken voor host-writes en maar beperkte capacitors hebben om alleen de huidige write af te wikkelen, zoals de Intel S3500/S3700 en Crucial M500/M550/MX100/MX200. Al deze SSDs zijn gewoon prima, al helemaal voor thuisgebruik.

Jij hebt een 'prut SSD' met Toshiba controller. Die heeft geen bescherming en veel bekend over de firmware is er ook niet. Dus vrijwel zeker dat er 'windows of opportunity' ontstaan waarbij corruptie kan onstaan. Dat betekent dat elke keer bij een 'Unsafe Power-Loss' je als het ware een dobbelsteen gooit en dan KAN er corruptie ontstaan. Dat hoeft overigens niet; hangt er vanaf wat de SSD aan het doen was op dat moment. Maar ook als de host (Windows/NTFS) niets deed op dat moment, kan de SSD intern wel bezig zijn met garbage collection. Dus die window of opportunity is best groot.

Punt is dus gewoon dat SSDs die niet beveiligd zijn, inherent onbetrouwbaar zijn en corruptie altijd op de loer ligt. Dergelijke SSDs kun je eigenlijk niet gebruiken omdat er altijd wel iets kan gebeuren met extreem vage klachten. De SSD is niet 'stuk' - hij is min of meer ontworpen om af en toe corruptie te genereren. Dergelijke SSDs zijn min of meer onbruikbaar. Je wilt dit soort gezeik niet.

Ik raad je dus aan om een 'echte' SSD te kopen, zoals de Crucial MX200 256GB - een van de beste allround consumenten SSDs van dit moment.
Om nog enigszins s

[Renault]

De key question is natuurlijk waar het grote aantal "Unsafe Shutdowns / powerlosses" vandaan komt: als de SSD geen unexpected power loss voor zijn kiezen krijgt zal de hoeveelheid problemen ermee ook kleiner zijn.

Omdat je blijkbaar gewoon kunt wachten op uitval ("20 minuten - 2 uur"): is de voeding wel helemaal lekker?

[begintmeta]

Windows lijkt er helaas gewoon niet altijd voor te zorgen dat de schijf weet dat de stroom straks wegvalt (ik meen dat het ata-signaal "standby immediate" daar normaalgesproken voor zorgt), wellicht driver-gerelateerd

[ Voor 25% gewijzigd door begintmeta op 11-09-2015 08:04 ]

[Reepje]

Toch vind ik het raar,je windows10 erop, er komen fouten, en dit vervolgens aan de SSD zou liggen.
Veel meer voor de hand liggend is, dat de harware niet met windows 10 kan omgaan.
Om dit te testen, zet windows 7 er weer op (of 8 ).

Ook als ik kijk naar de fout spaceport.sys, die blijkbaar ook veelvuldig voorkwam toen mensen van 7 naar 8 overstapten. Dat was oa te verklaren door incompatible hardware/drivers. Maar de fout kan inderdaad ook corrupte data als oorzaak hebben. Dat kan aan de SSD liggen, maar ook aan een foutje op je installatie medium.

Daarnaast vind ik de stelling dat de Kingston v100+ een prut SSD is overtrokken. Inderdaad hij heeft geen stroomverliesbescherming, maar deze SSD heeft geen slechte track record. 2011 was deze razend populair hier op Tweakers, en toen heb ik er ook eentje gekocht. Dat ding is niet kapot te krijgen (bij mij). Je hoort ook weinig klachten over deze SSD. Kijk als we het nu over de OCZ vertex/agility familie hebben, daar valt misschien wel 50% van uit. Dan zou ik de SSD ook verdenken.

[Gropah]

Reepje schreef op vrijdag 11 september 2015 @ 09:51:
Toch vind ik het raar,je windows10 erop, er komen fouten, en dit vervolgens aan de SSD zou liggen.
Veel meer voor de hand liggend is, dat de harware niet met windows 10 kan omgaan.
Om dit te testen, zet windows 7 er weer op (of 8 ).

Ik vind het zelf ook wel ver gezocht, zoals ook wel naar voren komt in de TS, maar de minidump suggereert in ieder geval dat het aan de SSD ligt.

Windows 7 er op zetten klinkt wel als een goed idee om te kijken of dat het oplost, dus dat zal ik maar eens gaan doen als ik tijd heb.

Ik wil (en moet waarschijnlijk uiteindelijk) toch wel graag over op windows 10, dus dan wil ik wel graag weten welk onderdeel roet in het eten gooit en zoals ik al eerder zei lijkt het de SSD te zijn.

Renault schreef op vrijdag 11 september 2015 @ 07:53:
De key question is natuurlijk waar het grote aantal "Unsafe Shutdowns / powerlosses" vandaan komt: als de SSD geen unexpected power loss voor zijn kiezen krijgt zal de hoeveelheid problemen ermee ook kleiner zijn.

Omdat je blijkbaar gewoon kunt wachten op uitval ("20 minuten - 2 uur"): is de voeding wel helemaal lekker?

Ik heb de luxe van een 2e voeding niet, dus voordat ik voordat ik van iemand anders een voeding moet regelen vroeg ik mij of er een manier is waarop ik de voeding kan testen zonder een 2e voeding te hebben?

[Reepje]

De unsafe shutdowns komen niet door de voeding, maar doordat de computer vastloopt, of doordat de stekker er per ongeluk uitgetrokken wordt (of de stop die eruitvliegt). Bij het testen van de previews win10 op een laptop (met de Kingston V+100 erin) heb ik zoveel vastlopers gehad dat ik ze niet meer kon tellen. Nu heb ik eens gekeken in de smart en de score is redelijk, 276 keer unsafe shutdown.

Wat wijst op falen van de ssd? Ik kan alleen maar googlen op spaceport.sys en dat geeft deze mogelijke oorzaken

Oorzaken van Spaceport.sys Fouten

Spaceport.sys blauwe scherm kunnen worden veroorzaakt door een verscheidenheid van hardware, firmware, stuurprogramma's, of softwareproblemen. Deze kunnen worden gekoppeld aan Windows 8 Pro software of Microsoft hardware, maar het is niet noodzakelijk het geval.

Meer specifiek, deze spaceport.sys fouten kunnen veroorzakt worden door:

Verkeerd geconfigureerde, oude of beschadigde Windows 8 Pro apparaatstuurprogramma's. (komt veel voor)
Corruptie in Windows-register van een recente spaceport.sys-gerelateerde software verandering (installeren of verwijderen).
Virus of malware infectie dat het spaceport.sys bestand heeft beschadigd of gerelateerde Windows 8 Pro programmabestanden.
Hardwareconflict na het installeren van nieuwe Microsoft hardware, of hardware gerelateerd aan spaceport.sys.
Beschadigde of verwijderde systeembestanden nadat u software of stuurprogramma's hebt geïnstalleerd gerelateerd aan Windows 8 Pro.
spaceport.sys blauw scherm veroorzaakt door een beschadigde harde schijf.
spaceport.sys STOP-fout als gevolg van geheugen (RAM) corruptie.

http://www.solvusoft.com/...dows-8-pro/spaceport-sys/

Ik weet ook niet in hoeverre dit relevant is voor jouw geval omdat het hier blijkt te gaan over een probleem bij de upgrade van win8.1 pro, en het is een advertentiesite voor een of ander regcleaner programma, maar uit de info haal ik dat spaceport.sys niet uitsluitend met een corrupte harde schijf te maken heeft.

[begintmeta]

Kan wellicht ook een softwareprobleem zijn misschien? even googelen levert vanalles op (bijvoorbeeld Power Off increases 'unexpected power loss count' (smart flag AE) - ssd at risk of being corrupted of X220 potentially killing SSD during each shutdown, sleep and hibernate

[Thralas]

Reepje schreef op vrijdag 11 september 2015 @ 09:51:
Daarnaast vind ik de stelling dat de Kingston v100+ een prut SSD is overtrokken. Inderdaad hij heeft geen stroomverliesbescherming, maar deze SSD heeft geen slechte track record. 2011 was deze razend populair hier op Tweakers, en toen heb ik er ook eentje gekocht. Dat ding is niet kapot te krijgen (bij mij). Je hoort ook weinig klachten over deze SSD. Kijk als we het nu over de OCZ vertex/agility familie hebben, daar valt misschien wel 50% van uit. Dan zou ik de SSD ook verdenken.

Jij verdient een standbeeld. Exact dit.

offtopic:
Excuses voor de rant. Komt 'ie:

Sorry CiPHER, in het algemeen lijk je ontzettend veel over storage te weten, maar dat eeuwige gemijmer over power loss protection vind ik persoonlijk overtrokken, In jouw ogen is alles zonder die mythische power loss protection waardeloos, terwijl er duizend-en-een zaken zijn die misschien wel belangrijker zijn.

Ja, er zijn 'beruchte' SSD series die tegen corruptie aanlopen en er zodoende compleet de brui aan kunnen geven, maar dat kan nog talloze andere oorzaken hebben. Who knows, voor de eindgebruiker is een SSD gewoon storage die werkt of niet; RMA-cijfers zijn interessant, over de technologie die daaraan bijdraagt is weinig te zeggen door eindgebruikers (de SSD firmware is immers een black box, ook voor jou).

EDIT: voor de duidelijkheid, het punt dat ik probeer te maken: de interne werking van SSDs is dermate intransparant voor ons als eindgebruikers, dat je onmogelijk een SSD zo stellig kunt afschrijven op basis van louter technische details.

Je hele verhaal is ongefundeerd (die SSD heeft geen slecht track record zoals Reepje aangeeft), en hier totaal irrelevant. Doe ik even een onderbouwde analyse:

Gropah schreef op donderdag 10 september 2015 @ 21:04:
Hierbij staan dus zowel ntoskrnl.exe als spaceport.sys roodgekleurd, waardoor ik denk af te lezen dat dat de schuldigen zijn. Spaceport heb ik eerder benoemd, maar ntoskrnl.exe niet. Wat ik hier over heb kunnen vinden is dat het proces de planner is van verschillende resources inclusief cache, geheugen en de kernel.

ntoskrnl.exe is niet zomaar een scheduler, het is de kernel

Bluescreens attribueren aan het eerste de beste Microsoftcomponent is een veelgemaakte fout. Terwijl Microsoft z'n zaakjes meestal wel op orde heeft, maar er simpelweg sprake is van stukke hardware of een brakke driver. Dat laatste in jouw geval.

De BSOD wijst allereerst echt naar een driver fault. Uitleg van parameter 1:

A driver has attempted to complete a request when no such outstanding request is pending.

Ref: Bug Check 0xA0: INTERNAL_POWER_ERROR

Twee; Microsoft kent het miniport drivermodel, waarbij een vendor driver sterk verweven is met een stuk Microsoftcode. Een vendor fuckup betrekt dus logischerwijs ook de port driver van MS bij een crash (dat zie je hier).

Drie: de twee storagedrivers die je aanhaalt zijn beide port drivers; gecomineerd met de eerdere aanname over MS-drivers mist er hier nog een vendor driver. In TS' geval waarschijnlijk een AMD storage miniport driver. Meer daarover later.

Het zou kunnen dat dit gelinked is aan de kapotte hardeschijf, maar dus ook aan het RAM. Verder staat er nog mcupdate_AuthenticAMD.dll tussen. Helaas kon ik hier niet extreem veel over vinden. Ik kwam op 2 dingen uit: iets met McAffee, de virusscanner, die ik niet gebruik en AMD drivers.

Lijkt me eerder een CPU microcode update library van je vrienden uit Redmond.

Wie-o-wie kan mij helpen/een zetje in de goede richting geven?

Ja. Welke entries zijn er nog meer rood gehighlight, behalve de MS-componenten? Hoe oud is de desbetreffende driver? Is er ergens een update te halen?

Ik doel hier specifiek op de AMD storage miniport driver. Die zou je hoogstwaarschijnlijk ook in de call stack verwachten.

Of post eens !analyze -v output. NEWS Instant Online Crash Dump Analyzer.

Mogelijke spoiler: je specifieke bug check (parameters!) geeft een exacte hit op een topic waar iemand tegen dezelfde BSOD aanloopt en vervolgens constateert dat z'n AMD storage driver uit 2009 stamt.

[ Voor 7% gewijzigd door Thralas op 11-09-2015 21:37 ]

[begintmeta]

offtopic:
Hmm, dus in bijvoorbeeld dit geval zou het inderdaad de driver kunnen zijn geweest?

[Gropah]

Dank voor je lange antwoord en mijn excuses voor het lange wachten.

Thralas schreef op vrijdag 11 september 2015 @ 21:19:
[...]
Welke entries zijn er nog meer rood gehighlight, behalve de MS-componenten? Hoe oud is de desbetreffende driver? Is er ergens een update te halen?

Er zijn geen andere entries die rood gehighlight zijn

Ik doel hier specifiek op de AMD storage miniport driver. Die zou je hoogstwaarschijnlijk ook in de call stack verwachten.

Of post eens !analyze -v output. NEWS Instant Online Crash Dump Analyzer.

Hierbij de output van !analyze -v

code:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

INTERNAL_POWER_ERROR (a0)
The power policy manager experienced a fatal error.
Arguments:
Arg1: 0000000000000613, A driver has attempted to complete a request when no such
    outstanding request is pending.
Arg2: ffffe0018f3c7ac0, POP_FX_DEVICE device
Arg3: 0000000000000000, Component index
Arg4: 0000000000000001, Report device powered on

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


SYSTEM_SKU:  To Be Filled By O.E.M.

SYSTEM_VERSION:  To Be Filled By O.E.M.

BIOS_DATE:  12/06/2010

BASEBOARD_PRODUCT:  880GMH/USB3.

BASEBOARD_VERSION:                        

BUGCHECK_P1: 613

BUGCHECK_P2: ffffe0018f3c7ac0

BUGCHECK_P3: 0

BUGCHECK_P4: 1

BUGCHECK_STR:  0xa0_613

CPU_COUNT: 6

CPU_MHZ: af0

CPU_VENDOR:  AuthenticAMD

CPU_FAMILY: 10

CPU_MODEL: a

CPU_STEPPING: 0

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

LAST_CONTROL_TRANSFER:  from fffff80275833ea4 to fffff8027575e240

STACK_COMMAND:  kb

FOLLOWUP_IP: 
amdxata+16be
fffff800`b0bc16be ??              ???

SYMBOL_STACK_INDEX:  b

SYMBOL_NAME:  amdxata+16be

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: amdxata

IMAGE_NAME:  amdxata.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  49f79247

BUCKET_ID_FUNC_OFFSET:  16be

FAILURE_BUCKET_ID:  0xa0_613_amdxata!Unknown_Function

BUCKET_ID:  0xa0_613_amdxata!Unknown_Function

PRIMARY_PROBLEM_CLASS:  0xa0_613_amdxata!Unknown_Function

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0xa0_613_amdxata!unknown_function

FAILURE_ID_HASH:  {152bdf2a-1598-635f-2efa-0c671f033ca2}

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

Nav je post (en de output hierboven) ben ik maar eens gaan kijken of ik voor de AMD controller drivers kon vinden. Windows zelf kon via de device manager geen nieuwere driver vinden. Vervolgens heb ik de autodetect drivers van AMD gedownload. Hierna maar de chipset drivers voor mijn pc gedownload, gezien die ook RAID drivers etc bevat. Dit ging probleemloos, dus ik hoop dat het nu klaar is

[Thralas]

Ik zie hier geen stacktrace, maar wel duidelijk dat 'ie in amdxata.sys is gecrashed.

Handig als je had kunnen dubbelchecken dat hij inderdaad een update heeft gehad (module timestamp in BlueScreenView), maar het zou inderdaad logisch zijn als hij bij de chipsetdrivers zit.

[Gropah]

Nou, het heeft helaas niet mogen baten... De resultaten van BlueScreenView voor de nieuwste crash:


Opvallend is dat amdxata.sys nu voor het eerst word genoemd bij deze crash

Ik heb even de oude logs doorzocht en daarbij had amdxata dezelfde timestamp als bij deze nieuwe, dus het lijkt er op dat er geen update is door gevoerd. Het rare is dat ik geen andere/losse installer kan vinden van de storage driver. Ik kan alleen de catalyst chipset installer vinden die ik al gedraaid heb. Mag ik hieruit concluderen dat ik de nieuwste versie te pakken heb/dat er geen losse driver update voor is?

[Verwijderd]

Thralas schreef op vrijdag 11 september 2015 @ 21:19:
Sorry CiPHER, in het algemeen lijk je ontzettend veel over storage te weten, maar dat eeuwige gemijmer over power loss protection vind ik persoonlijk overtrokken, In jouw ogen is alles zonder die mythische power loss protection waardeloos, terwijl er duizend-en-een zaken zijn die misschien wel belangrijker zijn.

Wat is dan belangrijker volgens jou? Iedereen (nouja 99,999% van de consumenten) staart zich blind op prestaties en prijs. Terwijl daar nu juist niet zoveel verschil zit tussen de beschikbare SSDs. Op het gebied van betrouwbaarheid juist weer wel - dus logisch dat je juist op dit gebied een SSD zou selecteren.

Ja, er zijn 'beruchte' SSD series die tegen corruptie aanlopen en er zodoende compleet de brui aan kunnen geven, maar dat kan nog talloze andere oorzaken hebben. Who knows, voor de eindgebruiker is een SSD gewoon storage die werkt of niet; RMA-cijfers zijn interessant, over de technologie die daaraan bijdraagt is weinig te zeggen door eindgebruikers (de SSD firmware is immers een black box, ook voor jou).

EDIT: voor de duidelijkheid, het punt dat ik probeer te maken: de interne werking van SSDs is dermate intransparant voor ons als eindgebruikers, dat je onmogelijk een SSD zo stellig kunt afschrijven op basis van louter technische details.

Ehm nou... NAND flash heeft gewoon inherent nadelen. Hardeschijven hebben dit probleem niet; die corrumperen niet omdat ze sowieso geen mapping table hebben. SSDs zijn zeer complexe opslagapparaten daarom kan er ook zoveel mis gaan. Zonder de mapping tables weet de SSD sowieso niet wat hij heeft opgeslagen. Iedere SSD reageert hier weer anders op. Zo zullen Intel SSDs met Intel controller een niet-beschrijfbare disk van 8 megabyte presenteren bijvoorbeeld. Andere SSDs worden bijvoorbeeld helemaal niet meer herkend door BIOS en operating system. Anderen worden weer zichbaar na een half uurtje van stroom verzien te zijn, waarbij de mapping tables weer consistent met de data gemaakt worden.

Jouw argument klopt tot op zekere hoogte dat wij - inclusief ikzelf - niet over uitvoerige kennis beschikken van de exacte implementatie van elke SSD. Maar dat neemt niet weg dat SSDs inherent onbetrouwbaar zijn als er iets met hun fragiele mapping tables gebeurt, om van firmware bugs nog maar niet te spreken.

Dat betekent ook automatisch dat alle SSDs die niet beschermd zijn met zowel RAID5 bitcorrectie als met power-safe capacitors, per definitie onbetrouwbare SSDs zijn. Ook al is de kans zeer gering - wat kan verschillen per implementatie - blijft er een window of opportunity bestaan waarbij de SSD corrupt kan raken. Iedere Unexpected Power-Loss blijft gokken in het casino of je SSD er ongeschonden uit komt.

Kan prima zijn dat de Kingston het beter doet dan andere onbeschermde SSDs, maar toch vind ik het niet kunnen dat er überhaupt een window of opportunity bestaat. Je wilt gewoon betrouwbare techniek, al helemaal bij zoiets essentiëels als een opslagapparaat. Stel je hebt vage problemen zoals in deze thread, dan kun je je SSD niet uitsluiten als factor. En nog erger: je zal achteraf nooit kunnen concluderen of de SSD nu de oorzaak is geweest. Dat vind ik simpelweg onacceptabel.

Daarom mijn advies om enkel betrouwbare - dus beveiligde - SSDs te gebruiken, voor dat ene tientje extra heb je gewoon veel meer zekerheid. En ja ook een Crucial MX200 kan stuk, maar niet op de manier waarop andere SSDs corrumperen. Want die blijven gewoon werken alleen zeer zelden corruptie vertonen. Al is dat eens per jaar, is dat nog veels teveel. Dat is althans mijn mening.

Edit: overigens, afgezien van bovenstaande, is het zeer goed mogelijk dat in dit geval de SSD er niets mee te maken heeft. In dat opzicht kan ik je reactie wel begrijpen dat ik altijd de SSD verdacht maak. Maar dat is juist het punt. Ik heb zelf een hekel aan 'gekut' met computers, vooral als het om vage klachten gaat. Dat kost je zoveel tijd en moeite en frustratie. Als dat ene tientje extra nou heel veel potentiële kopzorgen wegneemt, is dat het toch gewoon driedubbel waard?

[ Voor 6% gewijzigd door Verwijderd op 13-09-2015 23:09 ]

[dcm360]

Verwijderd schreef op zondag 13 september 2015 @ 22:56:
[...]

Wat is dan belangrijker volgens jou? Iedereen (nouja 99,999% van de consumenten) staart zich blind op prestaties en prijs. Terwijl daar nu juist niet zoveel verschil zit tussen de beschikbare SSDs. Op het gebied van betrouwbaarheid juist weer wel - dus logisch dat je juist op dit gebied een SSD zou selecteren.

Niet een reactie op mij, ik weet het, maar ik zou het eerder zoeken in een OS dat de stabiliteit van een alpha-versie heeft. Goede hardware heb je niets aan met brakke software.

[Verwijderd]

Ik wil prima erkennen dat mijn reactie in dit topic niet zoveel relevantie zou kunnen hebben met het concrete probleem. Het is echter het enige dat ik heb toe te voegen.

[Renault]

/offtopic:
Kleine nuancering:
We zitten hier in het storage topic: iedereen die ergens tegenaan loopt meldt zich hier en je ziet vaak/telkens dezelfde verschijnselen met een duidelijke (en te voorkomen) oorzaak-relatie gevolg.
Alle SSD-gebruikers die nergens last van hebben vinden dit onzin: ze hebben er immers geen last van en vinden veel van deze detailinfo geleuter.
Beide standpunten hebben hun rechtvaardiging. De bron van de ellende zit in voorschtijdende technische ontwikkeling en (helaas) marketing (in de vorm van onrijpe / buggy hardware op de markt brengen).
Toch is dat ook weer een deel van het bestaansrecht van fora als deze.
/ontopic