How to analysis a BSOD?

[hack3rcon]

Hello,
I used the WinDbg to analysis a BSOD file. I open the dump file:

Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..............................................................
................................................................
...............................................................
Loading User Symbols
Loading unloaded module list
...................

************* Symbol Loading Error Summary **************
Module name            Error
ntoskrnl               The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
For analysis of this file, run !analyze -v
*** WARNING: Unable to verify timestamp for watchdog.sys

Then, I ran the !analyze -v command and result is:

...
LAST_CONTROL_TRANSFER:  from fffff80563e93ad0 to fffff80555dfcd70

STACK_TEXT:
fffff805`595f3738 fffff805`63e93ad0 : 00000000`00000119 00000000`00000005 ffffc40c`6d90f000 ffffc40c`6df68520 : nt+0x3fcd70
fffff805`595f3740 00000000`00000119 : 00000000`00000005 ffffc40c`6d90f000 ffffc40c`6df68520 00000000`00011668 : watchdog+0x3ad0
fffff805`595f3748 00000000`00000005 : ffffc40c`6d90f000 ffffc40c`6df68520 00000000`00011668 00000000`00000000 : 0x119
fffff805`595f3750 ffffc40c`6d90f000 : ffffc40c`6df68520 00000000`00011668 00000000`00000000 ffffc40c`72f45590 : 0x5
fffff805`595f3758 ffffc40c`6df68520 : 00000000`00011668 00000000`00000000 ffffc40c`72f45590 fffff805`70fe02dd : 0xffffc40c`6d90f000
fffff805`595f3760 00000000`00011668 : 00000000`00000000 ffffc40c`72f45590 fffff805`70fe02dd ffffc40c`72f42000 : 0xffffc40c`6df68520
fffff805`595f3768 00000000`00000000 : ffffc40c`72f45590 fffff805`70fe02dd ffffc40c`72f42000 ffffc40c`6d90f000 : 0x11668


THREAD_SHA1_HASH_MOD_FUNC:  1ffa882a03d0bff665b5475db9543d1550319fa0

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  a56c5ea5e76595c5742709446528d8159b25ce45

THREAD_SHA1_HASH_MOD:  1ffa882a03d0bff665b5475db9543d1550319fa0

FOLLOWUP_IP:
watchdog+3ad0
fffff805`63e93ad0 cc              int     3

FAULT_INSTR_CODE:  cccccccc

SYMBOL_STACK_INDEX:  1

FOLLOWUP_NAME:  MachineOwner

STACK_COMMAND:  .thread ; .cxr ; kb

BUGCHECK_STR:  CFEE68AF

EXCEPTION_CODE: (NTSTATUS) 0xcfee68af - <Unable to get error code text>

EXCEPTION_CODE_STR:  CFEE68AF

EXCEPTION_STR:  WRONG_SYMBOLS

PROCESS_NAME:  ntoskrnl.wrong.symbols.exe

IMAGE_NAME:  ntoskrnl.wrong.symbols.exe

MODULE_NAME: nt_wrong_symbols

SYMBOL_NAME:  nt_wrong_symbols!CFEE68AF1046000

BUCKET_ID:  WRONG_SYMBOLS_X64_19041.1.amd64fre.vb_release.191206-1406_TIMESTAMP_800718-060119

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS_X64_19041.1.amd64fre.vb_release.191206-1406_TIMESTAMP_800718-060119

PRIMARY_PROBLEM_CLASS:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  WRONG_SYMBOLS_X64_19041.1.amd64fre.vb_release.191206-1406_TIMESTAMP_800718-060119_CFEE68AF_nt_wrong_symbols!CFEE68AF1046000

TARGET_TIME:  2023-09-18T22:48:43.000Z

OSBUILD:  19041

OSSERVICEPACK:  0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID:  0

OSBUILD_TIMESTAMP:  unknown_date

BUILDDATESTAMP_STR:  191206-1406

BUILDLAB_STR:  vb_release

BUILDOSVER_STR:  10.0.19041.1.amd64fre.vb_release.191206-1406

ANALYSIS_SESSION_ELAPSED_TIME:  853f

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:wrong_symbols_x64_19041.1.amd64fre.vb_release.191206-1406_timestamp_800718-060119_cfee68af_nt_wrong_symbols!cfee68af1046000

FAILURE_ID_HASH:  {38503203-cc04-2f43-4fa0-a35d5ce214c9}

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

Then, I did:

0: kd> lmvm nt_wrong_symbols
Browse full module list
start             end                 module name
0: kd>

No result!
What is the next step?

Thank you.

 

[ubuysa]

I refer you to the answer I gave you here: Question - How to analysis a BSOD?.

 

[hack3rcon]

I refer you to the answer I gave you here: Question - How to analysis a BSOD?.

Hello,
Thank you so much for your reply.
I think sharing a little experience is enough to solve this problem. It takes a lot of time to learn this professionally.

 

[ubuysa]

I appreciate that you want to learn, and I can see how you'd think that 'sharing a little experience' is enough to get you started. The problem is that you don't appreciate how steep (or how high) the learning curve really is. Despite the title I have here I'm no expert, compared to the real experts on here I'm just average, but I've been working with operating system internals all my working life, and with Windows internals for decades. And you need to understand, at least at a high level, how Windows works internally because analysing a dump is often about following the function calls to determine what went wrong.

As well as enrolling in the Sysnative BSOD Academy you might want to get a copy of part 1 of the Windows Internals book. Much of what's in there is important to know when kernel debugging. It will help you get started in debugging too, the authors use WinDbg in the book.

 

[hack3rcon]

I appreciate that you want to learn, and I can see how you'd think that 'sharing a little experience' is enough to get you started. The problem is that you don't appreciate how steep (or how high) the learning curve really is. Despite the title I have here I'm no expert, compared to the real experts on here I'm just average, but I've been working with operating system internals all my working life, and with Windows internals for decades. And you need to understand, at least at a high level, how Windows works internally because analysing a dump is often about following the function calls to determine what went wrong.

As well as enrolling in the Sysnative BSOD Academy you might want to get a copy of part 1 of the Windows Internals book. Much of what's in there is important to know when kernel debugging. It will help you get started in debugging too, the authors use WinDbg in the book.

Thanks again.
Suppose your car breaks down and you need help. You can ask for help from someone who has that problem, or you can learn to be a mechanic and fix the car after a few years. which job do you do?
Now I have the same situation and I don't have the opportunity to become an expert in this field and read a 784-page book.

 

[ubuysa]

There is no short cut sadly. I've given you my best advice.

 

[axe0]

Sadly, the in this case relevant information has been snipped out. All we can tell is that your setup is not configured properly. Note that when your setup is configured properly, it may take a few attempts before all symbols are downloaded, that's my experience from when I started.

Ubuysa is spot on, it is a steep learning process to get to a point where you decently understand what you see with the wide variety of possible crashes that each have different reasons for being triggered.

We could potentially point out where to look and how to do it, if all info is provided such as the dump itself, but ideally we'd look into it ourselves first and describe the process for you to learn. Keep in mind that most of the process probably won't be applicable to any future crash (hopefully none) if they're different from the one you posted. I'd also like to point out that we have an extensive library of 'how to' for many different crashes at BSOD Academy (Public), you might be able to use that too.