Ok, let's try another thing. Can you re-generate the _same_ XML in the previous example using URLESCAPE on that field this time? The second parameter doesn't matter.

Downloaded and installed 2.2.10 Reran and have the same problem.

Downloaded and installed 2.2.10. Reran and still have the same problem.

There actually was a bug in the XML output format exactly as you describe. 2.2.10 has been released months ago, I'm 99% sure it will solve your problem. Download it from www.microsoft.com and see if it solves the problem.

It's 2.2.9. That doesn't sound like it would be added during XML creation because the character, from what I can tell, is in the original event log.

Hey, hold on a sec - what Log Parser version is this? 2.2.9 or 2.2.10? (execute "logparser.exe" with no args and look at the first line dumped out) There was a bug time ago in the XML output format that would cause it to append extra chars in fields...

First, I did try using -oCodepage:-1, and it didn't work. I'm attaching an XML file that should illustrate the problem. The workstation field was parsed out of the strings field on 680 events generated from a particular computer in the security log. The last character in that field appears to change...

Metzlerd, do you mind posting the XML file that Log Parser is unable to parse? Also, have you tried using -oCodepage:-1 when creating the XML file?

Daniel Many thanks for your help, not sure how far i would have got without it. I'll try your suggestion in the next few days - no chance tonight. cheers Roger

Interesting... So the problem is this. You have three types of "row nodes": FWConfig, ProxyMatch & ProxyHTTPReq. Since they have different element names, LP does not let their attributes mingle. Any commonly named attributes in them are renamed with a counter suffix. If you execute the field listing...