Note: The changes discussed in this post are only applicable when running Visual Studio on Windows 8, there are no changes to functionality on Windows 7.
In order to understand why profiling functionality is different on Windows 8, I need to start with a brief overview of the profiler’s implementation. Once you understand how the profiler was implemented in Visual Studio 2010, the behavior differences on Windows 8 should make more sense.
All versions of Visual Studio through 2010 rely on a kernel mode driver to collect data. The driver was originally developed for CPU sampling so it can register for a callback based on CPU clock cycles (the default is 10 million cycles) in order to sample at a regular interval. Data collection for .NET Memory Allocation, and Concurrency profiling were then also integrated into the driver. Instrumentation profiling is a bit different because it does not rely on the driver for the instrumentation data, but it does use the driver to calculate application time (you’ll see why this is relevant below).
The profiling driver was registering for the callback in a way that interfered with a Windows kernel operation; and Windows 8 added a security feature that detects when non-operating system code registers for a callback in this. When this condition is detected, Windows does a bug check that results in a blue screen since the operating system can no longer trust the integrity of the kernel. However the supported way to register for the CPU cycle callback does not allow the callback handler to inspect information about user processes due to security concerns.
Since the driver was now at odds with the enhanced security model we needed to move away from the driver to the new capabilities of Windows added since the driver was first created for Visual Studio 2005.
Unfortunately, given the need to rewrite the collection and analysis components we were not able to release an update to Visual Studio 2010 to fix the issue. Since customers don’t want to blue screen their operating system, Windows 8 added logic to prevent all incompatible versions of the profiling driver from starting (2010, 2008, and 2005).
This means that when you try to start profiling with an incompatible version you will receive the message “Error VSP1398: The monitor was unable to start the VS performance driver. Access is denied. Consider using the /Admin:Driver,Start and /Admin:Security options of VSPerfCmd from an elevated environment.”
Which will result in the following behavior when running Visual Studio 2010 (or earlier) on Windows 8.
In Visual Studio 2012, we had to stop using the now incompatible driver for CPU sampling and instead use ETW (Event Tracing for Windows). However the move to ETW required a complete rewrite of the collection and analysis components for sampling, which unfortunately due to resource constraints meant we did not have time to add all of the existing sampling functionality to the new implementation. This has the following impact when profiling on Windows 8:
Hope this information is useful to some of you and please let me know if you have any questions.