While the test App or App is running or even after a deadlock occurs, go to the MSDEV
menu under 'Debug' and select 'Break'. This should break the session into the
debugger. From there select 'Debug->Threads' and when presented with the threads
list, trawl through the list, and click on the thread in question (some trial and
error needed there). When the thread in question is found, from the stack trace window click on
the 'CActiveScheduler::WaitForAnyRequest()' call. This should show the 'this'
object on the context window.
The 'this' object is basically the Active Scheduler for that thread and has
an iActiveQ. The 'this' context looks like the following:
+this
|+CBase
|-iLevel 1 (usually)
|+iActiveQ
|-TDblQueBase
|-+TDblQueLinkBase
|--+- iNext 0xXYZ
|--+- iPrev 0xKLM
|-+iOffset 12
Now this contextual info is good enough to find all AOs. With one caveat
If you look at the context the TDblQueBase has an iOffset, this denotes the offset
of the link list node in within the CActive object. Thus if you try to cast address
0xXYZ to a CBase* you will get garbage. To remedy this one should use the
'quickwatch' window and enter the following:
(CBase*)(0xXYZ-0xc)
Now that will give the exact context (and type) of the AO in question together with
all its member fields.
By doing this for all AOs on the iActiveQ link list, one can get all info
around the active and non-active AOs; and thus discover the deadlocked AO waiting (for ever) to be completed !