NLog.Etw扩展无法输出ETW事件的技术求助

Let's break down the possible issues with your setup and walk through actionable troubleshooting steps:

1. Version Compatibility Mismatch #

Your NLog version (4.0.1) is significantly older than the NLog.Etw extension (4.1.0). NLog extensions often require a minimum compatible NLog version, and NLog 4.0.1 lacks several extension support improvements introduced in later 4.x releases (like more reliable assembly loading and target initialization logic).

• Fix: Upgrade NLog to at least 4.5.0 (the earliest version confirmed to work with NLog.Etw 4.x), or align the NLog.Etw version with your existing NLog release (though newer NLog versions offer better stability and bug fixes).
• Verify: After upgrading, check if the NLog.Etw assembly loads correctly using NLog's internal logging (see step 5).

2. Incorrect Target Configuration #

You're using the ExtendedEventTracing target, but for NLog.Etw 4.x, the standard target type is Etw (or EtwEvent for newer iterations). The providerId attribute you added isn't documented because it's not the correct property for this target—instead, use providerName (a friendly identifier) or let the extension register a default provider automatically.

• Updated Target Example:

  <target xsi:type="Etw" name="nlogetw" providerName="MyNLogEtwProvider" layout="${longdate}|${uppercase:${level}}|${message}${onexception:|Exception occurred\:${exception:format=tostring}}"/>
  

• Note: If you insist on using ExtendedEventTracing, confirm your specified provider GUID is registered in the system. Run logman query providers in an elevated command prompt to check if the GUID exists—if not, the target can't publish events.

3. Permissions Issue #

ETW event publishing requires elevated privileges on Windows Server 2012 R2. Your application might lack the rights to register the ETW provider or send events to the system.

• Fix: Run your application as an Administrator, or grant the application's service account the "Manage auditing and security log" user right (via Local Security Policy > Local Policies > User Rights Assignment).
• Verify: Test by launching your app manually with admin rights and re-running the WPR capture.

4. Log Rule Validation #

Double-check that your Class* loggers are actually generating events at the Debug level or higher (since your rule uses minlevel="Debug" for the ETW target).

• Verify:
  • Confirm the console or filelog targets receive the same Class* logger events at Debug level. If not, adjust your logger configuration or ensure your code is logging at the correct level.
  • Temporarily lower the minlevel to Trace for the ETW rule to rule out level filtering:

    <logger name="Class*" minlevel="Trace" writeTo="nlogetw"/>
    

5. Enable NLog Internal Logging #

NLog's internal logging will reveal if the NLog.Etw extension loads correctly, if the target initializes without errors, or if there are issues during event publishing.

• Add to your nlog.config:

  <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" internalLogFile="nlog-internal.log" internalLogLevel="Debug">
    <!-- rest of your existing config -->
  </nlog>
  

• Check the log file: Look for lines like Loading assembly NLog.Etw or errors related to the nlogetw target (e.g., "Could not load type" or "Invalid property 'providerId'").

6. Validate WPR Capture Configuration #

Your WPRP file structure looks correct, but confirm the provider GUID matches what NLog is actually registering.

• Check Registered Providers: Open an elevated command prompt and run:

  logman query providers
  

  Search for the GUID ca2d86bc-1b67-419d-9048-962fa24d2cd2. If it doesn't appear, the NLog.Etw target isn't registering the provider successfully.
• Alternative Capture Method: Use Event Viewer for simpler testing:
  1. Open Event Viewer > Applications and Services Logs > Microsoft > Windows > Event Tracing > Debug.
  2. Enable logging for this channel, then run your application. Check if events appear here.

7. Assembly Loading Issues #

Ensure the NLog.Etw.dll is present in your application's output directory (bin/Debug or bin/Release). If you're using a custom logging assembly (MyCustomLoggingAssembly), make sure it doesn't conflict with NLog.Etw's assembly loading.

• Verify: Check the bin folder for NLog.Etw.dll. If missing, re-install the NuGet package (or copy the DLL manually if using a standalone assembly).

内容的提问来源于stack exchange，提问作者BustaH