Can't pipeline directory contents to Mount-DbgDumpFile about dbgshell HOT 9 CLOSED

You can dismount dump files, but there is a documentation / discoverability problem: you can use Disconnect-DbgProcess, or either of its windbg-esque wrappers, .detach or .kill. (There are multiple problems here; the term "DbgProcess" doesn't sound like it would be related to dumps at all, and the help for Mount-DbgDumpfile doesn't give you any clues.)

To clarify about the piping, you would want all the dumps to be mounted at the same time?

from dbgshell.

I don't have a strong opinion either way - I'm generally going to want to run more thing against a set of dumps, but whether that means mount -> command -> dismount or mount all -> enumerate targets -> command isn't particularly important to me.

from dbgshell.

About the documentation problem, there is also #22, to address making it easier to add cmdlet help, in addition actually adding more cmdlet help, so I'm going to consider that part of this issue covered by that one.

Also, I discovered that there is also a Dismount-DbgDumpFile command; I just never use it so I forgot about it (.kill is shorter to type, so I made it work in DbgShell, even though it doesn't in windbg :D).

But:

Also helpful for that would be a way to automatically dismount dump files [..] so you don't get target name conflicts

(emphasis added)

Are you talking about something like: you currently have a dump mounted at Dbg:\MyApp, and then you want to mount another dump at the same path (because that's the auto-chosen path), so you want to detach the first dump and attach the second, instead of getting an error about the target name already being used?

My gut reaction is that it wouldn't be good to do by default... but perhaps with a prompt, which could be suppressed by an option? But that wouldn't be high on my priority list to implement.

all the dumps to be mounted at the same time?
I don't have a strong opinion either way

In that case, I would recommend against trying to deal with multiple dumps mounted at the same time, unless you need to for some reason. DbgEng's API supports the concept of being attached to multiple targets, but IIRC it does not work very well for dump files (I think I've got comments in the code complaining about it). Since the dbgeng threading model basically limits you to linear processing anyway, I would just do them one at a time.

from dbgshell.

Let me clarify: I just want this (or similar equivalent) to work; I am simply not particular about the details of how, and I may have misinterpreted why it doesn't work.

> Get-ChildItem 'E:\MemoryDumps\' -File | % { $_.FullName.ToString()  } | Mount-DbgDumpFile | % { Get-DbgModuleInfo mshtml }
Name                       Start              End            Symbol Status     Company                Version
----                       -----              ---            -------------     -------                -------
mshtml               00000000`6b180000 00000000`6c514000      (deferred)       Microsoft Corporation  11.00.17134.523 (WinBuild.160101.0800)
mshtml               00000000`6b180000 00000000`6c514000      (deferred)       Microsoft Corporation  11.00.17134.523 (WinBuild.160101.0800)
mshtml               00000000`6b180000 00000000`6c514000      (deferred)       Microsoft Corporation  11.00.17134.523 (WinBuild.160101.0800)
mshtml               00000000`6b180000 00000000`6c514000      (deferred)       Microsoft Corporation  11.00.17134.523 (WinBuild.160101.0800)


> Get-ChildItem 'E:\MemoryDumps\' -File | % { $_.FullName.ToString()  } | Mount-DbgDumpFile | % { Get-DbgModuleInfo jscript9 }

Name                       Start              End            Symbol Status     Company                Version
----                       -----              ---            -------------     -------                -------
jscript9             00000000`6ab30000 00000000`6aec2000      (deferred)       Microsoft Corporation  11.00.17134.441 (WinBuild.160101.0800)
jscript9             00000000`6ab30000 00000000`6aec2000      (deferred)       Microsoft Corporation  11.00.17134.441 (WinBuild.160101.0800)
jscript9             00000000`6ab30000 00000000`6aec2000      (deferred)       Microsoft Corporation  11.00.17134.441 (WinBuild.160101.0800)


Mount-DbgDumpFile : Index too big: 6
At line:1 char:73
+ ... s\' -File | % { $_.FullName.ToString()  } | Mount-DbgDumpFile | % { G ...
+                                                 ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Mount-DbgDumpFile], NotSupportedException
    + FullyQualifiedErrorId : System.NotSupportedException,MS.Dbg.Commands.MountDbgDumpFileCommand

from dbgshell.

Ah, I see. I think you must have some modifications to your version, because it seems like you should have hit different problems first with those commands.

The first thing to note is that Mount-DbgDumpFile does output a bunch of objects, but probably not objects that you'd be interested in for this sort of analysis (all the "ModLoaded: blah" output, the last event ("break exception" or "access violation" or whatever), the registers, etc.), and you definitely wouldn't want to run your analysis for every one of those objects; you just want to run it once per dump.

So you'd want to do something more like this (it's slightly prettier if you have the commit I just made to allow piping the output of Get-ChildItem directly into Mount-DbgDumpFile; without it you can just use the .FullName.ToString() trick like you already did) (note the | Out-Null to ignore the output of Mount-DbgDumpFile):

Get-ChildItem 'C:\temp\Dumps' -File | %{
    #Mount-DbgDumpFile $_ | Out-Null
    Mount-DbgDumpFile $_.FullName.ToString() | Out-Null
    try {
        # do analysis here
        Get-DbgModuleInfo ntdll
    } finally {
        .detach
    }
}

That pattern could easily be packaged up into a ForEach-DbgDumpFile command... or at the very least be included in some "cookbook" documentation (#33).

from dbgshell.

<#
.SYNOPSIS
    For each dump file path, this command mounts the dump file, runs the supplied
    ScriptBlock, then detaches.
#>
function ForEach-DbgDumpFile
{
    [CmdletBinding()]
    param( [Parameter( Mandatory = $false,
                       ValueFromPipeline = $true,
                       ValueFromPipelineByPropertyName = $true )]
           [Alias( 'PSPath' )] # Allows piping in output of "dir"
           [string] $DumpFilePath,

           [Parameter( Mandatory = $true, Position = 0 )]
           [ScriptBlock] $ScriptBlock
         )

    process
    {
        try
        {
            # Note that we suppress/ignore all the output you normally get when you load a
            # dump file.
            Mount-DbgDumpFile $DumpFilePath | Out-Null

            & $ScriptBlock
        }
        finally
        {
            .detach
        }
    }
}

Example usage:

PS Dbg:\
> dir C:\temp\dumps\ -File | ForEach-DbgDumpFile { lm ntdll }

Name                       Start              End            Symbol Status     Company                Version
----                       -----              ---            -------------     -------                -------
ntdll                00007ff9`20ea0000 00007ff9`2108d000   (export symbols)    Microsoft Corporation  10.0.17763.292 (WinBuild.160101.0800)
ntdll                00007ff9`20ea0000 00007ff9`2108d000   (export symbols)    Microsoft Corporation  10.0.17763.292 (WinBuild.160101.0800)
ntdll                00007ff9`20ea0000 00007ff9`2108d000   (export symbols)    Microsoft Corporation  10.0.17763.292 (WinBuild.160101.0800)


PS Dbg:\
>

from dbgshell.

ForEach-DbgDumpFile is great! I had noticed (and forgotten) that the commands would run twice for the final dump but I hadn't tried to figure out why.

Is there an easy way to tack a TargetFriendlyName column onto a table? (makes it easier to toss in Excel & pivot/graph)

from dbgshell.

You could of course tack on such properties manually in your script block, using Add-Member. But it's a good idea, and seems like a sort of standard PowerShell-y thing to do, so I went ahead and baked it directly into ForEach-DbgDumpFile.

Note that I noticed a formatting bug (#71), so be aware of that when directly examining your output in DbgShell.

from dbgshell.

I suspected something like that was possible, but it exceeded my familiarity with PowerShell. Fortunately, the way I did come up with (adding a (Get-DbgCurrentTarget).TargetFriendlyName script column to the custom formatting for the commands I cared about) also happens to work around that formatting :)

from dbgshell.