I’ve marveled at this very phenomenon for some time now – my operating system seemingly deciding to give me – the interactive user that purchased the hardware and operating system – seemingly less priority than things running in the background. An astonishing thing in 2017.
The author did an amazing job of troubleshooting this. Let’s hope Microsoft comes up with a patch soon – and learns a larger lesson about not causing serious performance regressions in their software. (Hey, one can dream…)
SendMessageW needs the same lock and was blocked. I think the cursor should be independent? But the window underneath may need messages about mouse position.
I’ve marveled at this very phenomenon for some time now – my operating system seemingly deciding to give me – the interactive user that purchased the hardware and operating system – seemingly less priority than things running in the background. An astonishing thing in 2017.
The author did an amazing job of troubleshooting this. Let’s hope Microsoft comes up with a patch soon – and learns a larger lesson about not causing serious performance regressions in their software. (Hey, one can dream…)
What escapes my understand is why moving the mouse is affected by lock on
NtGdiCloseProcess.SendMessageW needs the same lock and was blocked. I think the cursor should be independent? But the window underneath may need messages about mouse position.
Where do I get a 24-core laptop?
I’m sure he has a Xeon-based workstation tower, not a laptop.
You’re right. He switched to laptop later in article and I got confused.
Not surprising given its windows.
>implying other operating systems don’t have bugs that can cause the pointer to be stuck because something is locking too much
http://kernel.kolivas.org/
MuQSS fixes a lot of this in Linux.