String values in evtx files sometimes contain embedded newlines, which are CRLF because they're written on Windows. In the attached exmaple, the value starting at offset 0x19472 is one such:
Application.evtx.gz
C:\Windows\System32\LogFiles\Scm\SCM.EVM
C:\Windows\servicing\Sessions\Sessions.xml
C:\Windows\System32\LogFiles\Scm\SCM.EVM
C:\Windows\Logs\CBS\FilterList.log
C:\Windows\Temp\WER6E75.tmp.WERInternalMetadata.xml
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Critical_10.0.10586.0_1_58b6cec169647e71609bf1745452c849866c6e89_00000000_cab_12bc6e95\memory.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Critical_10.0.10586.0_1_58b6cec169647e71609bf1745452c849866c6e89_00000000_cab_12bc6e95\minidump.mdmp
evtxexport writes these string values to stdout witout altering them. Because stdout is a text stream, it translates \n to the platform-appropriate line ending. On Windows the \r\n which ends each line in the above string has its \n translated to \r\n, while on Unix the \n remains an \n. The result is that in evtxexport's output, string values with embedded line endings have \r\r\n in them on Windows and \r\n in them on Unix---neither of which is a platform-appropriate line ending.
The correct thing to do is to translate the \r\n in these strings to \n before writing them to stdout, as then stdout will produce the platform-appropriate line ending. (Note that switching stdout to binary mode would not fix the problem, as in that case the line endings would remain \r\n on Unix.)
String values in evtx files sometimes contain embedded newlines, which are CRLF because they're written on Windows. In the attached exmaple, the value starting at offset 0x19472 is one such:
Application.evtx.gz
evtxexport writes these string values to stdout witout altering them. Because stdout is a text stream, it translates
\nto the platform-appropriate line ending. On Windows the\r\nwhich ends each line in the above string has its\ntranslated to\r\n, while on Unix the\nremains an\n. The result is that in evtxexport's output, string values with embedded line endings have\r\r\nin them on Windows and\r\nin them on Unix---neither of which is a platform-appropriate line ending.The correct thing to do is to translate the
\r\nin these strings to\nbefore writing them to stdout, as then stdout will produce the platform-appropriate line ending. (Note that switching stdout to binary mode would not fix the problem, as in that case the line endings would remain\r\non Unix.)