views:

34

answers:

1

I have a crash dump from a production server that shows an OutOfMemoryException. The exception itself is not relevant here.

I happened to run a !dso to view the stack objects:

0:042> !dso
OS Thread Id: 0x1014 (42)
ESP/REG  Object   Name
246eeb24 109a21bc System.UnhandledExceptionEventHandler
246eeb2c 39083998 System.Runtime.Remoting.Proxies.__TransparentProxy
246eeb34 39083b5c System.UnhandledExceptionEventArgs
246eeb48 39073280 System.Byte[]
246eec10 2e720050 System.OutOfMemoryException
[snip]
246ef250 0ac1c4d0 System.IO.MemoryStream <-- interesting

I thought the MemoryStream might have something to do with the error, so I dumped it:

0:042> !do 0ac1c4d0 
Name: System.IO.MemoryStream
MethodTable: 7932d5e4
EEClass: 790ec318
Size: 52(0x34) bytes
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
7933061c  400018a        4        System.Object  0 instance 00000000 __identity
7992cbcc  4001b6c        8 ...ream+ReadDelegate  0 instance 00000000 _readDelegate
7992cc58  4001b6d        c ...eam+WriteDelegate  0 instance 00000000 _writeDelegate
7931bd9c  4001b6e       10 ...ng.AutoResetEvent  0 instance 00000000 _asyncActiveEvent
79332c4c  4001b6f       14         System.Int32  1 instance        1 _asyncActiveCount
7932e6fc  4001b6b      574     System.IO.Stream  0   shared   static Null
    >> Domain:Value  000dc0f0:NotInit  00109d58:109b6abc <<
79333470  4001c16       18        System.Byte[]  0 instance 50710038 _buffer
79332c4c  4001c17       1c         System.Int32  1 instance        0 _origin
79332c4c  4001c18       20         System.Int32  1 instance 56071048 _position
79332c4c  4001c19       24         System.Int32  1 instance 56071048 _length
79332c4c  4001c1a       28         System.Int32  1 instance 67108864 _capacity
793044cc  4001c1b       2c       System.Boolean  1 instance        1 _expandable
793044cc  4001c1c       2d       System.Boolean  1 instance        1 _writable
793044cc  4001c1d       2e       System.Boolean  1 instance        1 _exposable
793044cc  4001c1e       2f       System.Boolean  1 instance        1 _isOpen

Wow, a 56,071,048 byte buffer seems a bit large. I'd like to see the contents of this buffer:

0:042> !do 50710038 
Name: System.Byte[]
MethodTable: 79333470
EEClass: 790eeb6c
Size: 67108876(0x400000c) bytes
Array: Rank 1, Number of elements 67108864, Type Byte
Element Type: System.Byte
Fields:
None

The first 10 elements of the array are below:

0:042> !dumparray -start 0 -length 10 50710038 
Name: System.Byte[]
MethodTable: 79333470
EEClass: 790eeb6c
Size: 67108876(0x400000c) bytes
Array: Rank 1, Number of elements 67108864, Type Byte
Element Methodtable: 79333520
[0] 50710040
[1] 50710041
[2] 50710042
[3] 50710043
[4] 50710044
[5] 50710045
[6] 50710046
[7] 50710047
[8] 50710048
[9] 50710049

This is a huge array. I'd rather not !dumparray the whole thing. I'd like to view the output in a file.

Question

Is it possible to dump the contents of this Byte[] to a file?

I am familiar with the .writemem command, but I can't seem to get this to work. I've tried writing the entire length, but WinDbg didn't like that:

0:042> .writemem C:\LargeBuffer.bin 50710040 L56071048
                                                     ^ Range error in '.writemem C:\LargeBuffer.bin 50710040 l56071048'

Did I format that .writemem command incorrectly?

+3  A: 

The L modifier for ranges is limited in size. If you want to get around the limit use the L? range modifier. The following command worked for me:

0:000> !do 0x04cc1000
Name:        System.Byte[]
MethodTable: 68374944
EEClass:     680aaf1c
Size:        67108876(0x400000c) bytes
Array:       Rank 1, Number of elements 67108864, Type Byte
Element Type:System.Byte
Content:     ................................................................................................................................
Fields:
None
0:000> .writemem c:\temp\array.bin 0x04cc1000 L?0x400000c
Writing 400000c bytes
Brian Rasmussen
That worked. Thank you!
Paul Williams