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@4tphi.net
> To: dragonforen@hotmail.com
> CC: vol-users@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