| ▲ | DLL that was not present in memory despite not being formally unloaded(devblogs.microsoft.com) |
| 68 points by ibobev 5 hours ago | 28 comments |
| |
|
| ▲ | masfuerte 3 hours ago | parent | next [-] |
| Part two: https://devblogs.microsoft.com/oldnewthing/20260626-00/?p=11... |
| |
| ▲ | Someone1234 2 hours ago | parent [-] | | 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. | | |
| ▲ | londons_explore an hour ago | parent | next [-] | | I assume the fact it is a third party application means debugging gets harder, and the business case for doing so is weaker/none. 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". | |
| ▲ | taneq 2 hours ago | parent | prev [-] | | Might have been an “I need to look into this” segueing into “ never mind”? |
|
|
|
| ▲ | zabzonk 3 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | brookst 2 hours ago | parent [-] | | When you’ve eliminated all possible explanation, it’s time to pack it in. | | |
| ▲ | zabzonk 11 minutes ago | parent | next [-] | | Or, as the original article suggests, blame someone else. | |
| ▲ | taneq 2 hours ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | rwmj 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | hackyhacky an hour ago | parent [-] | | > What MSFT support policy do you need to have the legendary Raymond Chen take a look at it? If you have to ask, you can't afford it. |
|
|
| ▲ | 1970-01-01 42 minutes ago | parent | prev | next [-] |
| >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. |
|
| ▲ | kumarvvr 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | Panzer04 2 hours ago | parent | next [-] | | Not a programmer? | | |
| ▲ | kumarvvr 2 hours ago | parent [-] | | I am, for 20 years now. I do embedded stuff too. Still. | | |
| ▲ | Panzer04 2 hours ago | parent [-] | | I'm a bit surprised you don't run into things like this then :). Do you use GDB and the like at all? 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 | | |
| ▲ | FartyMcFarter an hour ago | parent | next [-] | | 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). | |
| ▲ | kumarvvr 2 hours ago | parent | prev [-] | | 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. |
|
|
| |
| ▲ | dist-epoch 2 hours ago | parent | prev [-] | | Goes both ways, author probably knows little about FPGA programming, React or PyTorch. |
|
|
| ▲ | IChooseY0u 19 minutes ago | parent | prev | next [-] |
| Windows COM is super weird and way over engineered. |
| |
| ▲ | rpeden 10 minutes ago | parent [-] | | I actually think COM is an amazing bit of engineering considering its intended use case. It still feels like a much more advanced way of sharing compiled libraries between different languages than the current default of "export a C ABI and communicate across the barrier via primitive sticks and stones." COM isn't perfect but I still find it impressive especially since COM/OLE are 40 years old at this point. |
|
|
| ▲ | defrost 3 hours ago | parent | prev | next [-] |
| 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.
|
| |
| ▲ | chrisjj 3 hours ago | parent [-] | | We've not yet seen sufficient evidence this is any type of heisenbug. | | |
| ▲ | defrost 2 hours ago | parent | next [-] | | It's not, by the article, in a strict taxonomy. In a wider sloppier sense some use the term for bugs that are hard to pin down and exhibit wide behaviours. | |
| ▲ | brookst 2 hours ago | parent | prev [-] | | Looking more closely would resolve it one way or the other. | | |
|
|
|
| ▲ | nopurpose an hour ago | parent | prev | next [-] |
| How big and important third-party vendor must be for Raymond Chen to dissect its coredumps? |
| |
| ▲ | FartyMcFarter an hour ago | parent [-] | | 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. |
|
|
| ▲ | hackrmn 20 minutes ago | parent | prev [-] |
| The fact that Raymond Chen is debugging these kind of issues, tells me Microsoft is short on staff that has his particular set of skills, handing him the hairiest issues from the annals of Windows. The new hires are probably all about .NET and JavaScript and what have you -- whatever Microsoft is about these days. I doubt it's C/C++. Chen is probably on standby and is paid handsomely as a de-facto VIP consultant. He is a legend, but he's becoming somewhat of a vintage developer. |
