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

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

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Re: windbg digest: October 04, 2017

Osiris_PedrosoOsiris_Pedroso Member Posts: 24
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 <
[email protected]> wrote:

> WINDBG Digest for Wednesday, October 04, 2017.
>
> 1. 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 <
> [email protected]> 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: [email protected]
> > To unsubscribe send a blank email to [email protected]
> >
>
>
>
> ---
>
> END OF DIGEST
>
> ---
> You are currently subscribed to windbg as: [email protected]
> To unsubscribe send a blank email to [email protected]
>
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!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA