.dump /ma fails duing WriteFullMemory.Memory.Read(0x9f0000, 0x1000

[Matt Crowder]

I have a large application where the memory is becomming very fragmented. I
have been trying to use "adplus -hang -p 1234" to get a memory dump to then
use with VA View. However, when I use adplus (or just use windbg's ".dump
/ma C:\Dumps\dumpfile.dmp") I get the following errors when the dump is being
generated:

Creating C:\Dumps\dumpfile.dmp - mini user dump
WriteFullMemory.Memory.Read(0xc9f0000, 0x10000) failed, retries 5, 0x8007012b
WriteFullMemory.Memory.Read(0xc9f0000, 0x10000) failed, retries 4, 0x8007012b
WriteFullMemory.Memory.Read(0xc9f0000, 0x10000) failed, retries 3, 0x8007012b
WriteFullMemory.Memory.Read(0xc9f0000, 0x10000) failed, retries 2, 0x8007012b
WriteFullMemory.Memory.Read(0xc9f0000, 0x10000) failed, retries 1, 0x8007012b
Dump creation failed, Win32 error 299
"Only part of a ReadProcessMemory or WriteProcessMemory request was
completed."

This should be a relatively simple user dump to a local drive with plenty of
space. It has worked a couple of the times so I know that in theory it
should work.

Any ideas what the problem is a what I can do to generate a valid dump?

Thanks,

Matt Crowder

[Drew Bliss [MSFT]]

The errors mean that the debugger is unable to read the content of a piece
of memory that is supposed to be valid (c9f0000). Generally this happens
when the process has a file mapping open across the network and the
connection drops; the content can no longer be paged in. There is no way to
get a full dump when this error occurs because there is no way to get the
full memory content of the process. You instead have to try and get a
smaller, non-full-memory dump.

"Matt Crowder" <MattC...@discussions.microsoft.com> wrote in message
news:5BBD6C66-7A60-49D0...@microsoft.com...

[Matt Crowder]

Thanks for your information. I had seen another posting where this error was
the result of a network drive. However, in my case everything is local and
there isn't any file mapping open across the network. Are there other things
that can cause this error? Any ideas on what I can do to debug what is at
the address that is causing it to choke?

Any information you can provide would be much appreciated,

Matt Crowder

[Drew Bliss [MSFT]]

The same problem can occur on a local drive if the drive is having problems.

You can narrow the issue by doing !vprot <addr> in the live debug session.
If the memory is MEM_MAPPED it's a mapping of some kind. You can use
!mapped_file <addr> to have the debugger try and look up what file is
backing the mapping (may or may not work, though).

"Matt Crowder" <MattC...@discussions.microsoft.com> wrote in message

news:9449FACE-C978-4EC2...@microsoft.com...

[Matt Crowder]

You are correct that this is referencing a memory mapped file:

0:015> !vprot 0x4480000
BaseAddress: 04480000
AllocationBase: 04480000
AllocationProtect: 00000004 PAGE_READWRITE
RegionSize: 00040000
State: 00001000 MEM_COMMIT
Protect: 00000004 PAGE_READWRITE
Type: 00040000 MEM_MAPPED

0:015> !mapped_file 0x4480000
Mapped file name for 04480000:
'\Device\HarddiskVolume1\DOCUME~1\matt3274\LOCALS~1\Temp\~DF8D14.tmp'

I have also confirmed that this file exists on disk in my local %TEMP%
directory and is still being referenced. I don't see any reason why it
couldn't be accessed. Any ideas? Also, I can't find any documentation for
!mapped_file. Is this documented in the help? Are there other related
commands not in the help that might provide insight into what's going on?

Any help would be much appreciated,

[Drew Bliss [MSFT]]

You'd need a kernel debugger at this point to determine what exactly the
read failure is. I'd guess the file has been changed underneath the
mapping, such as marked for delete.

I don't believe !mapped_file has gotten document yet, eventually it will be.

"Matt Crowder" <MattC...@discussions.microsoft.com> wrote in message

news:B6233011-EE9B-4300...@microsoft.com...