I'm using PDB files provided by msdl.
Symchk and windbg were working fine till last week. But after an update (I think) suddenly I'm getting this message in symchk and every program which uses it.
Command: symchk.exe /v /r c:\windows\system32\win32k.sys /s SRV*c:\symbols\*http://msdl.microsoft.com/download/symbols
This is the verbose output of symchk:
[SYMCHK] Using search path "SRV*c:\symbols\*http://msdl.microsoft.com/download/symbols"
SYMCHK: win32k.sys FAILED - win32k.pdb mismatched or not found
SYMCHK: FAILED files = 1
SYMCHK: PASSED + IGNORED files = 0
[SYMCHK] Searching for symbols to c:\windows\system32\win32k.sys in path SRV*c:\symbols\*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: SRV*c:\symbols\*http://msdl.microsoft.com/download/symbols
DBGHELP: No header for c:\windows\system32\win32k.sys. Searching for image on disk
DBGHELP: c:\windows\system32\win32k.sys - OK
SYMSRV: c:\symbols\win32k.pdb\B271277F931B479F930225DE8E4DD5392\win32k.pdb not found
SYMSRV: http://msdl.microsoft.com/download/symbols/win32k.pdb/B271277F931B479F930225DE8E4DD5392/win32k.pdb not found
DBGHELP: win32k - no symbols loaded
[SYMCHK] MODULE64 Info ----------------------
[SYMCHK] Struct size: 1680 bytes
[SYMCHK] Base: 0xFFFFF97FFF000000
[SYMCHK] Image size: 3305472 bytes
[SYMCHK] Date: 0x59e533c6
[SYMCHK] Checksum: 0x00320cf6
[SYMCHK] NumSyms: 0
[SYMCHK] SymType: SymNone
[SYMCHK] ModName: win32k
[SYMCHK] ImageName: c:\windows\system32\win32k.sys
[SYMCHK] LoadedImage: c:\windows\system32\win32k.sys
[SYMCHK] PDB: ""
[SYMCHK] CV: RSDS
[SYMCHK] CV DWORD: 0x53445352
[SYMCHK] CV Data: win32k.pdb
[SYMCHK] PDB Sig: 0
[SYMCHK] PDB7 Sig: {00000000-0000-0000-0000-000000000000}
[SYMCHK] Age: 0
[SYMCHK] PDB Matched: TRUE
[SYMCHK] DBG Matched: TRUE
[SYMCHK] Line nubmers: FALSE
[SYMCHK] Global syms: FALSE
[SYMCHK] Type Info: FALSE
[SYMCHK] ------------------------------------
SymbolCheckVersion 0x00000002
Result 0x00010001
DbgFilename win32k.dbg
DbgTimeDateStamp 0x00000000
DbgSizeOfImage 0x00000000
DbgChecksum 0x00000000
PdbFilename win32k.pdb
PdbSignature {B271277F-931B-479F-9302-25DE8E4DD539}
PdbDbiAge 0x00000002
[SYMCHK] [ 0x00000000 - 0x00010001 ] Checked "c:\windows\system32\win32k.sys"
I tried deleting the symbols folder on my PC. no effect. I can get symbols for other files like ntoskrnl.exe. This command works like a charm on the latest windows 10; but occurs in windows 7. No other program like VS2017 and windbg can get the PDB files either.
Related
I am trying to use zbarcam as a qr code reader.
Build System: Buildroot
Hardware: NXP iMX8MM custom board.
Camera: Omnivision camera
Camera driver was ported successfully and I can run it successfully. I am getting the following error message when I am running the zbarcam app.
Can someone please help me with how to proceed with debugging ?
# zbarcam --verbose=9
_zbar_video_open: opened camera dunknown pixelformat:' '
evice /dev/video0 (fd=5)
_zbar_vmx6s-csi 32e20000.csi1_bridge: Fourcc format (0x00000000) invalid.
unknown pixelformat:' '
4l2_probe: i.MX6S_CSI on platformmx6s-csi 32e20000.csi1_bridge: Fourcc format (0x00000000) invalid.
:32e20000.csi1_bridge driver mx6s-csi (version 5.4.24)
_zbar_v4l2_probe: capabilities: CAPTURE READWRITE STREAMING
v4l2_reset_crop: crop bounds: 0 x 0 # (0, 0)
v4l2_reset_crop: current crop win: 0 x 0 # (0, 0) aspect 1 / 1
v4l2_probe_formats: enumerating supported formats:
v4l2_probe_formats: [0] RGB3 : RGB3 EMULATED
v4l2_probe_formats: [1] BGR3 : BGR3 EMULATED
v4l2_probe_formats: [2] YU12 : YU12 EMULATED
v4l2_probe_formats: [3] YV12 : YV12 EMULATED
v4l2_probe_formats: Max supported size: 0 x 0
v4l2_probe_formats: Found 0 formats and 4 emulated formats.
v4l2_probe_formats: current format: (00000000) 0 x 0 INTERLACED (line=0x0 size=0x0)
v4l2_probe_formats: setting requested size: 40960 x 30720
v4l2_probe_formats: set FAILED...trying to recover original format
v4l2_probe_formats: final format: (00000000) 0 x 0 INTERLACED (line=0x0 size=0x0)
WARNING: zbar video in v4l2_probe_iomode():
system error: USERPTR failed. Falling back to mmap: Invalid argument (22)
_zbar_v4l2_probe: using I/O mode: MMAP
ERROR: zbar processor in _zbar_processor_open():
unsupported request: not compiled with output window support
ERROR: zbar processor in zbar_processor_init():
system error: spawning input thread: Invalid argument (22)
ERROR: zbar processor in zbar_processor_init():
system error: spawning input thread: Invalid argument (22)
Thanks,
Avijit
I am using WinSCP to automate a get from an FTP server. The log shows me that the file was downloaded to the directory I specified but it's not in the directory.
This is the Scheduler param.
/log="C:\TEST\Automation\WinSCP.log" /ini=nul /command "open
sftp://HIDDEN:NOTTHATDUMB#ftplocation.com/ -rawsettings TryAgent=0
AuthGSSAPI=0" "put C:\TEST\Automation\*.pgp -nopreservetime -nopermissions"
"get /Inbox/* C:\TEST\Automation\NewFolder" "exit"
The log reads as if the file was downloaded but cant find file.
Log Output:
> 2018-05-23 12:07:50.077 Script: get /Inbox/* C:\TEST\Automation\NewFolder
. 2018-05-23 12:07:50.077 Listing directory "/Inbox".
> 2018-05-23 12:07:50.077 Type: SSH_FXP_OPENDIR, Size: 15, Number: 523
< 2018-05-23 12:07:50.155 Type: SSH_FXP_HANDLE, Size: 10, Number: 523
> 2018-05-23 12:07:50.155 Type: SSH_FXP_READDIR, Size: 10, Number: 780
< 2018-05-23 12:07:50.233 Type: SSH_FXP_NAME, Size: 164, Number: 780
> 2018-05-23 12:07:50.233 Type: SSH_FXP_READDIR, Size: 10, Number: 1036
< 2018-05-23 12:07:50.280 Type: SSH_FXP_STATUS, Size: 50, Number: 1036
< 2018-05-23 12:07:50.280 Status code: 1
> 2018-05-23 12:07:50.280 Type: SSH_FXP_CLOSE, Size: 10, Number: 1284
. 2018-05-23 12:07:50.280 FILENAME.txt;-;163487;2018-05-23T16:06:50.000Z;3;"200" [200];"100" [100];rw-------;0
. 2018-05-23 12:07:50.280 ..;D;0;1899-12-30T05:00:00.000Z;0;"" [0];"" [0];---------;0
. 2018-05-23 12:07:50.280 Copying 1 files/directories to local directory "C:\Test\Automation\" - total size: 163,487
. 2018-05-23 12:07:50.280 PrTime: Yes; PrRO: No; Rght: rw-r--r--; PrR: No (No); FnCs: N; RIC: 0100; Resume: S (102400); CalcS: No; Mask: NewFolder
. 2018-05-23 12:07:50.280 TM: B; ClAr: No; RemEOF: No; RemBOM: No; CPS: 0; NewerOnly: No; InclM: ; ResumeL: 0
. 2018-05-23 12:07:50.280 AscM: *.*html; *.htm; *.txt; *.php; *.php3; *.cgi; *.c; *.cpp; *.h; *.pas; *.bas; *.tex; *.pl; *.js; .htaccess; *.xtml; *.css; *.cfg; *.ini; *.sh; *.xml
. 2018-05-23 12:07:50.280 File: '/Inbox/FILENAME.txt' [2018-05-23T16:06:50.000Z] [163487]
. 2018-05-23 12:07:50.280 Copying "/Inbox/FILENAME.txt" to local directory started.
. 2018-05-23 12:07:50.280 Binary transfer mode selected.
. 2018-05-23 12:07:50.280 Checking existence of partially transferred file.
. 2018-05-23 12:07:50.280 Opening remote file.
> 2018-05-23 12:07:50.280 Type: SSH_FXP_OPEN, Size: 54, Number: 1539
< 2018-05-23 12:07:50.327 Type: SSH_FXP_STATUS, Size: 40, Number: 1284
. 2018-05-23 12:07:50.327 Discarding reserved response
< 2018-05-23 12:07:50.421 Type: SSH_FXP_HANDLE, Size: 10, Number: 1539
> 2018-05-23 12:07:50.421 Type: SSH_FXP_FSTAT, Size: 10, Number: 1800
< 2018-05-23 12:07:50.515 Type: SSH_FXP_ATTRS, Size: 37, Number: 1800
. 2018-05-23 12:07:50.515 Confirming overwriting of file.
> 2018-05-23 12:07:50.515 Type: SSH_FXP_READ, Size: 22, Number: 2053
< 2018-05-23 12:07:50.890 Status code: 1
. 2018-05-23 12:07:50.890 15 skipped SSH_FXP_WRITE, SSH_FXP_READ, SSH_FXP_DATA and SSH_FXP_STATUS packets.
> 2018-05-23 12:07:50.890 Type: SSH_FXP_CLOSE, Size: 10, Number: 4612
< 2018-05-23 12:07:50.890 Type: SSH_FXP_STATUS, Size: 17, Number: 3589
< 2018-05-23 12:07:50.890 Type: SSH_FXP_STATUS, Size: 17, Number: 3845
< 2018-05-23 12:07:50.921 Type: SSH_FXP_STATUS, Size: 17, Number: 4101
< 2018-05-23 12:07:50.921 Type: SSH_FXP_STATUS, Size: 17, Number: 4357
. 2018-05-23 12:07:50.921 Preserving timestamp [2018-05-23T16:06:50.000Z]
. 2018-05-23 12:07:50.937 Transfer done: '/Inbox/FILENAME.txt' => 'C:\Test\Automation\NewFolder' [163487]
. 2018-05-23 12:07:50.937 Copying finished: Transferred: 163,487, Elapsed: 0:00:00, CPS: 493,279/s
> 2018-05-23 12:07:50.937 Script: exit
. 2018-05-23 12:07:50.937 Script: Exit code: 0
. 2018-05-23 12:07:50.937 Closing connection.
. 2018-05-23 12:07:50.937 Sending special code: 12
. 2018-05-23 12:07:50.937 Sent EOF message
This line of the log tells me it downloaded, however navigating to the save location shows me an empty folder.
. 2018-05-23 12:07:50.937 Transfer done: '/Inbox/FILENAME.txt' => 'C:\Test\Automation\NewFolder' [163487]
Any ideas?
Your get command syntax says: download all files from /Inbox to local folder C:\Test\Automation and save them to file NewFolder. What effectively makes all files overwrite each other. Assuming that NewFolder folder actually does not exist. Had it existed, the download would fail with "is not file" error.
You are also for sure using some rather old version of WinSCP. As recent versions of WinSCP would warn you, that you are probably doing something wrong:
Are you sure you want to transfer multiple files to a single file 'NewFolder' in a directory 'C:\Test\Automation\'?
The files will overwrite one another.
If you actually want to transfer all files to a directory 'C:\Test\Automation\NewFolder\', keeping their name, make sure you terminate the path with a slash.
See also documentation for get command:
The last parameter specifies target local directory and optionally operation mask to store file(s) under different name. Target directory must end with backslash.
Solution:
Add blackslash;
Create NewFolder folder;
And you should also upgrade to the latest version of WinSCP.
I am trying to learn OS Dev and I started building my own kernel based on The Little book about OS Development.
When I loaded the kernel using bochs GRUB complains with:
error 13: invalid or unsupported executable format
The files I'm using:
loader.s
global loader
MAGIC_NUMBER equ 0xBADB002
FLAGS equ 0x0
CHECKSUM equ -MAGIC_NUMBER
section .text
align 4
dd MAGIC_NUMBER
dd FLAGS
dd CHECKSUM
loader:
mov eax, 0xCAFEBABE
.loop:
jmp .loop
link.ld
ENTRY(loader)
SECTIONS
{
. = 0x00100000;
.text ALIGN (0x1000) :
{
*(.text)
}
.rodata ALIGN (0x1000) :
{
*(.rodata*)
}
.data ALIGN (0x1000) :
{
*(.data)
}
.bss ALIGN (0x1000) :
{
*(COMMON)
*(.bss)
}
}
bochsrc.txt
megs: 32
display_library: sdl
romimage: file=/usr/share/bochs/BIOS-bochs-latest
vgaromimage: file=/usr/share/bochs/VGABIOS-lgpl-latest
ata0-master: type=cdrom, path=os.iso, status=inserted
boot: cdrom
log: bochslog.txt
clock: sync=realtime, time0=local
cpu: count=1, ips=1000000
menu.lst
default=0
timeout=0
title First OS
kernel /boot/kernel.elf
commands to execute:
nasm -f elf32 loader.s
ld -T link.ld -melf_i386 loader.o -o kernel.elf
genisoimage -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -A os -input-charset utf8 -quiet -boot-info-table -o os.iso iso
bochs -f bochsrc.txt
My files structure is like this:
os_dev
|--(rest of the files)
|--iso
|-- boot
|-- kernel.elf
|-- grub
|-- menu.lst
|-- stage2_eltorito
The file stage2_eltorito was downloaded from https://github.com/littleosbook/littleosbook/blob/master/files/stage2_eltorito
Michael Petch noticed that B. Kostas was using an incorrect Magic Number for Grub Legacy.
Changing MAGIC_NUMBER equ 0xBADB002 in loader.s to MAGIC_NUMBER equ 0x1BADB002 solved the issue.
I've faced with an interesting behavior of UDP socket with SO_REUSEADDR option set...
If I send 1472 bytes over IP/UDP I get it all in one frame - that' expected...
BUT for 1473 fragmentation differs with/without that option. Does anyone has a clue why that occurs (I'm using Debian 2.6.32-5-amd64)?
SO_REUSEADDR Enabled:
FRAME#1
Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: **1476**
Identification: 0x214d (8525)
Flags: 0x01 (More Fragments)
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..1. .... = More fragments: Set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xd53f [correct]
[Good: True]
[Bad: False]
Source: 173.59.3.22 (173.59.3.22)
Destination: 173.70.1.5 (173.70.1.5)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol (**8** bytes)
Source port: icl-twobase1 (25000)
Destination port: 5000 (5000)
Length: **1481**
Checksum: 0x3cac [unchecked, not all data available]
[Good Checksum: False]
[Bad Checksum: False]
Data (**1448** bytes)
FRAME#2
Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)br/>
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: **45**
Identification: 0x214d (8525)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 1456
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xfa20 [correct]
[Good: True]
[Bad: False]
Source: 173.59.3.22 (173.59.3.22)
Destination: 173.70.1.5 (173.70.1.5)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Data (**25** bytes)
SO_REUSEADDR Disabled:
FRAME#1
Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: **1500**
Identification: 0x214a (8522)
Flags: 0x01 (More Fragments)
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..1. .... = More fragments: Set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xd52a [correct]
[Good: True]
[Bad: False]
Source: 173.59.3.22 (173.59.3.22)
Destination: 173.70.1.5 (173.70.1.5)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol (**8** bytes)
Source port: icl-twobase1 (25000)
Destination port: 5000 (5000)
Length: **1481**
Checksum: 0x3cac [unchecked, not all data available]
[Good Checksum: False]
[Bad Checksum: False]
Data (**1472** bytes)
FRAME#2
Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: **21**
Identification: 0x214a (8522)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 1480
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xfa38 [correct]
[Good: True]
[Bad: False]
Source: 173.59.3.22 (173.59.3.22)
Destination: 173.70.1.5 (173.70.1.5)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Data (**1** byte)
The answer is NO - SO_REUSEADDR doesn't affect fragmentation...
The clue is MTU Discovery and Don't Fragment Flag in IP Header.
In case of sending of 1472 bytes with MTU Discovery = ON:
1500 bytes sent with Don't Frag Flag ON => I get ICMP:
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 4 (Fragmentation needed)
Checksum: 0x90db [correct]
MTU of next hop: 1480
After that the sender does fragmentation for all packets to fit 1480 MTU while route\arp cache info is kept for that receiver (5 min for route and 30 sec for arp - defaults configured on my system).
That's why I saw unexpected for me fragmentation of 1473 bytes (1456 + 25 bytes in two frames) (SO_REUSEADDR was ON in that experiment)...
Next time I tried sending the same 1473 bytes (SO_REUSEADDR was OFF) route\arp cache freed the info about the receiver and I saw that different confusing fragmentation (1480 + 1 bytes in two frames).
Sorry for everyone for the confusion...
However that was pretty cognitive for me to dig into such behavior and clarify things I observed. No miracles here.
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?
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
This is what worked for me:
.foreach($str {!DumpHeap /d -mt 00007ff890e96948 -min 0n126500 -short}){r#$t0= dwo(${$str}+8)*2;.writemem e:\temp\str\${$str}.txt ${$str}+c L? #$t0}