Thanks AAron,
I was able to cause a crash dump via the keyboard and collect a full memory crash dump.
The original problem was that I would BSOD a Windows 7 x64 system while trying to get a
memory image. That was a big deal because in a response situation, blowing away memory
with your efforts (and therefore losing all vaolitle info) was a problem. Thats what I
meant about "...BSOD and analysis...".
You are correct, I can use a full memory crash dump with Volatility. Vol 2.0 will process
it directly; Vol13 requires it to be converted with dmp2bin (no problem)
I started with Windows XP and will move on testing. If I run across any problems I'll
let you know (as requested).
Thanks for the help! Volatility rocks!
Mike      (info on processing with vol13 and vol20 below in case anyone is interested)
C:\Python27\Volatility-1.3_Beta>python volatility ident -f e:\tests\120310_crash
_dump\fullmemory.dmp
Traceback (most recent call last):
  File "volatility", line 219, in <module>
    main()
  File "volatility", line 212, in main
    modules[argv[1]].execute(argv[1], argv[2:])
  File "C:\Python27\Volatility-1.3_Beta\vmodules.py", line 62, in execute
    self.cmd_execute(module, args)
  File "C:\Python27\Volatility-1.3_Beta\vmodules.py", line 84, in get_image_info
    (addr_space, symtab, types) = load_and_identify_image(op, opts, True)
  File "C:\Python27\Volatility-1.3_Beta\vutils.py", line 201, in load_and_identi
fy_image
    ImageType = find_csdversion(addr_space, types)
  File "C:\Python27\Volatility-1.3_Beta\forensics\win32\tasks.py", line 306, in
find_csdversion
    process_address_space = process_addr_space(addr_space, types, task, addr_spa
ce.base.fname)
AttributeError: WindowsCrashDumpSpace32 instance has no attribute 'fname'
C:\Python27\Volatility-1.3_Beta>path
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\python27;c:\tool
s;C:\WINDOWS\system32\WindowsPowerShell\v1.0
C:\Python27\Volatility-1.3_Beta>dmp2bin e:\tests\120310_crash_dump\fullmemory.dm
p e:\fullmemory.bin
  dmp2bin - 1.0.20100405 - (Community Edition)
  Convert Microsoft crash dump files into raw memory dump images.
  Copyright (C) 2007 - 2010, Matthieu Suiche <http://www.msuiche.net>
  Copyright (C) 2009 - 2010, MoonSols <http://www.moonsols.com>
Initializing memory descriptors... Done.
Sorting 4 entries... 0 seconds.
Loading file... Done.
   [0x000000001FE80000 of 0x000000001FE80000]
Total time for the conversion: 0 minutes 17 seconds.
C:\Python27\Volatility-1.3_Beta>python volatility ident -f e:\tests\120310_crash
_dump\fullmemory.bin
              Image Name: e:\tests\120310_crash_dump\fullmemory.bin
              Image Type: Service Pack 3
                 VM Type: nopae
                     DTB: 0x39000
                Datetime: Sat Mar 10 16:14:26 2012
C:\Python27\Volatility-1.3_Beta>
C:\Python27\volatility-2.0>python vol.py imageinfo -f e:\120310_crash_dump\fullm
emory.dmp
Volatile Systems Volatility Framework 2.0
ERROR   : volatility.plugins.fileparam: The requested file doesn't exist
C:\Python27\volatility-2.0>python vol.py imageinfo -f e:\tests\120310_crash_dump
\fullmemory.dmp
Volatile Systems Volatility Framework 2.0
Determining profile based on KDBG search...
          Suggested Profile(s) : WinXPSP3x86, WinXPSP2x86 (Instantiated with Win
XPSP2x86)
                     AS Layer1 : JKIA32PagedMemory (Kernel AS)
                     AS Layer2 : WindowsCrashDumpSpace32 (E:\tests\120310_crash_
dump\fullmemory.dmp)
                     AS Layer3 : FileAddressSpace (E:\tests\120310_crash_dump\fu
llmemory.dmp)
                      PAE type : No PAE
                           DTB : 0x13054000
                          KDBG : 0x8054ce60L
                          KPCR : 0xffdff000L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2012-03-10 22:14:26
     Image local date and time : 2012-03-10 22:14:26
          Number of Processors : 1
                    Image Type : Service Pack 3
C:\Python27\volatility-2.0>python vol.py imageinfo -f e:\tests\120310_crash_dump
\fullmemory.bin
Volatile Systems Volatility Framework 2.0
Determining profile based on KDBG search...
          Suggested Profile(s) : WinXPSP3x86, WinXPSP2x86 (Instantiated with Win
XPSP2x86)
                     AS Layer1 : JKIA32PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (E:\tests\120310_crash_dump\fu
llmemory.bin)
                      PAE type : No PAE
                           DTB : 0x39000
                          KDBG : 0x8054ce60L
                          KPCR : 0xffdff000L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2012-03-10 22:14:26
     Image local date and time : 2012-03-10 22:14:26
          Number of Processors : 1
                    Image Type : Service Pack 3
C:\Python27\volatility-2.0>
  Date: Sat, 10 Mar 2012 08:38:49 -0500
 From: awalters(a)4tphi.net
 To: dragonforen(a)hotmail.com
 CC: vol-users(a)volatilityfoundation.org
 Subject: Re: [Vol-users] BSOD while collecting a memory image
 Mike,
  2. Is the "full memory dump" comaptible
with Volatility? 
 Yes. Volatility has support for samples in "full" crash dump format. If
 you have any difficulties, please let us know. Any feedback on samples
 collected from 64 bit machines would also be appreciated.
  Question: Has someone gotten a full memory dump
on BSOD and successfully
 processed it with Volatility? 
 Yes.
  Question: Has anyone else thought about how to
deal with BSOD and
 analysis? If it is not something that the list is interested in, we
 could take this offline. 
 The format for crash dumps is well understood (thanks Andreas!). There are
 even a number of tools that are capable of capturing samples in DMP format
 (ie kntdd, moonsols). Unfortunately, there are a number of challenges
 with relying on Window's ability to capture crash dumps (see Suiche's
 presentations). I do know of organizations that preconfigured their
 machines to support crash dumps before there were reliable acquisition
 tools.
 Thanks,
 AW