DLL that was not present in memory despite not being formally unloaded(devblogs.microsoft.com) |
DLL that was not present in memory despite not being formally unloaded(devblogs.microsoft.com) |
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.
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.
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.
Then again, if the bros at Microsoft can prompt ChatGPT (I assume that's what the company forces them to, since it's their investment), then they should be able to do Raymond's work though, but perhaps that doesn't stretch quite that far, somehow?
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.When you're at that level in a company, it's rare that someone would be micromanaging what you work on at all times.
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.