
MSVC CRT Sneaks in Telemetry by Default? - frozenport
https://www.reddit.com/r/cpp/comments/4hoyzr/msvc_mutex_is_slower_than_you_might_expect/d2thalz
======
xpaulbettsx
Lots of things inside Windows emit ETW events, which is Windows equivalent of
DTrace (basically the entire OS, and .NET), it's super useful for debugging
performance related events. It's not "Telemetry" like Google Analytics, it's
for _you_ to debug your own programs.

The easiest way to view the output of them is via WPA, you can watch some
videos about it at [https://msdn.microsoft.com/en-
us/library/windows/hardware/hh...](https://msdn.microsoft.com/en-
us/library/windows/hardware/hh448170.aspx)

~~~
DominikD
Man, you're fighting uphill battle. This is a typical case of people being
scared of something they don't understand coupled with not willing to learn.
Yesterday[1] I read that RFID tags emit radiation because RF means radio
frequency, so it's harmful. Today I read that ETW is harmful telemetry and MS
injecting code into binaries.

I thought I got over the fact that a lot of people programming on Windows
don't understand its internals. But I didn't. Understanding ETW is essential
on Windows, just like DTrace is a must on Linux or ktrace on OpenBSD. It's
also well documented on MSDN[2]. ETW also typically boils down to a single
check for any listener interested in messages. This info is public and has
been for ages. I guess I'd understand this attitude if there were no real
reasons to bash MS.

But I guess what pisses me the most is the context of that reddit thread.
People complain about mutex performance and show code where they mutex vector
accesses. This kind of code does not belong in performance critical game code.
"Hey, I've got a salad to make, what tools do I need? I've got a hammer but
these veggies are not a nail. But I'm sure if I take two hammers to the task
my problem suddenly changes to nailing things together!"

For Pete's sake, if a slight performance drop in mutex performance of user
mode code hogs your application, you're mutexing too much. Your code is a
problem, not a mutex. And if you're using single threaded STL primitives for
communication between threads you have no right to complain about CRT
performance. None. This lack of intellectual curiosity in people sinks my
heart.

Rant out. :S

[1] not on HN though, thankfully [2] well by MSDN standards at least - ETW
documentation is hard to grok without referencing sample code in the Windows
SDK

~~~
pjmlp
Another good example was when Microsost introduced C++/CX, their language
extensions for creating WinRT components in C++.

Lots of devs were up in arms that C++ was going to be managed in the new WinRT
world, just because C++/CX syntax is based on C++/CLI.

Microsoft had to do lots of sessions to clarify that, and I bet even today
there are developers that don't get the difference between C++/CX and C++/CLI.

------
Sanddancer
A different post showing exactly what the info is and where it goes (hint:
nowhere):

[https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_a...](https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/)

There is no info going in and out, it just adds hooks to the runtime for you
to add telemetry if you want it.

~~~
userbinator
_you can link notelemetry.obj and the calls are removed_

It's still a ridiculous idea to make this the default. Rather, it should be
something you opt-in to if you want to debug, more like

 _you can like telemetry.obj and the calls are inserted_

~~~
forrestthewoods
Why is this comment down voted? Is it not a good suggestion? Opt-in to
telemetry vs opt-out seems like a pretty reasonable thing to choose? Is that
not true?

~~~
userbinator
_Is that not true?_

Microsoft recently doesn't seem to think so.

------
ryuuchin
Just to mirror what's in the reddit thread the quick "fix" for this is to
simply link to notelemetry.obj just as you would with the other small obj
files included in the CRT lib directory[1]. Oddly notelemetry.obj is missing
from their list.

[1] [https://msdn.microsoft.com/en-
us/library/ms235330.aspx](https://msdn.microsoft.com/en-
us/library/ms235330.aspx)

~~~
tacos
[https://gist.github.com/aicpp](https://gist.github.com/aicpp)

------
chris_wot
I was looking at the C Runtime Library the other day and found the following
series of article on how to remove msvcrt.lib:

[https://hero.handmade.network/forums/code-
discussion/t/94](https://hero.handmade.network/forums/code-discussion/t/94)

Basically, the entrypoint for Win32 isn't actually WinMain, but
WinMainCRTStartup. To replace it you need to reimplement a few things,
including an implementation of memcpy() and memset(), some allocation routines
for 32 bit code under 64 bit systems and some floating point routines.

Curious to know what the new universal runtime loads up. I'd love Microsoft to
be a bit more open about what their C runtime actually does before a program
linked to it loads. Of course, perhaps they are, and I've missed it.

 _Edit:_ looks like someone was pissed about this lack of documentation in the
beta Vususl Studio beta:

[http://levicki.net/articles/2015/12/03/RANT_Microsoft_Visual...](http://levicki.net/articles/2015/12/03/RANT_Microsoft_Visual_Studio_2015.php)

~~~
asveikau
> I'd love Microsoft to be a bit more open about what their C runtime actually
> does before a program linked to it loads. Of course, perhaps they are, and
> I've missed it.

The source code to the CRT ships with Visual Studio.

> Basically, the entrypoint for Win32 isn't actually WinMain, but
> WinMainCRTStartup.

The entry point is whatever appears in the PE header and you can name it
whatever you want. It just so happens that the default linker settings point
it at CRT, which calls into you. You can change this with linker settings.

~~~
chris_wot
Ya, I didn't explain that as well as I might have. That is correct :-)

------
drucken
Note this Reddit comment by what appears to be a couple of MS devs:

 _(fourbadcats) Indeed. This sure better be an oversight of something not
disabled when transitioning from release candidate to RTM. We will lose
credibility with our customers if we claim that our application does not
collect any usage data when this is going out over the wire. I noticed that
notelemetry.obj is not present with VS 2015 Update 1 so this may have been
introduced with Update 2. Let 's hope it's gone in Update 3._

and this too:

 _(spongo2) Let me gather some details_

However, this is definitely highly disconcerting.

~~~
StephanTLavavej
The first comment, from fourbadcats, is apparently from a customer of MS (I
don't know who they are), referring to their customers in turn. The second
from spongo2 is VC's dev manager, my double boss. (I know very little about
this topic as the STL's senior developer; this stuff is in the vcruntime layer
below the STL.)

~~~
frik
Yes ask your boss.

> We will lose credibility with our customers if we claim that our application
> does not collect any usage data when this is going out over the wire.

Microsoft wasted Win10 and Office 2016 already (and sneaked it into newer
Win7&8 updates). It would have been such a great chance after the
misguided/failed Win8, but then MS decided to add invasive telemetry and other
phone home crap incl whitelisting IPs and URLs in kernel mode network layer,
with no way to deactivate all of it - don't even think MS respects you as a
end consumer (you are their sheep and loose control of your PC) and not even
as enterprise customer nor with LTSB (except you request a custom build of the
network stack).

------
_RPM
So, MSFT is injecting code into a binary? This probably won't be a popular
opinion here, but this does seem like a pretty good definition of malware to
me. It doesn't make it okay that just because it's MSFT they can get away with
it.

~~~
Aelinsaar
I don't know if it's malware, but it's something really close.

~~~
HillRat
Or, to put it another way, it's Microsoft saying, "Hey, you probably want
local event tracing in your application, so we enabled it by default." Been a
while since I've done Windows dev (and I'll install VS Beta to check this
out), but it might be as simple as the default project skeleton including an
instrumentation manifest whose presence adds EWT tracing to the build chain.
It's basically Windows' syslog equivalent, so unless Win10 is sending back all
EWT eventing as a matter of course -- which, Win10 being a privacy carwreck,
it might well be! -- I'm not too alarmed.

~~~
Aelinsaar
I don't think it's a reason to be alarmed regardless of the intention, it's
just one of those "Huh, isn't that funny?" moments IMO.

------
JustSomeNobody
Data isn't free for end users; it's capped for a lot of them. While I get that
devs can 'fix' this I wonder how many will in practice.

~~~
Sanddancer
The data stays local at most. It's a hook for devs to add telemetry, not
telemetry that goes to the mothership or anything like that.

------
jrcii
So much for "developers developers developers developers developers"
[https://www.youtube.com/watch?v=Vhh_GeBPOhs](https://www.youtube.com/watch?v=Vhh_GeBPOhs)

