Question: How best to handle ETW (un)registration under MSIX?

[wjk]

Title says it all, really. I don't want to have to use the old ReportEvent API, although I will if I have to, as that API is fully supported under MSIX. ETW enables a far easier-to-browse experience in Event Viewer, as ETW traces are shown in their own list view, while ReportEvent-generated events from all applications are mashed together.

Registration of an ETW .man file isn’t too hard: run wevtutil.exe im path\to\package\etw\app.man /rf:path\to\package\etw\messages.dll /pf:path\to\package\etw\messages.dll from my app’s code. However, there is no good way to call wevtutil.exe um upon uninstall, as MSIX gives no opportunity for an app to run code during the removal process. As such, dangling references in the system to the now-deleted messages.dll file will cause problems the next time the user or an app reads from the ETW database. What is the best way to accomplish this task?

(As an aside, why I am I not using the APIs in TraceLoggingProvider.h, which are far easier to use? Because AFAICT messages created via those APIs aren’t archived in the the Event Viewer, only streamed via realtime trace logging. If I am wrong about this, I’d be happy to hear it.)

[idigdoug]

MSIX does not support register/unregister of the ETW manifest during install/uninstall. This is a functionality gap that the MSIX team is investigating, but there is no support at present. I don't know of any supported way to accomplish your goal of writing to EventLog via ETW. I agree that this is frustrating.

You are correct about TraceLoggingProvider.h not working in this scenario, largely for the same reason. Note that registering a manifest serves two purposes:

1. It configures EventLog to listen for your events (i.e. it tells EventLog: when you see an event with Provider GUID "ABC" and Channel/Keyword set to "ABC/Operational", please record it in the "ABC/Operational" log).
2. It registers the decoding information for Provider GUID "ABC".

When you're using TraceLogging, you don't need purpose 2, but you still need purpose 1, so TraceLogging doesn't solve the problem.