Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

31–40 of 49 posts

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

#31

Post by microgpt »

londons_explore wrote: post #22
Someone1234 wrote: post #8

Earlier quoted context omitted.

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.

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

You could also look at modules loaded into all of those processes that crashed this way.

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

#32

Post by microgpt »

rpeden wrote: post #30
IChooseY0u wrote: post #28

Windows COM is super weird and way over engineered.

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.

It basically is that. It's a standardized sticks and stones. Plus objects for some reason. But I don't think the objects are a bad thing - it allows multiple implementations of sometimes to co-exist - consider using two different GPUs from different vendors at the same time. It took a really long time and a bunch of hacks to make OpenGL support that, but DirectX could always do it (at least at the API level) by just creating two different ID3DDevice objects backed by different code from different DLLs both loaded at the same time.

OpenGL basically loads the GPU driver DLL that directly implements the OpenGL functions while Direct3D uses a COM object with a vtable so it can easily have two different ones.

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

#33

Post by [deleted] »

hackrmn wrote: post #27

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…

[deleted]

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

#34

Post by forestry »

hackrmn wrote: post #27

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…

Managed dump analysis in windbg was a thing. It’s been many years since I’ve needed it, though. Service telemetry improved quickly thereafter.

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

#35

Post by rramadass »

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.

These sort of bugs require a lot of knowledge about a) Windows Internals b) Tools to debug at that level. Most application-level programmers won't need nor are exposed to these.

However, if you are interested in knowing what is all involved, see; Advanced Windows Debugging by Mario Hewardt and Daniel Pravat - https://advancedwindowsdebugging.com/

Review of the book by Raymond Chen himself! - https://devblogs.microsoft.com/oldnewthing/20071218-01/?p=24...

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

#37

Post by rramadass »

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.

Part-2 is more than a paragraph and is logically distinct from Part-1. In this, Raymond actually gets the crucial clue from another colleague's debugging efforts which leads him to identify that the bottom byte of HMODULE of the DLL gets overwritten by which is the root cause of the bug; viz.

The “DLL unmapped from memory” crash is just an alternate manifestation of the “somebody is writing 01 bytes to places they shouldn’t” bug. The original bug had a larger bucket spray than we initially thought.

Part-2 is the essence of the solution while Part-1 is a series of investigations and inferences.

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

#38

Post by Chu4eeno »

FartyMcFarter wrote: post #20
Panzer04 wrote: post #18

Earlier quoted context omitted.

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

I assume it's mostly just something you learn to recognize after decades of poking at the same things. I remember being impressed with Thiago (Qt developer) being able to immediately tell if a pointer was heap allocated, invalid/unaligned, etc. until I spent more time poring over /proc/*/maps and in gdb. Never figured out how he could tell someone's Qt version just from an strace excerpt, though.

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

#39

Post by DANmode »

rwmj wrote: post #17

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.

Perhaps it’s a matter of subjective interest!

Often that’s how these things go.

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

#40

Post by DANmode »

1970-01-01 wrote: post #26

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

Shady, as in, where does that data end up after MS collects it, and why?
Post reply on HN