Most Notable BSOD Kernel Dump Analysis posts

[Patrick]

Probably a garbage pirated version they all seem to get then.

 

[jcgriff2]

​

RE: Sysnative Forums BSOD Thread - https://www.sysnative.com/forums/bs...lling-zonealarm-windows-7-x86.html#post107314

Sometimes, BSOD analysis is done in "visual steps" with the Windbg command + resulting output shown in code boxes, step-by-step as was done in this thread.

To try and help you follow such steps in BSOD threads here at Sysnative Forums, I thought it would be helpful to provide additional details and information as to what these steps are and where the parms come from.

I can think of few things more frustrating than knowing what a Windbg command does, how it can help me in finding an answer/solution, but not being able to figure out where the memory address used in conjunction with the Windbg command came from.

When I read this thread earlier and came upon Patrick's post, I could follow all with relative ease, except that the memory address in step #4 (a.k.a., the "command parameter") eluded me for a bit until I looked closer at the output of #3. Once the output of #3 is reviewed, the origin of #4's "command parameter" becomes immediately evident.

Just to go over it quickly:

kd> command for #4 -

[COLOR=#565656]2: kd> [/COLOR][B]dt nt!_MODE c9dd6208[/B]

So... I'm on the hunt for memory address 0xc9dd6208, which could have come from the output of #3 or elsewhere. I'm not very familiar with #4 command, so the output of #3 is where I started and... there it was!

I included the command for #4, which includes the memory address from #3 command at the end of the show/hide (spoiler) tag for your viewing pleasure (makes it easier to see/compare)!

kd> command for #3 -

[COLOR=#565656]2: kd> [/COLOR][B]!handle 300[/B]

Output for #3:

Read More:

Output for #3:

2: kd> [B]!handle 300[/B]

PROCESS 95bf14e8  SessionId: 1  Cid: 07bc    Peb: 7ffde000  ParentCid: 1ffc
    DirBase: 9f02c280  ObjectTable: c44f85d8  HandleCount: 192.
    Image: vsmon.exe

Handle table at c44f85d8 with 192 entries in use

0300: Object: c9dd6220  GrantedAccess: 00020019 Entry: db2ba600
Object: c9dd6220  Type: (869e4980) Key
   [B] ObjectHeader: [COLOR=#ff0000]c9dd6208[/COLOR] (new version)[/B]
        HandleCount: 1  PointerCount: 1
        Directory Object: 00000000  Name: \REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\PROFILELIST\S-1-5-18

kd> command for #4 -

[FONT=Lucida Console] [COLOR=#565656]2: kd> [/COLOR][B]dt nt!_MODE [COLOR=#ff0000][B]c9dd6208[/B][/COLOR][/B][/FONT]

So, that ends the mystery as to where the cmd parm memory address for #4 came from.

We can all rest easy tonight! :0

---

---

START ANALYSIS OF PATRICK'S POST

Now, we'll get started with the analysis on Patrick's post #17.

Summation - "Probably caused by:" Zone Alarm BSOD likely caused by Bitdefender.

Windbg kd> commands used & displayed in post:

1. !analyze -v
2. knL
3. !handle 300
4. dt nt!_MODE c9dd6208
5. .bugcheck
6. !address 8eea7cc3
7. !thread 95a1c7c8
8. !irp 89326ac0
9. !fileobj 95a1a7c8

1. "!analyze" = displays information about the bugcheck; "-v" = verbose output; "!analyze -v is probably the most well known and widely used Windbg command in the world (my estimate & opinion)
2. Display Stack Backtrace - displays the thread's stack frame and related information (the command = "k"; "n" = Displays frame numbers; "L" = Hides source lines in the display. "L" is case sensitive)
3. Displays information about a handle that a process owns
   Not sure what the "300" after "!handle" means as I can't locate any information on it at this time.
   Windbg help CHM file shows these as valid parms for the !thread command:
   
   

   Read More:

   [B]Parameters
   [/B]
   [I][SIZE=3][B]Handle [/B][/SIZE][/I]
   Specifies the index of the handle to display. If Handle is -1 or if you omit this parameter, the debugger displays data for all handles that are associated with the current process. If Handle is 0, the debugger displays data for all handles.
   
   [SIZE=3][B][I]UMFlags[/I][/B][/SIZE]
   (User mode only) Specifies what the display should contain. This parameter can be a sum of any of the following bit values. (The default value is 0x1.)
   
   Bit 0 (0x1) 
   Displays handle type information.
   
   Bit 1 (0x2) 
   Displays basic handle information.
   
   Bit 2 (0x4) 
   Displays handle name information.
   
   Bit 3 (0x8) 
   Displays object-specific handle information, when available.
   
   [SIZE=3][I][B]KMFlags[/B][/I][/SIZE] 
   (Kernel mode only) Specifies what the display should contain. This parameter can be a sum of any of the following bit values. (The default value is 0x3.)
   
   Bit 0 (0x1) 
   Displays basic handle information.
   
   Bit 1 (0x2) 
   Displays information about objects.
   
   Bit 2 (0x4) 
   Displays free handle entries. If you do not set this bit and you omit Handle or set it to zero, the list of handles that are displayed does not include free handles. If Handle specifies a single free handle, it is displayed even if you do not set this bit. 
   
   Bit 4 (0x10) 
   (Windows XP and later) Displays the handle from the kernel handle table instead of the current process.
   
   Bit 5 (0x20) 
   (Windows XP and later) Interprets the handle as a thread ID or process ID and displays information about the corresponding kernel object.
   
   [SIZE=3][I][B]Process [/B][/I][/SIZE]
   (Kernel mode only) Specifies a process. You can use the process ID or the hexadecimal address of the process object. This parameter must refer to a currently running process on the target system. If this parameter is -1 or if you omit it, the current process is used. If this parameter is 0, handle information from all processes is displayed.
   
   [SIZE=3][I][B]TypeName [/B][/I][/SIZE]
   Specifies the type of handle that you want to examine. Only handles that match this type are displayed. TypeName is case sensitive. Valid types include Event, Section, File, Port, Directory, SymbolicLink, Mutant, WindowStation, Semaphore, Key, Token, Process, Thread, Desktop, IoCompletion, Timer, Job, and WaitablePort.

   
   ​
4. Displays displays information about a local variable, global variable or data type. The memory address (c9dd6208) was obtained from this output line from #3 -
   

   ObjectHeader: c9dd6208 (new version)

5. Displays bugcheck information - the STOP ERROR followed by 4 parameters in parenthesis (P1,P2,P3,P4)
6. Displays information about the memory address used by the target address [the hexadecimal number following the word ADDRESS]
7. Displays summary information about a thread [the hexadecimal number after the word THREAD]
8. Displays IRP (I/O Request Packet) information
9. Displays detailed information about the FILE_OBJECT structure. The actual file object is the memory address following the word FILEOBJ

Very nice analysis, Patrick. :thumbsup2:

Please know that a thread not found, detailed/analyzed and discussed in this "Most Notable BSOD Kernel Dump Analysis Posts" thread/sticky DOES NOT in any way mean that it was not good enough to be a "...most notable..." BSOD post. There are many reasons why most threads don't make it in here -- #1 reason (or excuse if you wish!) - lack of time.

"Sysnative Forums" is specifically mentioned here because this post involves a thread from this forum. Most of us (BSOD Analysts) are on staff at other forums or just simply answer BSOD threads as time permits.

Sysnative Forums is our primary forum; however, there are two other forums that take precedence over ALL others after Sysnative Forums -- Bleeping Computer (BC) and Tech Support Forum (TSF). They both use "BSOD Posting Instructions" very similar to ours (the same "SysnativeBSODCollectionApp.exe" dump + collection app is used -- 1st developed in 2008; improved constantly ever since, and copied/plagiarized by many).

Lastly, the comments in this post about the BSOD thread are mine. I in no way speak for Patrick, the author of the post in question and therefore, he is of course free to correct anything I have written. Something doesn't necessarily have to be incorrect/wrong; a simple disagreement may occur.

Regards. . .

jcgriff2

 

[Patrick]

Thanks to cluberti for answering my quick questions regarding that specific issue as well.

 

[Jared]

Not sure what the "300" after "!thread" means as I can't locate any information on it at this time.

The 300 is the actual handle that was being referenced.
It was actually after '!handle', not '!thread'.

It took Patrick and I a while to find the data structure that represents the Kernel and User mode of an object, I finally found it through sheer luck actually.
After about an hour, and many MSDN articles, searching for undocumented data structures later...

But good post though Patrick.

 

[jcgriff2]

Not sure what the "300" after "!thread" means as I can't locate any information on it at this time.

The 300 is the actual handle that was being referenced.
It was actually after '!handle', not '!thread'.

It took Patrick and I a while to find the data structure that represents the Kernel and User mode of an object, I finally found it through sheer luck actually.
After about an hour, and many MSDN articles, searching for undocumented data structures later...

But good post though Patrick.

Thanks for spotting my typo. I changed !thread to !handle before the 300.

I did look up !handle and don't see "300" as a parm; hence I still don't know its meaning.

With user mode dumps, the parm options are 0x1, 0x2, 0x4 & 0x8.

Kernel mode dumps - parm options listed are 0x1, 0x2, 0x4, 0x10 & 0x20.

I was just curious as to where the "300" came from & what it does as compared to the other parms.

Regardless of its origin ad meaning, it worked/helped you here!

Thanks,

John

 

[Patrick]

By the way John, this is a great way to show recognition.

 

[Jared]

Not sure what the "300" after "!thread" means as I can't locate any information on it at this time.

The 300 is the actual handle that was being referenced.
It was actually after '!handle', not '!thread'.

It took Patrick and I a while to find the data structure that represents the Kernel and User mode of an object, I finally found it through sheer luck actually.
After about an hour, and many MSDN articles, searching for undocumented data structures later...

But good post though Patrick.

Thanks for spotting my typo. I changed !thread to !handle before the 300.

I did look up !handle and don't see "300" as a parm; hence I still don't know its meaning.

With user mode dumps, the parm options are 0x1, 0x2, 0x4 & 0x8.

Kernel mode dumps - parm options listed are 0x1, 0x2, 0x4, 0x10 & 0x20.

I was just curious as to where the "300" came from & what it does as compared to the other parms.

Regardless of its origin ad meaning, it worked/helped you here!

Thanks,

John

300 isn't a parameter, it's the actual handle reference used to access an object, which was the handle reference that caused the crash.

Its passed as a parameter with the bugcheck function, it's the 2nd parameter in that particular 0xC4 bugcheck.

 

[jcgriff2]

OK... thanks.

I wasn't aware that could be done per the Windbg help file debugger.chm.

 

[jcgriff2]

By the way John, this is a great way to show recognition.

You did a great job, Patrick -- and it was a relatively easy one for me to explain in greater detail considering you prett much explained it as you went along in the thread.

I simply expanded on what you did/posted to give the users (including myself) additional info on the various commands that you used.

 

[jcgriff2]

Courtesy of Patrick - 2 BSODs - bugchecks = 0x19 + 0xa along with storport.sys mentioned.

Great analysis - https://www.sysnative.com/forums/bs...gging/26845-storport-sys-bsod.html#post239413

John

 

[jcgriff2]

Courtesy of Patrick and cwsink -- more Windbg commands -

Patrick - https://www.sysnative.com/forums/bs..._thread_exception_not_handled.html#post243582

cwsink - https://www.sysnative.com/forums/bs..._thread_exception_not_handled.html#post243882

John

 

[jcgriff2]

Bugcheck 0x50 - Invalid memory referenced

Through the use of the !pte Windbg command, the illegal page fault is revealed -

Constant system crash related to nvidia? Windows 10 BSOD

Nice job @x BlueRobot !

John

 

[jcgriff2]

Here is a thread that reminds us that one can have multiple (different) bugchecks and can be software (driver) related - Win7 Crashing Before I Can Use SysnativeFileCollectionApp - Page 2 - Tech Support Forum

Usually if we end up with varying bugchecks, the cause is often [unknown] hardware failure.

John




`