DLL that was not present in memory despite not being formally unloaded

Discussion (20 Comments)Read Original on HackerNews

masfuerte•about 2 hours ago

Part two:

https://devblogs.microsoft.com/oldnewthing/20260626-00/?p=11...

Someone1234•about 1 hour ago

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.

taneq•about 1 hour ago

Might have been an “I need to look into this” segueing into “ never mind”?

zabzonk•about 2 hours ago

> 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•about 1 hour ago

When you’ve eliminated all possible explanation, it’s time to pack it in.

taneq•about 1 hour ago

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•37 minutes ago

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•19 minutes ago

> 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.

kumarvvr•about 1 hour ago

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.

dist-epoch•about 1 hour ago

Goes both ways, author probably knows little about FPGA programming, React or PyTorch.

Panzer04•about 1 hour ago

Not a programmer?

kumarvvr•about 1 hour ago

I am, for 20 years now. I do embedded stuff too. Still.

Panzer04•33 minutes ago

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

defrost•about 2 hours ago

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•about 2 hours ago

We've not yet seen sufficient evidence this is any type of heisenbug.

defrost•about 1 hour ago

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•about 1 hour ago

Looking more closely would resolve it one way or the other.

defrost•about 1 hour ago

My hat.

DLL that was not present in memory despite not being formally unloaded

⚡ Community Insights

Discussion (20 Comments)Read Original on HackerNews