What MSFT support policy do you need to have the legendary Raymond Chen take a look at it?
I say this because we've reported a bunch of Windows bugs (mainly running Windows under virtualization) and getting them to pay attention at all is an up-hill battle.
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.
As someone who has debugged his fair share of tricky low-level issues, the parts that I find impressive in his blog posts are things such as "then we look at the bytes in memory and oh yeah, this looks like an exception record". I would usually not think to do that (or be able to recognise it as easily as I presume he did).
I have done everything from desktop apps to web apps and a bunch in between. Regular debugging is good enough for me. Never had the need to go down into call stack level.
Even with embedded programming, regular C debugger has always been enough.
Given his seniority, it could also be that he picks whatever bugs he wants to work on. Whether that is from personal interest, frequency of crashes or any other criteria.
When you're at that level in a company, it's rare that someone would be micromanaging what you work on at all times.
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.
https://devblogs.microsoft.com/oldnewthing/20260626-00/?p=11...
But I would hope that some kind of reverse debugger triggered on one of these crashes would make it pretty simple to say "who wrote this 01".
The story of software development through the ages.
I say this because we've reported a bunch of Windows bugs (mainly running Windows under virtualization) and getting them to pay attention at all is an up-hill battle.
If you have to ask, you can't afford it.
Or do you mean all the windows specific stuff etc, I guess I was more imaging the call stack etc.
No insult was intended XD
Even with embedded programming, regular C debugger has always been enough.
When you're at that level in a company, it's rare that someone would be micromanaging what you work on at all times.
In a wider sloppier sense some use the term for bugs that are hard to pin down and exhibit wide behaviours.