I launch programs by typing <Win> and then a few search characters. Ideally and usually this takes a fraction of a second. On my high-powered Windows-10 laptop it sometimes takes a lot longer. I finally caught this behavior in an ETW trace. The trace shows an almost 15 second delay from when I typed the search query to when anything happens. That is, I typed <Win>, notepad, <Enter> and I saw a blank start menu for 15 seconds, and then notepad launched. Unacceptable.

My most recent blog post was written on my home laptop, which was possible because Chrome is open source. I could find links to the bug, to the relevant change lists, complete with their discussions, and I could use source.chromium.org to search all of the source code. Perhaps most underappreciated, I could use windbg to load the canary version of chrome.dll, and due to the magic of symbol servers the debugger automatically downloaded chrome.dll.pdb - full debug information:
randomascii.wordpress.com/2013/03/09/sym…

Last month I reported about how some third-party code was violating the Windows ABI, not restoring some registers, and this was causing Chrome crashes. A fix to Trellix disk encryption shipped, so I thought the story was over. It wasn't. Apparently enterprise software updates roll out _very_ slowly, so the crash rate actually started to go _up_, despite getting independent confirmation from users that the fix worked. Hmmm.

My Windows laptop was being sluggish. I assumed that something was soaking up all the CPU time so I brought up Task Manager. It said that the CPU (four-core/eight-thread) was only 27% busy, so a naive analysis would say that there was lots of CPU time left over. Heck, the CPU is idling at 0.78 GHz which implies low enough demand that the OS hasn't bothered to ramp it up to full speed. That is seemingly consistent with the 27% CPU usage.
And yet, this analysis is completely wrong.

I continue to be amazed by how many CPU bugs I encounter when analyzing crash dumps at Chrome scale. It has happened enough times that I now have a well tested process:
If an "impossible bug" only happens on one family/model/stepping then it is presumed to be a CPU bug. If the bug is in an emulated CPU then report the bug to the emulator team. Otherwise, monitor. Most CPU bugs are triggered by unknowable rearrangements of code and will go away on the next build.

mov register-> a
mov register-> b

On x86/x64 the store to "b" is guaranteed to not be visible to other processors before the store to "a". On ARM that is not guaranteed.
Many benign x86/x64 data races will becomes real bugs on ARM, and it appears many programmers don't know this If you respect the memory model rules of C++ (or your language of choice) then you are fine. If you don't then in addition to the risk of the compiler rearranging your code, you now have to worry about the CPU rearranging your reads and writes.

Be careful out there.

What MSFT Windows PM decided that a fully utilized CPU running at one-third of maximum speed should be described as 32% usage?
That's broken. The CPU is running at 0.89 GHz but fully utilized! CPU percentage used should be 100% minus idle percentage (which was zero). My laptop was extremely sluggish, the reason wasn't clear, and since Task Manager said my CPU was only 32% utilized I assumed that wasn't the problem. Bad assumption. I was catastrophically CPU starved due to the CPU running slow (for unclear reasons).