You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Currently, the logging in burn doesn't including logging form dutil because dutil.lib is linked before the log handler is overridden by engine.lib (and burn.exe). There's also a number of log messages - like all of PlanDump (which is only compiled and linked when #DEBUG is defin3ed) - that consume a lot of space and probably aren't useful for a number of scenarios.
Instead, we could use ETW for logging so that logs from dutil, engine/burn and anything using the dutil logging functions can write to a unified log. This also means we can split some of the strings - such as the vast majority of the Logging* helper functions - to mappings in the ETW manifest(s) and reduce the size of the executable for those strings that do not need to be included (if any).
This also has the advantage that trace listeners can gather additional details, like disk consumption upon certain events (like when a package install begins and ends - for which ETW recommends you write operations for) for measuring disk space consumption throughout the entire install, and other handlers for ETW events.
Events can also be written to the Windows Event Viewer, and some computationally-expensive events can be triggered only upon enabling of certain event sources. For functions like PlanDump, these can be entirely different manifests or sets or resources so that the EXE can always write them without the expensive of carrying all those string resources.
See the WIP for details.
Originally opened by heaths
The text was updated successfully, but these errors were encountered:
Currently, the logging in burn doesn't including logging form dutil because dutil.lib is linked before the log handler is overridden by engine.lib (and burn.exe). There's also a number of log messages - like all of PlanDump (which is only compiled and linked when #DEBUG is defin3ed) - that consume a lot of space and probably aren't useful for a number of scenarios.
Instead, we could use ETW for logging so that logs from dutil, engine/burn and anything using the dutil logging functions can write to a unified log. This also means we can split some of the strings - such as the vast majority of the Logging* helper functions - to mappings in the ETW manifest(s) and reduce the size of the executable for those strings that do not need to be included (if any).
This also has the advantage that trace listeners can gather additional details, like disk consumption upon certain events (like when a package install begins and ends - for which ETW recommends you write operations for) for measuring disk space consumption throughout the entire install, and other handlers for ETW events.
Events can also be written to the Windows Event Viewer, and some computationally-expensive events can be triggered only upon enabling of certain event sources. For functions like PlanDump, these can be entirely different manifests or sets or resources so that the EXE can always write them without the expensive of carrying all those string resources.
See the WIP for details.
The text was updated successfully, but these errors were encountered: