Technical interpretion of content of an ST22

[Former Member]

Hi all,

I am trying to build a test case for an intermittent problem that causes short dumps.  The short dump is very sensitive to the set of data in an input table.  If that set grows or shrinks, the problem disappears.  The input data ends up processed and unidentifiable.  Given a short dump, I need to be able to work back to the input data.

I have had luck that it occurred with 3 lines of input.  The ST22 includes 3 lines of the input table.  There are 3 columns, 2 GUIDs and a 6 character field.

I am looking at the lines of output and trying to work back to the input lines.  I have one line of input because the short dump mentions one of the GUIDs and I can work out the other.

The lines in the short dump look crazy since there are 32 bytes of binary followed by 6 ASCII characters

The one line I know must appear is.

001999D86EAC1ED69DB70D5BA5FFC404 5CF3FCDE03781ED69DB7C0BE36871F6E MRH015

Here is the extract.  I assume the V0 is its interpretation of the string as ASCII.  The following X0 lines I think ought to be the hexadecimal version of the line, but not that I can see.  At the very least the line then would end in the hex version of MRH015, 4D 52 48 30 31 35

Does anyone know how to interpret this?  Am I totally misunderstanding the information being conveyed?

TH ----- 1st level extension part -----

TH regHook                 = 0x0000000000000000

TH collHook                = 0x0000000000000000

TH ext2                    = 0x0000000000000000

V0 ##砃혞랝뻀蜶渟ᤀ#걮혞랝嬍ﾥӄMRH015

X0 5F019C31096190AC454333

X0 CC3ED06F09EEDD54D28015

X0 FD7DBB861DADB5F0000000

X0 3E867E7E98C67BF4000000

V0 ##砃혞랝뻀蜶渿ᤀ#걮혞랝렣瑄䰄MRH015

X0 5F019C3309619240454333

X0 CC3ED06F09EED344D28015

X0 FD7DBB861DADBB74000000

X0 3E867E7E98C6784C000000

V0 ##砃혞랝#밒###砃혞랝Ᵹ녎꺞MRH015

X0 5F019E155F019749454333

X0 CC3ED72FCC3EDDEED28015

X0 FD7DBFBDFD7DBABA000000

X0 3E8675CC3E86771E000000

[Former Member]

I found another section where I can see the 6 characters in the hex lines.  I split the line at the start of the ASCII characters in Unicode. I split at least 2 at the start of one of the GUIDs.  So, I guess I answered it myself.  Sorry to bother.

##砃혞랝뻀蜶渟ᤀ#걮혞랝嬍ﾥӄMRH015

5CF3FCDE03781ED69DB7C0BE36871F6E 001999D86EAC1ED69DB70D5BA5FFC4044D

0052004800300031003500

##砃혞랝뻀蜶渿ᤀ#걮혞랝렣瑄䰄MRH015

5CF3FCDE03781ED69DB7C0BE36873F6E 001999D86EAC1ED69DB723B84474044C4D

0052004800300031003500

##砃혞랝#밒###砃혞랝Ᵹ녎꺞MRH015

5CF3FCDE03781ED69DB7E7F512BC5FDC5CF3FCDE03781ED69DB77DA74EB19EAE4D

0052004800300031003500

[Sandra_Rossi]

The question has been answered but here's just the explanation of your technical view. First of all, you have a Unicode system, as you have 4 lines "X0" (if you had an ASCII system, you would have only 2 lines "X0"). The line "V0" is the character representation, and the "X0" lines are the hexadecimal representation of every character above (in the line "V0"). "X0" lines must be read vertically, then horizontally. The hexadecimal value of the first character is made of the 4 digits below the character, i.e. 5CF3 in the example below:

V0 ##砃혞랝뻀蜶渟ᤀ#걮혞랝嬍ﾥӄMRH015 
X0 5F019C31096190AC454333 
X0 CC3ED06F09EEDD54D28015 
X0 FD7DBB861DADB5F0000000 
X0 3E867E7E98C67BF4000000

PS: on my laptop, there's a rendering problem hex values are not exactly below the characters, as the width of Chinese characters is larger than other characters.