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.GetFormatDescription() throws "The specified resource type cannot be found in the image file." exception #56469

Closed
simon1749 opened this issue Jul 28, 2021 · 10 comments · Fixed by #57804
Labels
area-System.Diagnostics.EventLog good first issue Issue should be easy to implement, good for first-time contributors help wanted [up-for-grabs] Good issue for external contributors
Milestone

Comments

@simon1749
Copy link

simon1749 commented Jul 28, 2021

Description

EventLogRecord.GetFormatDescription() throws "The specified resource type cannot be found in the image file." exception. while querying the Windows EventLog

Here is the StackTrace:

at System.Diagnostics.Eventing.Reader.EventLogException.Throw(Int32 errorCode)
at System.Diagnostics.Eventing.Reader.NativeWrapper.EvtFormatMessageRenderName(EventLogHandle pmHandle, EventLogHandle eventHandle, EvtFormatMessageFlags flag)
at System.Diagnostics.Eventing.Reader.ProviderMetadataCachedInformation.GetFormatDescription(String ProviderName, EventLogHandle eventHandle)
at HMS.Agent.LogInfoRetriever.<>c.b__1_1(EventRecord o) in C:\Users\RemoteUser\Documents\Projects\Code\HMS\HMS.Agent\LogInfoRetriever.cs:line 153
at System.Linq.Enumerable.SelectEnumerableIterator2.ToList() at HMS.Agent.LogInfoRetriever.<>c__DisplayClass1_0.<GetWindowsEventLogs>b__0() in C:\Users\RemoteUser\Documents\Projects\Code\HMS\HMS.Agent\LogInfoRetriever.cs:line 152 at System.Threading.Tasks.Task1.InnerInvoke()
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)

Configuration

  • Which version of .NET is the code running on? -- .net 5
  • What OS and version, and what distro if applicable? -- Windows 10 build 19043.1110
  • What is the architecture (x64, x86, ARM, ARM64)? -- X64
  • Do you know whether it is specific to that configuration? -- No
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Jul 28, 2021
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@danmoseley
Copy link
Member

danmoseley commented Aug 9, 2021

We handle various error codes to cover the case where the formatting of the message fails
https://github.com/danmoseley/runtime/blob/9df3f89f104b20d7b98ebba410463ebc18bdad37/src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/Reader/NativeWrapper.cs#L916-L931

In the case of ERROR_EVT_UNRESOLVED_VALUE_INSERT we just return what we have figuring it has some value.

For ERROR_EVT_MESSAGE_NOT_FOUND, ERROR_EVT_MESSAGE_ID_NOT_FOUND, ERROR_EVT_MESSAGE_LOCALE_NOT_FOUND, ERROR_RESOURCE_LANG_NOT_FOUND, ERROR_MUI_FILE_NOT_FOUND we return null (which does not seem documented). Presumably that at least allows an app to continue enumeration.

In all other cases, like this, we throw. This pattern is unfortunately duplicated across 8 places.

Per this issue ERROR_EVT_UNRESOLVED_PARAMETER_INSERT which it suggests to treat the same as ERROR_EVT_UNRESOLVED_VALUE_INSERT , ie return the string. It seems they debugged and verified that there is a useable string in this case, albeit not fully formatted.

The above issue is encountering another error, ERROR_RESOURCE_TYPE_NOT_FOUND. I do not know whether there is a useable string in this case, but most likely not.

My suggestion is that we treat ERROR_EVT_UNRESOLVED_PARAMETER_INSERT the same as ERROR_EVT_UNRESOLVED_VALUE_INSERT (return the string) and ERROR_RESOURCE_TYPE_NOT_FOUND the same as ERROR_EVT_MESSAGE_NOT_FOUND (return null). And we do this in all 8 places where we have this pattern.

@dotnet/area-system-diagnostics-eventlog @stephentoub seem reasonable? I would not attempt to create a test to trigger this -- it does not seem likely to be unit testable.

@ericstj ericstj removed the untriaged New issue has not been triaged by the area owner label Aug 17, 2021
@ericstj ericstj added this to the 7.0.0 milestone Aug 17, 2021
@ericstj
Copy link
Member

ericstj commented Aug 17, 2021

Moving out since this is existing behavior in .NET 5.0 and doesn't meet the bar for 6.0 at the moment.

My suggestion is that we treat ERROR_EVT_UNRESOLVED_PARAMETER_INSERT the same as ERROR_EVT_UNRESOLVED_VALUE_INSERT (return the string) and ERROR_RESOURCE_TYPE_NOT_FOUND the same as ERROR_EVT_MESSAGE_NOT_FOUND (return null). And we do this in all 8 places where we have this pattern.

This seems reasonable.

@danmoseley danmoseley added good first issue Issue should be easy to implement, good for first-time contributors help wanted [up-for-grabs] Good issue for external contributors labels Aug 19, 2021
@FatTigerWang
Copy link
Contributor

I will deal with this problem

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Aug 20, 2021
@FatTigerWang
Copy link
Contributor

FatTigerWang commented Aug 20, 2021

https://github.com/danmoseley/runtime/blob/9df3f89f104b20d7b98ebba410463ebc18bdad37/src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/Reader/UnsafeNativeMethods.cs#L68

Should I add ERROR_RESOURCE_TYPE_NOT_FOUND here? But I am not sure which error code should be used (perhaps 0x718?)

@danmoseley
Copy link
Member

Should I add ERROR_RESOURCE_TYPE_NOT_FOUND here? But I am not sure which error code should be used (perhaps 0x718?)

winerror.h (on my machine it's in C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared\winerror.h)

// MessageId: ERROR_RESOURCE_TYPE_NOT_FOUND
//
// MessageText:
//
// The specified resource type cannot be found in the image file.
//
#define ERROR_RESOURCE_TYPE_NOT_FOUND    1813L

so 0x715

@danmoseley
Copy link
Member

Is this judgment unnecessary? Because it will never be true.

That is clearly dead code and therefore can be removed.

@danmoseley
Copy link
Member

BTW, it would be nice if there was a way to reduce the 8 places we have this pattern.

@FatTigerWang
Copy link
Contributor

PR #57804

danmoseley pushed a commit that referenced this issue Aug 24, 2021
* fix #56469 handle special error event

* fix #56469 handle special error event

* fix #56469 handle special error event

* fix if keyword followed space code style
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Aug 24, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Sep 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Diagnostics.EventLog good first issue Issue should be easy to implement, good for first-time contributors help wanted [up-for-grabs] Good issue for external contributors
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants