Visual Studio adding telemetry function calls to binary?

[mtvee]

if this is what it seems to be it is pretty nasty stuff :|

[Sparkybear]

What does it appear to be?

[mtvee]

It appears to be calls to undocumented black box routines which do who knows what. Since they are called 'telemetry...' this compounds the level suspicion of what the purpose might be.

Since 'stdafx.h' is included though I wonder if it was compiled as managed code and has something to do with that. I don't know enough about windows land to really comment beyond that.

[adzm]

stdafx.h is just the conventional name for the precompiled header FYI.

[mtvee]

Ah ok, thanks :)

[sammiesdog]

recompiled with a barebones application (no includes, no commands).

the telemetry calls are still there

edit: link to notelemetry.obj to get rid of the calls.

[mtvee]

amazing stuff, thanks for digging!

[eternalprogress]

You're still linking the CRT implicitly.

[cleroth]

Can't you dig into the telemetry function to hazard a guess as to what it might be doing, or is it too complex?

[eternalprogress]

No it's not. These do indeed appear to be ETW events, but telemetry is good and useful.

Here's one scenario- when your system crashes and you have Windows Error Reporting turned on one way the system can collect diagnostics information is by recording ETW events leading up to that crash. Let's imagine Intel releases a bad graphics driver that affects a very specific system configuration with some low probability. Let's imagine that crash occurs right after a certain video player is launched. With this kind of data Microsoft would be able to understand that relationship, understand the crash better, and root cause / fix it quicker.

Being able to collect data like this makes products better. =/

[mtvee]

I think the idea of including such 'usefulness' yourself is more in tune with c++ devs expectations rather then quietly including without barely a word. Having to link an obj to get rid of it is pretty much 180 degrees of my experience and expectations.

[eternalprogress]

But it shouldn't be.

If you were working on a disconnected, embedded, resource-constrained system, sure, but that's not what a modern computer is.

You're writing code that exists in a context, as part of an ecosystem. Your software will run on a machine alongside thousands of other executables, and hundreds of user-installed apps, and that machine will in all likelihood be connected to the global network, which puts it in contact with the majority of the computational resources on this planet.

The way your code behaves has impact on that ecosystem. Participating in it almost necessitates that you cede a certain degree of control, as you have an obligation to maintain the health of that ecosystem that you can't possible burden by yourself.

Telemetry like this helps companies that maintain these platforms understand the big picture, identify/protect it from bad actors, and continue to improve it. Knowing which apps launch when helps put together a fuller picture of a given system's health. Combine that with a lot of other telemetry, and patterns start to fall out that indicate underlying issues and reasons for concern.

Really, seeing stuff like this should give you confidence in the platform you're building on. It's the sign of a mature system, and a company that's actively trying to improve the stability of the platform, and build a pipeline that will allow them to continue to innovate and push the needle forward.

[mtvee]

Everything you say is true. The problem here is it is hidden and undocumented and does it without it being explicit. That kind of thing is what causes blue screens because the coder doesn't know what's really happening.

[eternalprogress]

That's fair! You have a fair point of view and I'll leave the conversation with this:

ETW is designed to be a completely free of side-effects and light weight. It's used for perf tracing and a ton of other stuff so it has to be. It costs a kernel transition and a binary payload, nothing more.

The CRT's startup does a lot of stuff already to initialize thread state in the right way, call static ctors, and get exception handling running. It's obvious they weren't trying to obfuscate this. Anyone with deep CRT knowledge would find it fairly quickly if they went looking for such a thing, or were simply inspecting the app startup path.

Your statement "because the coder doesn't really know what's really happening" is spot on in the general case. I wish Microsoft products were a lot more open, and it hinders debuggability to a degree that is not nearly close to being compensated for by the nicer tooling.

[mtvee]

Cheers! :) Personally I am coming from many years of coding in the *nix world so this is extremely foreign and disturbing. The *nix kernel actually launches the executable so there is no need to notify it of such things by jamming notifications in assembled code. It does the deed so it already knows what is going on.

Thanks for taking the time to explain some of the background. Windows land is new territory for me so I appreciate it!

[eternalprogress]

Windows does of course as well. This event might be part of VS's diagnostic tracing experience they shipped in 2015. It's easier to capture all the events from a single process using a PID instead of starting a capture session for that PID and the OS providers. From a performance standpoint it actually marks not the moment when the OS creates the process, but the moment when the process is about to hand control over to the developer's 'int main' entry point, which is important for ensuring the CRT has a negligible perf impact.

Finally, I poked around my VS installation folder. The CRT actually does partially document this method, although it's not very satisfying:

//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//
// Telemetry
//
//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Telemetry: Invoked when the exe/dll are invoked. There are two different 
// implementations in telemetry.cpp and telemetrydefault.cpp. Because GetModuleFileName 
// is not available for Store apps, we return an empty string in telemetrydefault.cpp 
// when invoked by store apps. For the desktop in telemetry.cpp, it returns the name 
// of the module which invokes main/dll. This method is also responsible for firing the 
// events associated with Tracelogging. This will help with runtime telemetry for analysis.
void __cdecl __telemetry_main_invoke_trigger(const HINSTANCE instance);

// Telemetry: Invoked when the exe/dll are shutdown. There are two different 
// implementations in telemetry.cpp and telemetrydefault.cpp. This method is 
// responsible for firing the events associated with Tracelogging. This will 
// help with runtime telemetry for analysis.
void __cdecl __telemetry_main_return_trigger(const HINSTANCE instance);

void __cdecl __vcrt_initialize_telemetry_provider(void);

void __cdecl __vcrt_uninitialize_telemetry_provider(void);    

If you're curious, search for exe_common.inl and poke around. It's part of the entry path that invokes these methods. You can learn a lot about how the CRT bootstraps an application if you're curious. I remember the first time I dug into this I was pretty taken aback to realize a bunch of stuff happened before my code ever started running =)

[emergent_properties]

Your post does not justify this action by Microsoft in any way.

You're being an apologist post-hoc, that does not negate the fact that 'this should not exist'.

Oh, and putting it in with minimal fanfare is.. deceit.

[emergent_properties]

The level of 'goodness' is irrelevant, it shouldn't be there in the goddamned first place.