When doing post-mortem debugging, one important task is to quickly find out what's going on in the system.
Sometimes you will find some local information at the point of failure to get you started, but in many cases this only provides some very localized state that doesn't give you clues about what was really going on.
A trick I've used for many years now is to try and make all the state in my applications and libraries globally reachable, so I can focus on any .exe or .dll I might find in various contexts. Often this takes the form of a list of top-level objects that are either in some global vector or are chained via an intrusive double-linked list.
This collection should never extend the lives of the objects, i.e. should not keep them alive if they're no longer otherwise needed.
Maintaining this collection is relatively inexpensive, even if there's a lock involved, as most interesting top-level objects end up being things like network connections, input devices, databases, etc.
Other useful things that are really there for post-mortem include the following. These are often values within objects that are then reachable through globals. Ideally all the state for your library hangs off these objects, and keeping these roots lets you effectively access all (valid) values.
The point really isn't that having globals is good. The point is that the ability to see all the state in your system is important enough that it's worth using them even if you otherwise wouldn't.
Happy debugging!