« Patterns on Portal
Crash Dump Analysis AntiPatterns (Part 5) »

Memory dumps from VMware images

Although I haven’t found the way to distinguish the process dump taken from a physical machine versus virtualized machine there is a way to see it from kernel and complete memory dumps if VMware Tools are installed inside the guest Windows OS:

kd> !vm
...
...
...
         1098 VMwareUser.exe     350 (      1400 Kb)
...
         14e4 VMwareTray.exe     317 (      1268 Kb)
...
         0664 VMwareService.e    190 (       760 Kb)
...
...
...

In case of a kernel minidump we can check for VMware drivers (as we can obviously do with kernel and complete memory dumps):

kd> lmt m vm*
start    end        module name
bf9e6000 bf9faa80   vmx_fb    Tue Oct 04 08:13:32 2005
f6e8b000 f6e8ed80   vmx_svga  Tue Oct 04 08:13:02 2005
f77e7000 f77ede80   vmxnet    Sat Apr 22 23:13:11 2006
f7997000 f7998200   vmmouse   Tue Aug 02 20:07:49 2005
f79c9000 f79ca5c0   vmmemctl  Thu Jul 26 21:50:03 2007

If VMware Tools are not installed we can check machine id:

kd> !sysinfo machineid
Machine ID Information [From Smbios 2.31, DMIVersion 0, Size=1642]
BiosVendor = Phoenix Technologies LTD
BiosVersion = 6.00
BiosReleaseDate = 04/17/2006
SystemManufacturer = VMware, Inc.
SystemProductName = VMware Virtual Platform
SystemVersion = None
BaseBoardManufacturer = Intel Corporation
BaseBoardProduct = 440BX Desktop Reference Platform
BaseBoardVersion = None

- Dmitry Vostokov @ DumpAnalysis.org -

This entry was posted on Wednesday, October 31st, 2007 at 2:12 pm and is filed under Crash Dump Analysis, Virtualization. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 Responses to “Memory dumps from VMware images”

  1. heejune Says:
    November 6th, 2007 at 3:47 am

    after Microsoft has been released VirtualPC for free, it seems like more and more people start changing their vm tools. anyway, VirtualPC has also very similar processes and drivers.
    kd> lmt m vm*
    start end module name
    f7f43000 f7f57000 vmsrvc Sat May 05 20:37:40 2007 (463C6C84)
    kd> lmt m vpc*
    start end module name
    bf9d5000 bf9ee000 vpc_s3_bf9d5000 Wed Apr 25 05:18:48 2007 (462E6628)
    f829d000 f82b4000 vpc_s3 Wed Apr 25 05:18:51 2007 (462E662B)

    BTW, when I tried to make a crash dump sample for kernel stack overflow 0×7F-8 while preparing kernel debugging speech, I coudn’t get it from VirtualPC. I gueess VirtualPC treat it as an internal error, contrary to VMWare’s behavior.

  2. Crash Dump Analysis » Blog Archive » Memory Dumps from Xen-virtualized Windows Says:
    March 13th, 2008 at 5:18 pm

    […] Note: similar information can be checked for VMWare and Virtual PC. […]

  3. Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 87) Says:
    July 10th, 2009 at 8:24 pm

    […] Memory dumps from VMware images (Virtual PC diagnostics in post comments) […]

  4. Crash Dump Analysis » Blog Archive » Memory Dumps from Hyper-V-virtualized Windows Says:
    July 28th, 2009 at 9:33 pm

    […] is another addition to memory dumps coming VMWare, VirtualPC and Xen Server virtualized systems. Now I had a look at Hyper-V and found that this information […]

  5. Dmitry Vostokov Says:
    February 17th, 2012 at 12:42 pm

    Snapshot to a dump:

    http://www.vmware.com/pdf/snapshot2core_technote.pdf

  6. Marc Sherman Says:
    February 17th, 2012 at 2:10 pm

    And there’s also Hyper-V saved state to a dump:

    http://archive.msdn.microsoft.com/vm2dmp

Leave a Reply

You must be logged in to post a comment.