Reference: Workarounds & other tools
This info is handy however to help understand memory run's
Dealing with VMWare (or anything else that has a problem with these inputs (/me looks at @Rekal @Volatility ;)
An interim solution for dealing with problems in extracting from difficult to analyze .vmem files (the memory file that VMWare uses for Workstation when you suspend/snapshot) can function like this;
Windows 1511>"\Program Files (x86)\VMware\VMware Workstation"\vmss2core -W "Windows 1511-1b05a6a0.vmss" "Windows 1511-1b05a6a0.vmem"
vmss2core version 3272444 Copyright (C) 1998-2015 VMware, Inc. All rights reserved.
region[0]: start=0 end=c0000000.
region[1]: start=100000000 end=178800000.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
So in the above case a current version of Windows 10 (1511 from October 2015) is suspended and we had hoped to create a .DMP to allow for use in a debugger or inVtero.net itself (since we now support DMP's emitted from this tool). Unfortunately, like with many memory analysis tools there is a problem (memory analysis can be very hard given the lack of concrete artifacts).
Fortunately, until I (or somebody sends me a patch) implment support for VMWare 11-12, all the information we need has been dumped to the screen.
I'll be adding an interface to the command line for this exact format so you can copy paste it (very, like today)soon region[0]: start=0 end=c0000000. region[1]: start=100000000 end=178800000
Until then, if you can manage code, and you either ping me or wait for the (yes today I'm sure of it:) next commit. The Vtero class has a new member DetectedDesc of type MemoryDescriptor which is a List and counter of the region[] info that vmss2core dumps out. I'll probably write the command line handling updates at the same time so you wont ever have todo a code patch unless your using inVtero.net in your personal tools.