liver, на 09 February 2012 - 07:12, каза:
В ръководството се препоръчва да се конфигурира създаването на 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-ът) като височина, скорост и други. Да, понякога само тази информация е достатъчна (в редки случаи), но много често се налага да разполагаш и с двигателите, авиониката, части от фюзелажа и други съществени неща, които пряко касаят проблема, за да кажеш наистина какво се е объркало.
liver, на 09 February 2012 - 15:59, каза:
И аз така си мисля, но логиката ми казва друго. Не може в един от най-големите форуми в света да пишат празни приказки. Говорим за форум, който само в раздела Crashes and Debuging има 160 000+ мнения, разбираш ли за какво става въпрос? На час се постват между 5-10 нови теми, само в този раздел. И за да помогнат при BSOD, изискват small memory dump
Не виждам каква е връзката между големината на даден сайт и качеството на потребителите и респективно коментарите в него. Това са две съвсем различни неща, които нямат никаква връзка, още повече, че това е доста специфична материя и не е за всеки (особено дълбокия анализ), но друг е въпросът, че всеки се пише "специалист" в днешно време. Същото се отнася и за програмирането и как в момента всеки втори се пише "програмист" нищо, че ако го питаш какво е стек примерно ще те гледа умно, а да не говорим за нещо сложно. С две думи това не е аргумент. Ако не ми вярваш на мен хвани отвори дебелите книги виж какво пише там, осмисли го добре и пак заповядай да дискутираме.
7
hdtune.png 51.39К
3 Брой изтегляния
wininit.txt 2.77К
1 Брой изтегляния
