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

4 comments

• masfuerte 39 minutes ago
  Part two:

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

  [-]
  • Someone1234 15 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 0 minutes ago
      Might have been an “I need to look into this” segueing into “ never mind”?
• zabzonk 50 minutes 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 8 minutes ago
    When you’ve eliminated all possible explanation, it’s time to pack it in.
• kumarvvr 29 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 7 minutes ago
    Goes both ways, author probably knows little about FPGA programming, React or PyTorch.
  • Panzer04 15 minutes ago
    Not a programmer?
• defrost 53 minutes 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 42 minutes ago
    We've not yet seen sufficient evidence this is any type of heisenbug.
    [-]
    • brookst 7 minutes ago
      Looking more closely would resolve it one way or the other.