3 ms·

Windows used to have that habit of making the processes CPU starved, and yet claiming the CPU was idle all the time. Since the Microsoft response to the bug wa

Windows used to have that habit of making the processes CPU starved, and yet claiming the CPU was idle all the time. Since the Microsoft response to the bug was denying and gaslighting the affected people, we can't tell for sure what caused it. But several people were in a situation where their computer couldn't finish any work, and the task-manager claimed all of the CPU time was spent on that line item.

gruez 2y ago
I've never heard of this. How do you know it's windows "gaslighting" users, and not something dumb like thermal throttling or page faults?
- belter 2y ago
  Well this is one possible scenario. Power management.... "Windows 10 Task Manager shows 100% CPU but Performance Monitor Shows less than 2%" - https://answers.microsoft.com/en-us/windows/forum/all/windows-10-task-manager-shows-100-cpu-but/00c92238-9382-4946-bc6a-bbc451888b96 https://answers.microsoft.com/en-us/windows/forum/all/window...
- marcosdumay 2y ago
  It's gaslighting because it consists on people from Microsoft explicitly saying that it is impossible, it's not how Windows behave, and the user's system is idle instead of overloaded. Gaslighting customers was the standard Microsoft's reaction to bugs until at least 2007, when I last oversaw somebody interacting with them.
RajT88 2y ago
> Since the Microsoft response to the bug was denying and gaslighting the affected people Well. I wouldn't go that far. Any busy dev team is incentivized to make you run the gauntlet: 1. It's not an issue (you have to prove to me it's an issue) 2. It's not my issue (you have to prove to me it's my issue) 3. It's not that important (you have to prove it has significant business value to fix it) 4. It's not that time sensitive (you have to prove it's worth fixing soon) It was exactly like this at my last few companies. Microsoft is quite a lot like this as well. If you have an assigned CSAM, they can help run the gauntlet. That's what they are there for. See also: The 6 stages of developer realization: https://www.amazon.com/Panvola-Debugging-Computer-Programmer-Programming/dp/B0BQ76LN3T https://www.amazon.com/Panvola-Debugging-Computer-Programmer...
- ziddoap 2y ago
  >If you have an assigned CSAM That's an unfortunate acronym. I assume you mean Customer Service Account Manager.
  - RajT88 2y ago
    Customer Success Account Manager. And I would agree - it is very unfortunate. Definitely in my top 5 questionable acronym choices from MSFT.
- thatfunkymunki 2y ago
  Your reticence to accept the term gaslighting clearly indicates you've never had to interact with MSFT support.
  - RajT88 2y ago
    On the contrary, I have spent thousands of hours interacting with MSFT support. What I'm getting at with my post is the dev teams support has to talk to, which they just forward along their responses verbatim. A lot of MSFT support does suck. There are also some really amazing engineers in the support org. I did my time in support early in my career (not at MSFT), and so I understand well it's extremely hard to hire good support engineers, and even harder to keep them. The skills they learn on the job makes them attractive to other parts of the org, and they get poached. There is also an industry-wide tendency for developers to treat support as a bunch of knuckle-dragging idiots, but at the same time they don't arm them with detailed information on how stuff works.
    - RHSeeger 2y ago
      > What I'm getting at with my post is the dev teams support has to talk to, which they just forward along their responses verbatim. But the "support" that the end user sees is that combination, not two different teams (even if they know it's two or more different teams). The point is that the end user reached out for help and was told their own experiences weren't true. The fact that Dave had Doug actually tell them that is irrelevant.
nerdile 2y ago
As a former Windows OS engineer, based on the short statement here, my assumption would be that your programs are IO-bound, not CPU-bound, and that the next step would be to gather data (using a profiler) to investigate the bottlenecks. This is something any Win32 developer should learn how to do. Although I can understand how "Please provide data to demonstrate that this is an OS scheduling issue since app bottlenecks are much more likely in our experience" could come across as "denying and gaslighting" to less experienced engineers and layfolk
- 1000100_1000101 2y ago
  I'm not the original poster, but I ran into something similar late in Win 7 (Win 8 was in beta at the time). We had some painting software, and we used open-MP to work on each scan-line of a brush in parallel. It worked fine on Mac. On Windows though, if you let it use as many threads as there were CPUs, it would nearly 100% of the time fail before making it through our test suite. Something in scheduling the work would deadlock. It was more likely to fail if anything was open besides the app. Basically, a brush stoke that should complete in a tenth of a second would stall. If you waited 30-60 minutes (yes minutes), it would recover and continue. I vaguely recall we used the Intel compiler implementation of OpenMP, not what comes with MSVC, so the fault wasn't necessarily a Microsoft issue, but could still be a kernel issue. I left that company later that year, and MS rolled out Windows 8. No idea how long that bug stuck around.
  - lostmsu 2y ago
    This sounds like you had a deadlock in the painting software code, that would only reproduce under Windows.

gruez 2y ago

I've never heard of this. How do you know it's windows "gaslighting" users, and not something dumb like thermal throttling or page faults?

belter 2y ago
Well this is one possible scenario. Power management.... "Windows 10 Task Manager shows 100% CPU but Performance Monitor Shows less than 2%" - https://answers.microsoft.com/en-us/windows/forum/all/windows-10-task-manager-shows-100-cpu-but/00c92238-9382-4946-bc6a-bbc451888b96 https://answers.microsoft.com/en-us/windows/forum/all/window...
marcosdumay 2y ago
It's gaslighting because it consists on people from Microsoft explicitly saying that it is impossible, it's not how Windows behave, and the user's system is idle instead of overloaded. Gaslighting customers was the standard Microsoft's reaction to bugs until at least 2007, when I last oversaw somebody interacting with them.

RajT88 2y ago

> Since the Microsoft response to the bug was denying and gaslighting the affected people Well. I wouldn't go that far. Any busy dev team is incentivized to make you run the gauntlet: 1. It's not an issue (you have to prove to me it's an issue) 2. It's not my issue (you have to prove to me it's my issue) 3. It's not that important (you have to prove it has significant business value to fix it) 4. It's not that time sensitive (you have to prove it's worth fixing soon) It was exactly like this at my last few companies. Microsoft is quite a lot like this as well. If you have an assigned CSAM, they can help run the gauntlet. That's what they are there for. See also: The 6 stages of developer realization: https://www.amazon.com/Panvola-Debugging-Computer-Programmer-Programming/dp/B0BQ76LN3T https://www.amazon.com/Panvola-Debugging-Computer-Programmer...

ziddoap 2y ago
>If you have an assigned CSAM That's an unfortunate acronym. I assume you mean Customer Service Account Manager.
- RajT88 2y ago
  Customer Success Account Manager. And I would agree - it is very unfortunate. Definitely in my top 5 questionable acronym choices from MSFT.
thatfunkymunki 2y ago
Your reticence to accept the term gaslighting clearly indicates you've never had to interact with MSFT support.
- RajT88 2y ago
  On the contrary, I have spent thousands of hours interacting with MSFT support. What I'm getting at with my post is the dev teams support has to talk to, which they just forward along their responses verbatim. A lot of MSFT support does suck. There are also some really amazing engineers in the support org. I did my time in support early in my career (not at MSFT), and so I understand well it's extremely hard to hire good support engineers, and even harder to keep them. The skills they learn on the job makes them attractive to other parts of the org, and they get poached. There is also an industry-wide tendency for developers to treat support as a bunch of knuckle-dragging idiots, but at the same time they don't arm them with detailed information on how stuff works.
  - RHSeeger 2y ago
    > What I'm getting at with my post is the dev teams support has to talk to, which they just forward along their responses verbatim. But the "support" that the end user sees is that combination, not two different teams (even if they know it's two or more different teams). The point is that the end user reached out for help and was told their own experiences weren't true. The fact that Dave had Doug actually tell them that is irrelevant.

nerdile 2y ago

As a former Windows OS engineer, based on the short statement here, my assumption would be that your programs are IO-bound, not CPU-bound, and that the next step would be to gather data (using a profiler) to investigate the bottlenecks. This is something any Win32 developer should learn how to do. Although I can understand how "Please provide data to demonstrate that this is an OS scheduling issue since app bottlenecks are much more likely in our experience" could come across as "denying and gaslighting" to less experienced engineers and layfolk

1000100_1000101 2y ago
I'm not the original poster, but I ran into something similar late in Win 7 (Win 8 was in beta at the time). We had some painting software, and we used open-MP to work on each scan-line of a brush in parallel. It worked fine on Mac. On Windows though, if you let it use as many threads as there were CPUs, it would nearly 100% of the time fail before making it through our test suite. Something in scheduling the work would deadlock. It was more likely to fail if anything was open besides the app. Basically, a brush stoke that should complete in a tenth of a second would stall. If you waited 30-60 minutes (yes minutes), it would recover and continue. I vaguely recall we used the Intel compiler implementation of OpenMP, not what comes with MSVC, so the fault wasn't necessarily a Microsoft issue, but could still be a kernel issue. I left that company later that year, and MS rolled out Windows 8. No idea how long that bug stuck around.
- lostmsu 2y ago
  This sounds like you had a deadlock in the painting software code, that would only reproduce under Windows.