We are looking for the cause of BSOD in automatic mode.
In continuation of the article TijAY .
Recently, an interesting story emerged - on the victim’s computer, the BSOD glowed with enviable regularity. To his credit, the car went into reboot faster than it was possible to read the STOP code. There is only one way out: analyze memory dumps.
Considering that these dumps had accumulated a very large number, it seemed to me too tedious to open each debugger.
The cmd-script of Alexey Sukhovey “Kernel Debugger Front End” was called for help (for example, here ). It requires the Windows Debugging Tools installed and it works like this:
')
Well, in order to make things easier for himself, a simple .bat-nick was written:
It would be better if you call it with the parameter "> kdfe_output.txt", then it will be enough to wait for the script to run and look at the kdfe_output.txt file in its folder, where its results will be recorded.
Successful repair, and may the BSOD be with you! :)
PS C: \ Windows turned out to be reasonably replaced with% SystemRoot%, thanks ryazantsev ; The key / d was added to cd, thanks asm0dey
PPS Regarding the results of the KDFE itself - you must carefully read the output of the script: the reason is written possible (“ Probably caused by”), so in case of broken memory, sometimes this chip can be buggy, and in any case you will have to manually look at the dumps in WinDbg.
Recently, an interesting story emerged - on the victim’s computer, the BSOD glowed with enviable regularity. To his credit, the car went into reboot faster than it was possible to read the STOP code. There is only one way out: analyze memory dumps.
Considering that these dumps had accumulated a very large number, it seemed to me too tedious to open each debugger.
The cmd-script of Alexey Sukhovey “Kernel Debugger Front End” was called for help (for example, here ). It requires the Windows Debugging Tools installed and it works like this:
')
Well, in order to make things easier for himself, a simple .bat-nick was written:
cd / d% SystemRoot% \ Minidump
for %% A in (* .dmp) do "C: \ path \ to \ script \ kdfe" %% A
It would be better if you call it with the parameter "> kdfe_output.txt", then it will be enough to wait for the script to run and look at the kdfe_output.txt file in its folder, where its results will be recorded.
Successful repair, and may the BSOD be with you! :)
PS C: \ Windows turned out to be reasonably replaced with% SystemRoot%, thanks ryazantsev ; The key / d was added to cd, thanks asm0dey
PPS Regarding the results of the KDFE itself - you must carefully read the output of the script: the reason is written possible (“ Probably caused by”), so in case of broken memory, sometimes this chip can be buggy, and in any case you will have to manually look at the dumps in WinDbg.
Source: https://habr.com/ru/post/60980/
All Articles