TMF vs PDBs for wpp

Is there a specific advantage of having TMF files over using PDBs to get WPP traces?
Can I distribute the TMFs and Control GUIDS to customers without having to share the PDBs perhaps?

If you have concerns about releasing a PDB, then by all means go with TMFs. But TMFs are for decoding. Do your customers need to decode or just collect traces and send them back to you (in which case control guids are the only thing they are asked to consume)? TMFs have the underlying problem that the debugger doesn’t know how to find them and it can be frustratingly hard to pair the right TMFs with the module. The advantage of embedding TMF data in the PDB is the debugger knows how to find the right one and the TMF piggy backs for free.

@Doron_Holan said:
Do your customers need to decode or just collect traces and send them back to you (in which case control guids are the only thing they are asked to consume)?

It is a bit tricky for us. We purchased a 3p library to statically link with our driver (which has been around for decades now). The 3p lib didnt come with sources, and has it’s own control guid for the WPP.

This kind of integration philosophy is bound to have problems (and I have mentioned it to upper management) but this is what they want to do. Since giving the PDBs out means we also end up giving out private info to the 3P vendor in case they want to analyze a dump (and I have no idea how that will work in the future), as of now the goal is for them to have the ability to decode their own traces.

As an aside, this old legacy driver of ours is still using the command line styles sources based build environment. The sources file has the WPP settings in it, but how do I add TMF support to that?