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 -
Code:
2: kd> dt nt!_MODE c9dd6208
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 -
Output for
#3:
Read More:
Output for #3:
Code:
2: kd> !handle 300
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
ObjectHeader: c9dd6208 (new version)
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name: \REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\PROFILELIST\S-1-5-18
kd> command for #4 -
Code:
2: kd> dt nt!_MODE c9dd6208
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:
- !analyze -v
- knL
- !handle 300
- dt nt!_MODE c9dd6208
- .bugcheck
- !address 8eea7cc3
- !thread 95a1c7c8
- !irp 89326ac0
- !fileobj 95a1a7c8
- "!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)
- 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)
- 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:
Code:
Parameters
Handle
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.
UMFlags
(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.
KMFlags
(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.
Process
(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.
TypeName
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.
- Displays displays information about a local variable, global variable or data type. The memory address (c9dd6208) was obtained from this output line from #3 -
Code:
ObjectHeader: c9dd6208 (new version)
- Displays bugcheck information - the STOP ERROR followed by 4 parameters in parenthesis (P1,P2,P3,P4)
- Displays information about the memory address used by the target address [the hexadecimal number following the word ADDRESS]
- Displays summary information about a thread [the hexadecimal number after the word THREAD]
- Displays IRP (I/O Request Packet) information
- 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
