Re: windbg digest: October 04, 2017

Osiris_Pedroso · October 5, 2017, 2:00pm

I was so out of words… and it worked too!
I will try to script the whole process and get back if I am successful.
Thanks,
Osiris

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

WINDBG Digest for Wednesday, October 04, 2017.

Re: windbg digest: October 03, 2017

Subject: Re: windbg digest: October 03, 2017
From: Osiris Pedroso
> Date: Wed, 04 Oct 2017 11:49:00 +0000
> X-Message-Number: 1
>
> 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
> (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
> >
>
>
>
> —
>
> 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:>