DLL that was not present in memory despite not being formally unloaded • Hacker News Board

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

#11

Post by brookst » Sun, Jun 28, 2026, 1:10 PM UTC

chrisjj wrote: post #4

defrost wrote: post #2

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.

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

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

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

#12

Post by taneq » Sun, Jun 28, 2026, 1:17 PM UTC

Someone1234 wrote: post #8

masfuerte wrote: post #5

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

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.

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

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

#13

Post by kumarvvr » Sun, Jun 28, 2026, 1:18 PM UTC

Panzer04 wrote: post #7

kumarvvr wrote: post #6

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.

Not a programmer?

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

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

#14

Post by taneq » Sun, Jun 28, 2026, 1:19 PM UTC

brookst wrote: post #9

zabzonk wrote: post #3

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

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

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.

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

#15

Post by defrost » Sun, Jun 28, 2026, 1:22 PM UTC

chrisjj wrote: post #4

defrost wrote: post #2

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.

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

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.

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

#16

Post by defrost » Sun, Jun 28, 2026, 1:23 PM UTC

brookst wrote: post #11

chrisjj wrote: post #4

Earlier quoted context omitted.

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

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

My hat.

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

#17

Post by rwmj » Sun, Jun 28, 2026, 1:31 PM UTC

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.

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

#18

Post by Panzer04 » Sun, Jun 28, 2026, 1:35 PM UTC

kumarvvr wrote: post #13

Panzer04 wrote: post #7

Earlier quoted context omitted.

Not a programmer?

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

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

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

#19

Post by kumarvvr » Sun, Jun 28, 2026, 1:43 PM UTC

Panzer04 wrote: post #18

kumarvvr wrote: post #13

Earlier quoted context omitted.

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

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

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.

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

#20

Post by FartyMcFarter » Sun, Jun 28, 2026, 1:49 PM UTC

Panzer04 wrote: post #18

kumarvvr wrote: post #13

Earlier quoted context omitted.

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

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

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