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

 (devblogs.microsoft.com)

45 points | by ibobev 3 hours ago

5 comments

  • masfuerte 1 hour ago
    Part two:

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

    [-]
    • Someone1234 36 minutes 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 21 minutes ago
        Might have been an “I need to look into this” segueing into “ never mind”?
  • rwmj 7 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.

  • zabzonk 1 hour 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 29 minutes ago
      When you’ve eliminated all possible explanation, it’s time to pack it in.
      [-]
      • taneq 19 minutes 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.
  • kumarvvr 50 minutes 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 28 minutes ago
      Goes both ways, author probably knows little about FPGA programming, React or PyTorch.
    • Panzer04 36 minutes ago
      Not a programmer?
      [-]
      • kumarvvr 21 minutes ago
        I am, for 20 years now. I do embedded stuff too. Still.
        [-]
        • Panzer04 3 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 1 hour 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 1 hour ago
      We've not yet seen sufficient evidence this is any type of heisenbug.
      [-]
      • defrost 16 minutes 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 28 minutes ago
        Looking more closely would resolve it one way or the other.
        [-]