>I asked for the 100 most recent crashes in that third party program and put them into a pivot table so I could see the distribution.
Always wondered if crash reporting is some kind of shady business. It's good to know it does, at minimum, do what it promises and give valuable crash data to MS.
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.
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.
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.
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".
Always wondered if crash reporting is some kind of shady business. It's good to know it does, at minimum, do what it promises and give valuable crash data to MS.
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.
In a wider sloppier sense some use the term for bugs that are hard to pin down and exhibit wide behaviours.
When you're at that level in a company, it's rare that someone would be micromanaging what you work on at all times.