Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EventLogRecord.TaskDisplayName throws System.AccessViolationException and termintates the program #100198

Closed
prakashguru opened this issue Mar 24, 2024 · 5 comments · Fixed by #105636

Comments

@prakashguru
Copy link

Description

I am reading forwarded events (WEF) from event log. When I try to read the TaskDisplayName for an event where it does not exists application crashes with access violation exception. This also happens when reading the "KeywordsDisplayNames"

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Repeat 2 times:
--------------------------------
   at Microsoft.Win32.UnsafeNativeMethods.EvtFormatMessage(System.Diagnostics.Eventing.Reader.EventLogHandle, System.Diagnostics.Eventing.Reader.EventLogHandle, UInt32, Int32, EvtStringVariant[], EvtFormatMessageFlags, Int32, Char[], Int32 ByRef)
--------------------------------
   at System.Diagnostics.Eventing.Reader.NativeWrapper.EvtFormatMessageRenderName(System.Diagnostics.Eventing.Reader.EventLogHandle, System.Diagnostics.Eventing.Reader.EventLogHandle, EvtFormatMessageFlags)
   at System.Diagnostics.Eventing.Reader.ProviderMetadataCachedInformation.GetTaskDisplayName(System.String, System.Diagnostics.Eventing.Reader.EventLogHandle)
   at System.Diagnostics.Eventing.Reader.EventLogRecord.get_TaskDisplayName()
   at EventLogCrash.Program.Main(System.String[])

When I checked the event in the event viewer it's xml does not have values for Task and Keywords under RenderingInfo.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-DNS-Client" Guid="{1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}" />
    <EventID>1014</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>1014</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000010000000</Keywords>
    <TimeCreated SystemTime="2024-03-21T23:32:09.577293500Z" />
    <EventRecordID>1590</EventRecordID>
    <Correlation />
    <Execution ProcessID="844" ThreadID="1280" />
    <Channel>System</Channel>
    <Computer>DESKTOP-JP7LKRA.kovo.local</Computer>
    <Security UserID="S-1-5-20" />
  </System>
  <EventData>
    <Data Name="QueryName">wpad</Data>
    <Data Name="AddressLength">128</Data>
    <Data Name="Address">02000000AC106480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</Data>
  </EventData>
  <RenderingInfo Culture="en-US">
    <Message>Name resolution for the name wpad timed out after none of the configured DNS servers responded.</Message>
    <Level>Warning</Level>
    <Task />
    <Opcode>Info</Opcode>
    <Channel>System</Channel>
    <Provider>Microsoft-Windows-DNS Client Events</Provider>
    <Keywords />
  </RenderingInfo>
</Event>

Reproduction Steps

EventLogCrash.zip

The attached sample project contains an evtx file and the C# code tries to read the events from that file and it crashes with access violation.

Note: Make sure to set the current machine's culture to en-US before running the sample. Otherwise it will not try to read the rendering info and wont fail. Setting the cultureinfo in c# code will not work. Changing of UI culture is not required

Reproducible on Windows 11 and Windows Server 2022. Have not checked for other operating systems.

Expected behavior

The correct values should read and application should not crash.

Actual behavior

The application crashes with Access Violation exception.

Regression?

No response

Known Workarounds

No response

Configuration

  • .NET 6.0.28 and 8.0.2
  • Windows 11 and 2022
  • x64
  • I think it should happen to all operating systems.

Other information

No response

Copy link
Contributor

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Mar 24, 2024
@ericstj ericstj removed the untriaged New issue has not been triaged by the area owner label Jul 18, 2024
@ericstj ericstj added this to the 9.0.0 milestone Jul 18, 2024
@ericstj
Copy link
Member

ericstj commented Jul 18, 2024

I can confirm I repro this. This was broken with 97f7e68#diff-5313c21d925c1cc0b1f59c0c9570a98b5b43331b4e52f8188e40e9a19f79c3dfR909
In .NET 7.0. Previously we passed a StringBuilder to the API which would have a buffer of default capacity, then this commit changed to pass NULL/0

Now https://learn.microsoft.com/en-us/windows/win32/api/winevt/nf-winevt-evtformatmessage documents that you can do this, and it normally works -- except when the message formatted has a length of zero. If it does, then EvtFormatMessage still tries to copy one character \0 to NULL and that's the AV. So this is a bug in a Windows API that was uncovered by a change to our interop.

We can workaround this by passing 1 character buffer to the API so that it won't AV.

@ericstj
Copy link
Member

ericstj commented Jul 18, 2024

So all uses of EvtFormatMessage need to pass in a char[1] instead of null.

@prakashguru
Copy link
Author

@ericstj Thanks for the update. By any chance will it be back ported to dotnet 8?

@ericstj
Copy link
Member

ericstj commented Jul 31, 2024

You can use the 9.0.0 nuget package on net8.0 (the package does support net8.0) - that's the quickest way to get the fix.
https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet9/NuGet/System.Diagnostics.EventLog/overview/9.0.0-rc.1.24380.7

This does meet the bar for servicing, so I can initiate a request for backport.

@github-actions github-actions bot locked and limited conversation to collaborators Aug 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants