Closed GoogleCodeExporter closed 8 years ago
Hi Holger,
Sure, is there a place you can upload the memory dump so we can access it? Its
not a size thing per-se, as we've analyzed dumps that are 30-40 GB before, so
there must be something else going on, but we're glad to help track it down.
Thanks!
Original comment by michael.hale@gmail.com
on 13 May 2012 at 6:01
Ups, can you change the title for me?
There is a typing error and i meant dumps and not mumps..lol
Original comment by Fa.DEM...@googlemail.com
on 13 May 2012 at 6:02
Ok, i'll upload on our server (archived with WinRAR) and then i'll post the
download link here.
Thank's a lot for your help.
Original comment by Fa.DEM...@googlemail.com
on 13 May 2012 at 6:12
Original comment by mike.auty@gmail.com
on 13 May 2012 at 7:19
Upload finished.
Mail with download - link sent to you
Thank's again
Holger
Original comment by Fa.DEM...@googlemail.com
on 13 May 2012 at 9:55
Holger, I got the memory dump, so you can go ahead and delete it. Thanks.
@devs, I'll let you know what's going on after I take a look.
Original comment by michael.hale@gmail.com
on 14 May 2012 at 1:13
Hey Holger,
I can't get anything working with your memory dump either. In an effort to
double check with another tool besides Volatility, I converted the memory dump
to a crash dump with Moonsol's bin2dmp.exe (from the same package as Win64dd,
the professional version). It converted OK, but when I tried to open the
converted file in windbg I got the attached error messages. In short, windbg
was able to identify it as Win7SP1x64 but failed to list any processes or
kernel modules due to "possible paged-out or corrupt data." When I tried
!analyze -v in the debugger, it indicated some driver crash:
GetContextState failed, 0xD0000147
GetContextState failed, 0xD0000147
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x4D415454
If you see the Bugcheck str, 0x4D415454 is MATT in ASCII, which is the name of
the win64dd driver author. He likes to put strange identifying strings in crazy
places, so most likely the acquisition driver caused a crash of some sort, thus
leading to a corrupt memory dump.
So unfortunately I cannot help much more, but you may have better luck with
another acquisition tool. See
http://www.forensicswiki.org/wiki/Tools:Memory_Imaging for some other options.
Typically we recommend Kntdd but its one of the commercial ones.
Original comment by michael.hale@gmail.com
on 14 May 2012 at 4:19
Oh sorry, here's the attached windbg output.
Original comment by michael.hale@gmail.com
on 14 May 2012 at 4:32
Attachments:
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
Hey Michael,
that sounds very strange for me, because i tried win64dd on 4 other Win7 64 bit
systems without any problems.
Only on my ASUS Notebook with 12 GB of memory, i got this issue.
I tried another tool before (Redline and Memorize from Mandiant), but that
generated a Bluescreen on this machine.
Mandiant says, the machine which are used for analyzing must have more memory
than the dumped memory, so i can't use this tool on this machine.
Normaly i would say, "MoonSols" must fix their tool. Maybe, that's fixed in the
comercial version.
Otherwise this tool doesn't work on all machines correctly.
Thank's a lot for your analyze and i'll try to test with another tool.
If there a link to KNTDD? I would like to get the price of this tool.
Greetings,
Holger
Original comment by Fa.DEM...@googlemail.com
on 14 May 2012 at 12:15
Hiya Holger,
I'm going to mark this bug as invalid, simply because it appears to be an issue
with the memory acquisition software, rather than in volatility itself. Do
feel free to reopen the issue if you feel it isn't fixed. MHL will still be
able to respond here, it's mostly just to clear the issue off our todo list.
Hope that's ok...
Mike
Original comment by mike.auty@gmail.com
on 14 May 2012 at 12:50
No Problem Mike,
To relieve the board here, I can communicate well in advance with Michael via
email.
Only when it again volatility and concern for your development should be
interesting, I'll write something about it here again.
Thank's a lot to all for your great job here!
Holger
Original comment by Fa.DEM...@googlemail.com
on 14 May 2012 at 1:42
Original issue reported on code.google.com by
Fa.DEM...@googlemail.com
on 13 May 2012 at 5:57