Re: windbg digest: October 03, 2017

Osiris_Pedroso · October 4, 2017, 7:49am

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.

Re: Scripting WinDBG to process captured minidumps

Re: Difference in WinDBG “!analyze -v” stack formatting

Re: Difference in WinDBG “!analyze -v” stack formatting

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 (00007ffe7867dd20)] > > 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 <xxxxx> > 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 <xxxxx> <xxxxx> 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 > (00007ffe7867dd20)]
> >
> > 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 http:
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http:
> >
>
> ----------------------------------------------------------------------
>
> 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 http:
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http:
> >>
> >
>
>
>
> —
>
> END OF DIGEST
>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></http:></http:></http:></http:>