1

I have build a custom EventSource by using Visual Studio 2015 and the nuget package Microsoft Event Source Library (latest version 1.1.28).

I have installed the manifest by using wevtutil.exe on my Windows 8.1 work station and on a Windows Server 2012 R2.

In general this EventSource works on both machines, it is fetching events which are visible in the Event Viewer. Just on Windows Server 2012 R2 the output looks a little bit crappy in the Event Viewer.

When I install it on my dev workstation it works fine. Here is an example for my sample UnhandledException event:

enter image description here

When I install it on Windows Server 2012 R2 the Event Viewer is completely messed up as you can see in this screenshot:

enter image description here

Does anybody know why this is happening? How can I fix it?

Edit:

I am able to reproduce it with the Microsoft EventSource Library Samples by following these steps:

  1. Create a new console application project in Visual Studio and name it "DemoEventSource"
  2. Install Microsoft EventSource Library Samples from nuget
  3. Run the EventLogEventSourceDemo. You can comment out all the other examples in "EventSourceSamples\00_AllSamples.cs" because they are not relevant for this issueenter image description here
  4. Press F5 to run it, and follow the instructions, Event Viewer will open automatically. On my workstation it works fine: enter image description here
  5. In the next step I have created a virtual machine on Azure with Windows Server 12 (issue occures on Windows Server 2012 R2 and Windows Server 2012) and deployed the test application there. The result is messed up as described in my example above: enter image description here
Philipp Stauss
  • 721
  • 7
  • 22
  • Philipp, Let's start with the simple stuff. EventViewer doesn't (at least in earlier versions of Windows) support in-line manifests as created by EventSource. Instead it uses a specific manifest that you need to install on the machine where EventViewer is running. Did you do that step? Yes or now sort of splits the rest of the conversation. Thanks for catching me on Twitter. I don't spend much time here, but i marked this thread. Kathleen – Kathleen Dollard Jul 05 '16 at 14:30
  • Hi Kathleen. I have updated the question details. I have installed the manifest in both scenarios, on a Windows 8.1 and on a Windows Server 2012 R2 machine. Just on a Windows Server it looks really strange. I have tried several Windows Server instances. Always the same result. – Philipp Stauss Jul 06 '16 at 06:47

1 Answers1

0

Without substantial testing, I can't say with 100% certainty, but this looks like a bug. EventSource does some unusual (but legal) things with keywords. For example, the manifest says "event ID 72 uses keyword 0x12", but when you actually look in the ETL file, the event actually uses keyword 0xf000012 (or something like that). This behavior is legal but rare. In some versions of tdh.dll, this caused the event to be decoded incorrectly. Event Log uses tdh.dll to decode the events.

IIRC, Windows 8.1 got a fix for this bug, but I don't think the fix made it to earlier versions.

Doug Cook - MSFT
  • 121
  • 6
  • which fix? 8.1 and 2012 R2 are the same version so the fix can be applied to both – magicandre1981 Jul 13 '16 at 04:11
  • is it this fix? https://support.microsoft.com/en-us/kb/3080149 which fixes this: **Fixes an occasional event decoding issue in the Trace Data Helper (TDH) TdhGetEventInformation function that caused Event Tracing for Windows (ETW) events created by using the .NET Framework 4.6** – magicandre1981 Jul 13 '16 at 04:20
  • I think KB3080149 is fixing something else. This fix was already installed on my Azure VM when I started to test my EventSource. – Philipp Stauss Jul 13 '16 at 06:33
  • Doug, have you figured out which fix it is? – magicandre1981 Jul 19 '16 at 15:24
  • I'm not an expert at looking through the KB articles. I know this was found and fixed during development of Windows 10. I'm not seeing any corresponding fix back-ported to 8.1, so it might not have been back-ported. – Doug Cook - MSFT Aug 04 '16 at 00:22
  • There was another issue in tdh.dll related to how TDH does caching of decoded event metadata. I suspect that was the fix in KB3080149. – Doug Cook - MSFT Aug 04 '16 at 00:27
  • Ok. Does it mean there won't be a fix for this issue? – Philipp Stauss Aug 08 '16 at 09:00
  • 1
    I don't know of any current plan to fix this in earlier versions of Windows. You could open a request with Microsoft product support services if this is important to you. You might also be able to tweak your manifest a little bit to make the event come out correctly -- IIRC, this bug only shows up if the total size of a certain combination of strings in the manifest has an even length, so tweaking the strings in your event might fix it. – Doug Cook - MSFT Aug 10 '16 at 23:47