Windows is known to have reduced timer resolution, though it can't have the common Unix problem of only delivering profiling signals after a full time slice because the Windows APIs couldn't express a bug like that.
I don't see any Windows profiling failures on the dashboard. Could this be related to whatever CL produced that failure?
Go profiler is not using signal on Windows. It is running on a separate dedicated OS thread. The thread is running with THREAD_PRIORITY_HIGHEST to make it as reliable as possible, but ... Also the thread is only started on demand - maybe there is some latency to that when CPU is busy.