0.6.0 introduced error about evtx

[forensicmatt]

Interesting, it works fine with the 0.6.0 evtx_dump using evtx_dump.exe --separate-json-attributes -o jsonl "E_ShadowCopy6_windows_system32_winevt_logs_Microsoft-Windows-CAPI2%4Operational.evtx".

Maybe it is something I am doing though the library. It's just strange that it works fine for me with 0.5.1 but panics on 0.6.0 using the library.

I will see if I can pin point with example code.

[forensicmatt]

I am sorry, I was not using the 0.6.0 bin. The 0.6.0 bin does error out using the following:

>evtx_dump.exe --separate-json-attributes -o jsonl "E_ShadowCopy6_windows_system32_winevt_logs_Microsoft-Windows-CAPI2%4Operational.evtx"
thread 'thread '<unnamed><unnamed>' panicked at '' panicked at 'It can only be an object or null, and null was coveredIt can only be an object or null, and null was covered', ', src\libcore\option.rssrc\libcore\option.rs::11661166::55

stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: BaseThreadInitThunk
  29: RtlUserThreadStart
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: <unknown>
  29: <unknown>
  30: <unknown>
  31: <unknown>
  32: BaseThreadInitThunk
  33: RtlUserThreadStart

[omerbenamram]

Huh! this is a regression. I'll fix it and push 0.6.1.
Sorry about that!

EDIT: this seems to only happen with --seperate-json-attributes.

[omerbenamram]

Fixed with #66.
This regression was introduced because 0.6.0 is smarter about nodes that have multiple XML nodes with the same name (when converting to JSON), so some unexpected paths were hit twice in places where this shouldn't have happened.

Also changed all tests to cover this flag now.

Let me know if anything else is not working with this release :)

[forensicmatt]

Thanks! Just curious, what are garbage nodes considered?

[omerbenamram]

@forensicmatt it's stuff like this.

Notice the stuff between the nodes, I did notice them while adding support for EntityRef notes.

From what I've compared against the windows event explorer, they never contained any data that wasn't garbage (/ etc).
The data is there by all means, I'm just not certain of why it's there.

<URLCacheFlushInfo></URLCacheFlushInfo>&amp;quot&amp;<URLCacheResponseInfo></URLCacheResponseInfo>