Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

Re: windbg digest: October 03, 2017

Wow!

On Wed, Oct 4, 2017 at 12:00 AM Kernel Debugging Interest List digest <
xxxxx@lists.osr.com> wrote:

> WINDBG Digest for Tuesday, October 03, 2017.
>
> 1. Re: Scripting WinDBG to process captured minidumps
> 2. Re: Difference in WinDBG "!analyze -v" stack formatting
> 3. Re: Difference in WinDBG "!analyze -v" stack formatting
> 4. Re: Difference in WinDBG "!analyze -v" stack formatting
>
> ----------------------------------------------------------------------
>
> Subject: Re: Scripting WinDBG to process captured minidumps
> From: "Scott Noone"
> Date: Tue, 3 Oct 2017 09:11:26 -0400
> X-Message-Number: 1
>
> I'm not sure I completely understand the problem, but maybe try using the
> command line version (kd.exe) instead? It should take the same command line
> arguments as WinDbg.
>
> -scott
> OSR
> @OSRDrivers
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Difference in WinDBG "!analyze -v" stack formatting
> From: "Scott Noone"
> Date: Tue, 3 Oct 2017 09:35:53 -0400
> X-Message-Number: 2
>
> I just stepped through the !analyze command in the debugger. The call that
> !analyze makes to DebugClient::OutputStackTrace uses a hard coded flags
> value:
>
> 0:001> kc
> # Call Site
> 00 dbgeng!DebugClient::OutputStackTrace
> 01 ext!DbgClient::OutputStackTrace
> 02 ext!DebugFailureAnalysis::SetContextFollowupDetails
> 03 ext!DebugFailureAnalysis::AnalyzeStackEx
> 04 ext!DebugFailureAnalysis::ProcessInformationCore
> 05 ext!DebugFailureAnalysis::ProcessInformation
> 06 ext!BcFillAnalysis
> 07 ext!BcAnalyze
> 08 ext!AnalyzeBugCheck
> 09 ext!analyze
> 0a dbgeng!ExtensionInfo::CallA
> 0b dbgeng!ExtensionInfo::Call
> 0c dbgeng!ExtensionInfo::CallAny
> 0d dbgeng!ParseBangCmd
> 0e dbgeng!ProcessCommands
> 0f dbgeng!ProcessCommandsAndCatch
> 10 dbgeng!Execute
> 11 dbgeng!DebugClient::ExecuteWide
> 12 windbg!ProcessCommand
> 13 windbg!ProcessEngineCommands
> 14 windbg!EngineLoop
> 15 KERNEL32!BaseThreadInitThunk
> 16 ntdll!RtlUserThreadStart
>
> HRESULT OutputStackTrace(
> [in] ULONG OutputControl,
> [in, optional] PDEBUG_STACK_FRAME Frames,
> [in] ULONG FramesSize,
> [in] ULONG Flags
> );
>
> mov dword ptr [rsp+20h],0Dh <<== Flags == 0xD
> mov rax,qword ptr [rcx]
> mov rax,qword ptr [rax+108h]
> call qword ptr [ext!_guard_dispatch_icall_fptr (00007ffe`7867dd20)]
>
> So, doesn't look like there's a way to set this as part of running !analyze
> command.
>
> -scott
> OSR
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Difference in WinDBG "!analyze -v" stack formatting
> From: raj r
> Date: Wed, 4 Oct 2017 02:19:24 +0530
> X-Message-Number: 3
>
> you can employ this hack debug the debugger and pass the flags
>
> stack prior to hack
>
> 0:002> dx Debugger.Utility.Control.ExecuteCommand("!analyze
> -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> Debugger.Utility.Control.ExecuteCommand("!analyze
> -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> [0x0] : STACK_TEXT:
> [0x1] : WARNING: Frame IP not in any known module.
> Following frames may be wrong.
> [0x2] : 00f1dde4 100e9b5c ffffffff 00f1de04 00f1de00 0x0
> [0x3] : 00f1e60c 100ec196 10248e54 003fe9d8 0000002e
> dbgeng+0xe9b5c
> [0x4] : 00f1e620 10147ba5 003fe9d8 00000000 00f1e6b0
> dbgeng+0xec196
> [0x5] : 00f1e688 10148730 003fe9d8 00000000 bbb100a7
> dbgeng+0x147ba5
> [0x6] : 00f1e6e8 100bda7c 003fe9d8 00000000 00000000
> dbgeng+0x148730
> [0x7] : 00f1eb5c 100bdcc4 003fe9d8 00f1ef90 00000002
> dbgeng+0xbda7c
> [0x8] : 00f1ebb4 0041e08d 003fe9e0 00000001 00f1ef90
> dbgeng+0xbdcc4
> [0x9] : 00f1ef70 0041e4e7 00000000 00000000 00000040
> windbg+0x1e08d
>
>
> issuing .dbgdbg to spawn a parent debugger that debugs the debugger
> debugging your debuggee
>
> 0:002> .dbgdbg
> Debugger spawned, connect with
> "-remote npipe:icfenable,pipe=cdb_pipe,server=XXXX"
>
>
> now in the ntsd that is spawned
>
> set this conditioanl breakpoint and pass the flag 1fff (look in
> dbgeng.h for explanation of values)
>
> bp dbgeng!DebugClient::OutputStackTrace "ed esp+14 1fff ;gc"
>
> 0:006> bl
> 0 e 5b6b1c40 0001 (0001) 0:**** dbgeng!DebugClient::OutputStackTrace
> "ed e
> sp+14 1fff ;gc"
>
> and execute g
>
> now all your further analyze -v will have a verbose stack
>
>
>
> 0:002> dx Debugger.Utility.Control.ExecuteCommand("!analyze
> -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> Debugger.Utility.Control.ExecuteCommand("!analyze
> -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> [0x0] : STACK_TEXT:
> [0x1] : # Memory ChildEBP RetAddr Args to Child
> [0x2] : WARNING: Frame IP not in any known module.
> Following frames may be wrong.
> [0x3] : 00 00f1dde4 100e9b5c ffffffff
> 00f1de04 00f1de00 0x0
> [0x4] : 01 828 00f1e60c 100ec196 10248e54
> 003fe9d8 0000002e dbgeng+0xe9b5c
> [0x5] : 02 14 00f1e620 10147ba5 003fe9d8
> 00000000 00f1e6b0 dbgeng+0xec196
> [0x6] : 03 68 00f1e688 10148730 003fe9d8
> 00000000 bbb100a7 dbgeng+0x147ba5
> [0x7] : 04 60 00f1e6e8 100bda7c 003fe9d8
> 00000000 00000000 dbgeng+0x148730
> [0x8] : 05 474 00f1eb5c 100bdcc4 003fe9d8
> 00f1ef90 00000002 dbgeng+0xbda7c
> [0x9] : 06 58 00f1ebb4 0041e08d 003fe9e0
> 00000001 00f1ef90 dbgeng+0xbdcc4
>
>
>
>
>
>
> On 10/3/17, Scott Noone wrote:
> > I just stepped through the !analyze command in the debugger. The call
> that
> > !analyze makes to DebugClient::OutputStackTrace uses a hard coded flags
> > value:
> >
> > 0:001> kc
> > # Call Site
> > 00 dbgeng!DebugClient::OutputStackTrace
> > 01 ext!DbgClient::OutputStackTrace
> > 02 ext!DebugFailureAnalysis::SetContextFollowupDetails
> > 03 ext!DebugFailureAnalysis::AnalyzeStackEx
> > 04 ext!DebugFailureAnalysis::ProcessInformationCore
> > 05 ext!DebugFailureAnalysis::ProcessInformation
> > 06 ext!BcFillAnalysis
> > 07 ext!BcAnalyze
> > 08 ext!AnalyzeBugCheck
> > 09 ext!analyze
> > 0a dbgeng!ExtensionInfo::CallA
> > 0b dbgeng!ExtensionInfo::Call
> > 0c dbgeng!ExtensionInfo::CallAny
> > 0d dbgeng!ParseBangCmd
> > 0e dbgeng!ProcessCommands
> > 0f dbgeng!ProcessCommandsAndCatch
> > 10 dbgeng!Execute
> > 11 dbgeng!DebugClient::ExecuteWide
> > 12 windbg!ProcessCommand
> > 13 windbg!ProcessEngineCommands
> > 14 windbg!EngineLoop
> > 15 KERNEL32!BaseThreadInitThunk
> > 16 ntdll!RtlUserThreadStart
> >
> > HRESULT OutputStackTrace(
> > [in] ULONG OutputControl,
> > [in, optional] PDEBUG_STACK_FRAME Frames,
> > [in] ULONG FramesSize,
> > [in] ULONG Flags
> > );
> >
> > mov dword ptr [rsp+20h],0Dh <<== Flags == 0xD
> > mov rax,qword ptr [rcx]
> > mov rax,qword ptr [rax+108h]
> > call qword ptr [ext!_guard_dispatch_icall_fptr
> (00007ffe`7867dd20)]
> >
> > So, doesn't look like there's a way to set this as part of running
> !analyze
> >
> > command.
> >
> > -scott
> > OSR
> >
> >
> > ---
> > WINDBG is sponsored by OSR
> >
> > OSR is hiring!! Info at http://www.osr.com/careers
> >
> >
> > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software
> > drivers!
> > Details at
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> >
> >
>
> ----------------------------------------------------------------------
>
> Subject: Re: Difference in WinDBG "!analyze -v" stack formatting
> From: raj r
> Date: Wed, 4 Oct 2017 02:29:27 +0530
> X-Message-Number: 4
>
> sorry hit enter too soon so following up
>
> if you are issuing a kvn20 after analyze -v wouldn't that print the
> windbg's stack in the top rather than the dumps exception stack ??
>
> iirc !analyze -v detects that part and skips all the dump analysis
> logic stack and only prints the exception stack
>
>
>
> On 10/4/17, raj r wrote:
> > you can employ this hack debug the debugger and pass the flags
> >
> > stack prior to hack
> >
> > 0:002> dx Debugger.Utility.Control.ExecuteCommand("!analyze
> > -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> > Debugger.Utility.Control.ExecuteCommand("!analyze
> > -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> > [0x0] : STACK_TEXT:
> > [0x1] : WARNING: Frame IP not in any known module.
> > Following frames may be wrong.
> > [0x2] : 00f1dde4 100e9b5c ffffffff 00f1de04 00f1de00 0x0
> > [0x3] : 00f1e60c 100ec196 10248e54 003fe9d8 0000002e
> > dbgeng+0xe9b5c
> > [0x4] : 00f1e620 10147ba5 003fe9d8 00000000 00f1e6b0
> > dbgeng+0xec196
> > [0x5] : 00f1e688 10148730 003fe9d8 00000000 bbb100a7
> > dbgeng+0x147ba5
> > [0x6] : 00f1e6e8 100bda7c 003fe9d8 00000000 00000000
> > dbgeng+0x148730
> > [0x7] : 00f1eb5c 100bdcc4 003fe9d8 00f1ef90 00000002
> > dbgeng+0xbda7c
> > [0x8] : 00f1ebb4 0041e08d 003fe9e0 00000001 00f1ef90
> > dbgeng+0xbdcc4
> > [0x9] : 00f1ef70 0041e4e7 00000000 00000000 00000040
> > windbg+0x1e08d
> >
> >
> > issuing .dbgdbg to spawn a parent debugger that debugs the debugger
> > debugging your debuggee
> >
> > 0:002> .dbgdbg
> > Debugger spawned, connect with
> > "-remote npipe:icfenable,pipe=cdb_pipe,server=XXXX"
> >
> >
> > now in the ntsd that is spawned
> >
> > set this conditioanl breakpoint and pass the flag 1fff (look in
> > dbgeng.h for explanation of values)
> >
> > bp dbgeng!DebugClient::OutputStackTrace "ed esp+14 1fff ;gc"
> >
> > 0:006> bl
> > 0 e 5b6b1c40 0001 (0001) 0:****
> dbgeng!DebugClient::OutputStackTrace
> > "ed e
> > sp+14 1fff ;gc"
> >
> > and execute g
> >
> > now all your further analyze -v will have a verbose stack
> >
> >
> >
> > 0:002> dx Debugger.Utility.Control.ExecuteCommand("!analyze
> > -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> > Debugger.Utility.Control.ExecuteCommand("!analyze
> > -v").SkipWhile(a=>(a.Contains("STACK_TEXT") == 0)).Take(10)
> > [0x0] : STACK_TEXT:
> > [0x1] : # Memory ChildEBP RetAddr Args to Child
> > [0x2] : WARNING: Frame IP not in any known module.
> > Following frames may be wrong.
> > [0x3] : 00 00f1dde4 100e9b5c ffffffff
> > 00f1de04 00f1de00 0x0
> > [0x4] : 01 828 00f1e60c 100ec196 10248e54
> > 003fe9d8 0000002e dbgeng+0xe9b5c
> > [0x5] : 02 14 00f1e620 10147ba5 003fe9d8
> > 00000000 00f1e6b0 dbgeng+0xec196
> > [0x6] : 03 68 00f1e688 10148730 003fe9d8
> > 00000000 bbb100a7 dbgeng+0x147ba5
> > [0x7] : 04 60 00f1e6e8 100bda7c 003fe9d8
> > 00000000 00000000 dbgeng+0x148730
> > [0x8] : 05 474 00f1eb5c 100bdcc4 003fe9d8
> > 00f1ef90 00000002 dbgeng+0xbda7c
> > [0x9] : 06 58 00f1ebb4 0041e08d 003fe9e0
> > 00000001 00f1ef90 dbgeng+0xbdcc4
> >
> >
> >
> >
> >
> >
> > On 10/3/17, Scott Noone wrote:
> >> I just stepped through the !analyze command in the debugger. The call
> >> that
> >> !analyze makes to DebugClient::OutputStackTrace uses a hard coded flags
> >> value:
> >>
> >> 0:001> kc
> >> # Call Site
> >> 00 dbgeng!DebugClient::OutputStackTrace
> >> 01 ext!DbgClient::OutputStackTrace
> >> 02 ext!DebugFailureAnalysis::SetContextFollowupDetails
> >> 03 ext!DebugFailureAnalysis::AnalyzeStackEx
> >> 04 ext!DebugFailureAnalysis::ProcessInformationCore
> >> 05 ext!DebugFailureAnalysis::ProcessInformation
> >> 06 ext!BcFillAnalysis
> >> 07 ext!BcAnalyze
> >> 08 ext!AnalyzeBugCheck
> >> 09 ext!analyze
> >> 0a dbgeng!ExtensionInfo::CallA
> >> 0b dbgeng!ExtensionInfo::Call
> >> 0c dbgeng!ExtensionInfo::CallAny
> >> 0d dbgeng!ParseBangCmd
> >> 0e dbgeng!ProcessCommands
> >> 0f dbgeng!ProcessCommandsAndCatch
> >> 10 dbgeng!Execute
> >> 11 dbgeng!DebugClient::ExecuteWide
> >> 12 windbg!ProcessCommand
> >> 13 windbg!ProcessEngineCommands
> >> 14 windbg!EngineLoop
> >> 15 KERNEL32!BaseThreadInitThunk
> >> 16 ntdll!RtlUserThreadStart
> >>
> >> HRESULT OutputStackTrace(
> >> [in] ULONG OutputControl,
> >> [in, optional] PDEBUG_STACK_FRAME Frames,
> >> [in] ULONG FramesSize,
> >> [in] ULONG Flags
> >> );
> >>
> >> mov dword ptr [rsp+20h],0Dh <<== Flags == 0xD
> >> mov rax,qword ptr [rcx]
> >> mov rax,qword ptr [rax+108h]
> >> call qword ptr [ext!_guard_dispatch_icall_fptr
> >> (00007ffe`7867dd20)]
> >>
> >> So, doesn't look like there's a way to set this as part of running
> >> !analyze
> >>
> >> command.
> >>
> >> -scott
> >> OSR
> >>
> >>
> >> ---
> >> WINDBG is sponsored by OSR
> >>
> >> OSR is hiring!! Info at http://www.osr.com/careers
> >>
> >>
> >> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> >> software
> >> drivers!
> >> Details at
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >>
> >>
> >
>
>
>
> ---
>
> END OF DIGEST
>
> ---
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!