Статия: Сините екрани (BSoDs)

[Гост newnickname]

п.п да задам въпроса по този начин - какво липсва като информация в kеrnel memory dump-a, че искат small memory dump.

 

Да ти кажа честно отскоро анализирам dump-файлове и не знам защо искат по-бедния на информация файл от двата (kernel и small).

Иначе кой какво записва като инфо можеш да научиш тук

[liver]

Благодаря. Ще разгледам и там.

[Aquarius]

В ръководството се препоръчва да се конфигурира създаването на Kernel Memory Dump. В англоезичният форум на 7-цата ми препоръчват друго - small memory dump. Чудя се, кое е вярното?

 

 

п.п

http://sourcedaddy.c...dump-files.html а в тази статия се споменава, че при възникване на stop грешка, windows винаги създава small memory dump, дори да сме задали kernel memory dump или complete memory dump.

 

Всеки човек, който е наистина добре запознат с материята, включително какво точно представлява Мemory Dump файлът, как се записва и какво има вътре пределно ясно знае, че има само един разумен вариант и това е Kernel Memory Dump. Всичко друго са свободни съчинения на хора, които са чел тук там, но нямат реална представа за нещата. Ще кажа съвсем кратичко защо това е така, за да няма повече въпросителни относно този въпрос.

Идеята с две думи е следната: Small Memory Dump-ът, който се създава по дифолт само при Windows XP (още от Vista дифолтната настройка е Kernel) съдържа крайно ограничена информация в рамките на килобайти до около 1MB, което на практика означава, че имаш само стоп кода и параметрите, списъкът със заредените драйвери, т.нар. EPROCESS и ETHREAD, които представляват структури от данни, описващи текущия процес и нишка и kernel стека на нишката, причинила срива. Има и още няколко дребни нещица, но това е основното.

Другата крайност Complete Memory Dump, който съдържа цялата физическа памет (RAM) по време на срива. Това е доста глупаво, защото вътре има голямо количество код, изпълняващ се в потребителски режим (user mode), а на практика само и единствено код, който се изпълнява в системен режим (kernel mode) може да причини син екран. Това води до един огромен размер (особено при новите машини с много RAM), който е адски непрактичен и освен всичко друго изисква файл за странициране на виртуална памет (Pagefile.sys) голям колкото RAM-та + 1MB, за да може да се създаде успешно, което е абсолютен овъркил за машина с 8GB RAM примерно където на практика няма нужда изобщо от странициране на памет. А да не говорим за 12GB или 16GB RAM, което не е нещо рядко срещано в днешно време с тея цени на паметите дори при мобилните компютри. Така че тая опция е безумна с две думи.

И идваме на великия въпрос защо съм препоръчал Kernel Memory Dump - защото предлага най-добър баланс между обем и полезна информация. Както казва и името му става въпрос за това, че се записват САМО страници, достъпвани от системен режим (kernel mode), които са се намирали в паметта по време на срива. Съответно в този тип дъмп няма страници, които да принадлежат на потребителски процеси за разлика от Complete-а. Това е и причината да има значително по-малък размер, който варира от система до система в зависимост от количество системна памет, алокирана от драйверите и операционната система в момента на срива. Тъй като всяка система съдържа различни драйвери и различните драйвери имат различно потребление на системна памет размерът няма как да се предвиди. Moже да е 50MB, може да е и 300-500MB. Аз лично при повечето системи наблюдавам размери от порядъка на 200-500MB, но както казах няма как да се каже предварително, освен ако не се генерира тестов BSOD. С две думи тъй като Kernel Memory Dump-ът съдържа цялата системна памет той има същото ниво на полезност спрямо Complete Memory Dump-а с тази разлика, че не съдържа ненужните потребителски данни и код, които нямат никаква връзка със синия екран, а само увеличават многократно размера.

Това, че системата създава И minidump независимо дали е конфигурирана за Kernel или Full е вярно. Дори е възможно ако се отвори Kernel дъмп в WinDbg с командата .dump/m да се извлече "страхотният" minidump. Реално единственият плюс на minidump-a e неговият размер, нищо повече. При една заплетена ситуация по анализ с minidump си все едно да разследваш инцидент със самолет, но да имаш достъп само до "черните" кутии (които всъщност са оранжеви) т.е. едната, която записва последните 30 минути от разговорите в пилотската кабина (Cockpit Voice Recorder-ът) и другата, която записва данни за полета (Flight Data Recorder-ът) като височина, скорост и други. Да, понякога само тази информация е достатъчна (в редки случаи), но много често се налага да разполагаш и с двигателите, авиониката, части от фюзелажа и други съществени неща, които пряко касаят проблема, за да кажеш наистина какво се е объркало.

 

И аз така си мисля, но логиката ми казва друго. Не може в един от най-големите форуми в света да пишат празни приказки. Говорим за форум, който само в раздела Crashes and Debuging има 160 000+ мнения, разбираш ли за какво става въпрос? На час се постват между 5-10 нови теми, само в този раздел. И за да помогнат при BSOD, изискват small memory dump

 

Не виждам каква е връзката между големината на даден сайт и качеството на потребителите и респективно коментарите в него. Това са две съвсем различни неща, които нямат никаква връзка, още повече, че това е доста специфична материя и не е за всеки (особено дълбокия анализ), но друг е въпросът, че всеки се пише "специалист" в днешно време. Същото се отнася и за програмирането и как в момента всеки втори се пише "програмист" нищо, че ако го питаш какво е стек примерно ще те гледа умно, а да не говорим за нещо сложно. С две думи това не е аргумент. Ако не ми вярваш на мен хвани отвори дебелите книги виж какво пише там, осмисли го добре и пак заповядай да дискутираме.

[liver]

Благодаря за изчерпателното обяснение. Не съм казал, че не вярвам на написаното тук. Иначе щях ли да посещавам форума? Просто ме озадачи това, че има разминаване. Но сигурно си има обяснение. Както и да е.

Възстанових с Recuva, kernel memory dump файла. Възможен ли е анализ на файла? И ако е, да го кача ли тук да го анализирате? Благодаря.

 

п.п файла е 448мб.

[Aquarius]

тествах ги и няма грешки също така тествах и процесора но там работят двете ядра на 100% а другите две не се включват много видях ги от Task manager качвам ти снимка а за видео картата тествах с FurMark но неразбрах дали работи добре никаде не оишеше за грешки можели малко разеснение как да разбера дали работи добре,ако се сещаш и нещо друго да проверя казвай и благодаря ти за бързия отговор

 

Паметта се тества няколко часа (най-добре цяла нощ) с Memtest. След това за комбиниран тест с Orthos на процесор, памет и чипсет се пускат две инстанции (за да натовариш 4-те ядра) и се оставя минимум 2-3 часа на Blend, а не 5 минути. Също не е лошо да пуснеш един Power Supply тест с OCCT за 1 час.

 

Благодаря за изчерпателното обяснение. Не съм казал, че не вярвам на написаното тук. Иначе щях ли да посещавам форума? Просто ме озадачи това, че има разминаване. Но сигурно си има обяснение. Както и да е.

Възстанових с Recuva, kernel memory dump файла. Възможен ли е анализ на файла? И ако е, да го кача ли тук да го анализирате? Благодаря.

 

п.п файла е 448мб.

 

Архивирай файла, качи го някъде и дай линк да го погледнем. Виждам, че имаш отделна тема за BSOD, която касае Win32k.sys. Въпросният драйвер имплементира частта на Windows подсистемата (Win32), работеща в системен режим (kernel mode). Както съм писал и преди Win32k.sys е изключително съществен компонент, който съдържа мениджъра на прозорците, графичният интерфейс за устройства, отделно получава вход от клавиатура / мишка и други устройства. Препоръчително е да си тестваш хардуера чрез инструментите и начините, които съм описал в темата.

[liver]

Kernel memory dump file http://dox.bg/files/dw?a=8399c538dd . Тествах с hd tune, furmark, superpi mode 1.5. Останалите (memtest и prime95) по-късно или утре. Системата не крашна на нито един от тестовете, нито изкара грешки, въпреки, че furmark-a го пуснах два пъти по 15 мин. + едноминутния бенчмарк. Естествено, следях температурата постоянно. Снимки:

 

 

п.п напреженията (различават се от hwmonitor, но винаги е било така) и температурите в покой от AIDA :

 

 

процесор Е8400

видеокарта - 8800gt 512mb Asus

захранване - Bluestorm II 500W

хардиск - Hitachi HDP725032GLA320

памети - 2х1 gb DDR2 super T cl5 800mhz и 2x1gb kingston 2x1gb DDR2 800 mhz

дънна платка - Gygabite p35-ds3r rev. 2.0

[liver]

prime95 blind test - 5 часа Memtest - 9 часа

 

 

Извинявам се за последователните постове.

[Aquarius]

Дискът се тества със специализирания инструмент от производителя в случая Hitachi DFT. HDTune намира друго приложение и затова и не съм го написал в секцията за тестване на HDD. Иначе другите тестове изглеждат ОК като цяло. Можеш ли да дадеш информация при какви обстоятелства се получава въпросния син екран?

 

P.S.: Напреженията не се гледат със софтуер, а с мултимер.

[liver]

Синият екран възникна, докато пред компютъра нямаше никой - при пълен покой и никакви задачи на заден план. Оставих го включен, като настроих в power settings, монитора да се изключи след минута. След час отивам...и син екран. Колко време след това е възникнал, не знам. Интересно, че докато е под товар, особено последните дни се играе основно Modern Warfare 3 по 3-6 часа в мрежа, няма проблем. Дори и сега тестовете - memtest, prime95, futmark, check disk...почти 20 часа без прекъсване е под товар и няма проблеми. Поне да изкара някаква грешка, да знам от какво е. А то - нищо. Всъщност това е първият син екран, откакто преинсталирах преди 5-6 месеца. Дори не се сещам, преди това да съм виждал син екран под 7-цата.

 

Тетсвах с hd tune, защото нямах cd под ръка, а теста Hitachi DFT изисква бутващо cd, ако не греша. Както и за напреженията - нямам мултимер.

 

Пуснах и chеck disk на дяловете. Това са резултатите, ако вършат работа: wininit.txtwininit2.txt

 

п.п има ли нещо притеснително? Освен това, chеck disk не засича ли проблеми, свързани с хардиска?

 

п.п 2 при първа възможност, ще тествам и с инструмента на Hitachi.

[Night_Raven]

ето и Dump файла и с analyze -v

Без самия файл е трудно да се каже.

[valyo_93]

къде да намеря файла които искаш

[Night_Raven]

C:\WINDOWS.

[valyo_93]

как да го кача то е 251 мб и с какво се отваря подобен файл

[Night_Raven]

Архивираш и качваш на някой файлов хостинг. Файлът се отваря с Debugging Tools for Windows.

[valyo_93]

Изтегли го от тук

 

http://www27.zippyshare.com/v/85098806/file.html