I see posts like this, this deep dive into the call stacks and am always humbled and reminded of the limits of my knowledge about computers and programs.
That's some doggedly determined back tracing to uncover an unexpected heisenbug (loose meaning).
So a total of 46% of the crashes were due to this rogue force-unload of a DLL. This is a case of bucket spray, where a single underlying cause generates a large number of different types of crashes.
Part two:
https://devblogs.microsoft.com/oldnewthing/20260626-00/?p=11...
Part 1 was interesting; it isn't clear why he split that into a Part 2 since it adds little to the story and is a paragraph long.
Might have been an “I need to look into this” segueing into “ never mind”?
> The good news for the shell32 team is that they are off the hook; they are the victim. The bad news is that we don’t know who the culprit is.
The story of software development through the ages.
When you’ve eliminated all possible explanation, it’s time to pack it in.
Oh man, my journey from idealistic “there is always an explanation” youth to “some days it do be like that, and we may never know why” in a nutshell.
I see posts like this, this deep dive into the call stacks and am always humbled and reminded of the limits of my knowledge about computers and programs.
Goes both ways, author probably knows little about FPGA programming, React or PyTorch.
Not a programmer?
I am, for 20 years now. I do embedded stuff too. Still.
That's some doggedly determined back tracing to uncover an unexpected heisenbug (loose meaning).
We've not yet seen sufficient evidence this is any type of heisenbug.
Looking more closely would resolve it one way or the other.