\nOkay, so I gave it away in the title, but follow along anyway.\n<\/p>\n
\nYour program chugs along and then suddenly it crashes like this:\n<\/p>\n
\neax=06bad8e8 ebx=00000000 ecx=1e1cfdf0 edx=00000000 esi=06b9a680 edi=01812950\neip=1180ab57 esp=001178b4 ebp=001178c0 iopl=0 nv up ei pl nz na pe nc\ncs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206\nABC!FunctionX+0x1f:\n1180ab57 ff5108 call dword ptr [ecx+8] ds:0023:1e1cfdf8=????????\n0:000>>\n<\/pre>\n\nInstantly you recognize the following:\n<\/p>\n
ecx<\/code>.\n (That is the base register of the indirect call.)\n — Very high confidence.<\/p>\n- The underlying DLL for this object has been unloaded.\n (The memory that contains the vtable is not valid and its address\n is consistent with once having been in valid code.)\n — High confidence.<\/p>\n
- This is a
IUnknown::Release<\/code> call.\n (Release<\/code> is the third function of IUnknown<\/code>\n and therefore resides at offset 8 on x86.)\n — High confidence.\n<\/ul>\n\nOf course, all of the above “instant conclusions” are merely\n“highly-educated guesses”, but life is full of highly-educated guesses.\n(Every morning, I guess that my plates are still in the cupboard.)\n<\/p>\n
\nLet’s run with our theory that the object was in an unloaded DLL\nand look for confirmation.\n<\/p>\n
\n0:000> lm\nstart end module name\n...\nUnloaded modules:\n10340000 10348000 DEF.DLL\n1e1c0000 1e781000 GHI.DLL\n25a90000 25a96000 JKL.DLL\n0:000>\n<\/pre>\n\nAha, our presumed vtable address lies right inside the address space\nwhere GHI.DLL<\/code> used to be loaded.\nLet’s see what used to be loaded at that address.\nFor this, I borrow a trick from\n\nDoron<\/a>, namely\n\nloading a module as a dump file<\/a>.\nThis “virtually loads” the library so you can poke around inside it.\n<\/p>\n\nC:\\Program Files\\ABC> ntsd -z GHI.DLL\nMicrosoft (R) Windows Debugger\nCopyright (c) Microsoft Corporation. All rights reserved.\nLoading Dump File [C:\\Program Files\\ABC\\GHI.DLL]\n...\nModLoad: 15800000 15dc1000 C:\\Program Files\\ABC\\GHI.DLL\neax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000\neip=15807366 esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na pe nc\ncs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000 efl=00000000\nGHI!_DllMainCRTStartup:\n15807366 8bff mov edi,edi\n0:000>\n<\/pre>\n\nThat module-load notification tells you where the DLL got\nvirtually-loaded;\nin our case, it got loaded to 0x15800000.\nThis isn’t the same address as it was in our crashed process,\nso we’ll have to do some mental arithmetic to account for the\ndiscrepancy.\n<\/p>\n
\nGoing back to the original register dump, we see that our\nputative vtable is at ecx=1e1cfdf0<\/code> relative\nto the load address 1e1c0000<\/code>.\nSince our DLL-loaded-as-a-dump-file was loaded at 0x1580000<\/code>\nwe need to adjust the address to be relative to the new location.\n<\/p>\n\n\/\/ working with the second copy of ntsd\n0:000> ln 0x1580fdf0\n(1580fdf0) GHI!CAlphaStream::`vftable'\n<\/pre>\n\nThat magic number 0x1580fdf0<\/code> is just the result of\nsome mental arithmetic.\nFirst:\n<\/p>\n