{"id":2653,"date":"2013-11-15T07:00:00","date_gmt":"2013-11-15T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2013\/11\/15\/restoring-symbols-to-a-stack-trace-originally-generated-without-symbols\/"},"modified":"2013-11-15T07:00:00","modified_gmt":"2013-11-15T07:00:00","slug":"restoring-symbols-to-a-stack-trace-originally-generated-without-symbols","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20131115-00\/?p=2653","title":{"rendered":"Restoring symbols to a stack trace originally generated without symbols"},"content":{"rendered":"

\n\nHas this ever happened to you<\/a>?\n<\/p>\n

\nlitware!Ordinal3+0x6042\nlitware!DllInstall+0x4c90\nlitware!DllInstall+0x4b9e\ncontoso!DllGetClassObject+0x93c3\ncontoso!DllGetClassObject+0x97a9\ncontoso!DllGetClassObject+0x967c\ncontoso!DllGetClassObject+0x94d7\ncontoso!DllGetClassObject+0x25ce\ncontoso!DllGetClassObject+0x2f7b\ncontoso!DllGetClassObject+0xad55\ncontoso!DllGetClassObject+0xaec7\ncontoso!DllGetClassObject+0xadf7\ncontoso!DllGetClassObject+0x3c00\ncontoso!DllGetClassObject+0x3b2a\ncontoso!DllGetClassObject+0x462b\nUSER32!UserCallWinProcCheckWow+0x13a\nUSER32!DispatchMessageWorker+0x1a7\ncontoso!DllCanUnloadNow+0x19b6\ncontoso!DllGetClassObject+0xeaf2\ncontoso+0x1d6c\nlitware!LitImportReportProfile+0x11c4\nlitware!LitImportReportProfile+0x1897\nlitware!LitImportReportProfile+0x1a3b\nKERNEL32!BaseThreadInitThunk+0x18\nntdll!RtlUserThreadStart+0x1d\n<\/pre>\n
\nUgh.\nA stack trace taken without working symbols.\n(There’s no way that\nDll­Get­Class­Object<\/code>\nis a deeply recursive 60KB function.\nJust by casual inspection, you know that the symbols are wrong.)\n<\/p>\n
\nTo see how to fix this, you just have to understand what the\ndebugger does when it has no symbols to work from:\nIt uses the symbols from the exported function table.\nFor every address it wants to resolve,\nit looks for the nearest exported function whose address is\n\nless than or equal to<\/a> the target value.\n<\/p>\n
\nFor example, suppose CONTOSO.DLL<\/code>\nhas the following exported symbols:\n<\/p>\n\n\n\n\n
Symbol<\/th>\nOffset<\/th>\n<\/tr>\n
Dll­Get­Class­Object<\/code><\/td>\n0x5132<\/code><\/td>\n<\/tr>\n
Dll­Can­Unload­Now<\/code><\/td>\n0xFB0B<\/code><\/td>\n<\/tr>\n<\/table>\n
\nLook at it this way:\nThe debugger is given the following information about your module:\n(Diagram not to scale.)\n<\/p>\n\n\n\n
 <\/td>\n<\/tr>\n
 <\/td>\n↑<\/td>\nDll­Get­Class­Object<\/td>\n↑<\/td>\nDll­Can­Unload­Now<\/td>\n<\/tr>\n<\/table>\n
\nIt needs to assign a function to every byte in the module.\nIn the absence of any better information, it does it like this:\n<\/p>\n\n\n
???<\/td>\nDll­Get­Class­Object<\/td>\nDll­Can­Unload­Now<\/td>\n<\/tr>\n<\/table>\n
\nIn words, it assumes that every function begins at the location specified\nby the export table,\nand it ends one byte before the start of the next function.\nThe debugger is trying to make the best of a bad situation.\n<\/p>\n
\nSuppose your DLL was loaded at\n\n0x10000000<\/code><\/a>,\nand the debugger needs to generate a symbolic name for the address\n0x1000E4F5<\/code>.\n<\/p>\n
\nFirst, it converts the address into a relative virtual address\nby subtracting the DLL base address,\nleaving 0xE4F5<\/code>.\n<\/p>\n
\nNext, it looks to see what function “contains” that address.\nFrom the algorithm described above,\nthe debugger concludes that the address 0xE4F5<\/code> is\n“part of” the\nDll­Get­Class­Object<\/code> function,\nwhich began at\nbegins at 0x5132<\/code>.\nThe offset into the function is therefore\n0xE4F5 - 0x5132 = 0x93C3<\/code>,\nand it is reported in the debugger as\ncontoso!Dll­Get­Class­Object+0x93c3<\/code>.\n<\/p>\n
\nRepeat this exercise for each address that the debugger needs to resolve,\nand you get the stack trace above.\n<\/p>\n
\nFine, now that you know how the bad symbols were generated,\nhow do you fix it?\n<\/p>\n
\nYou fix it by undoing what the debugger did, and then redoing it\nwith better symbols.\n<\/p>\n
\nYou need to find the better symbols.\nThis is not too difficult if you still have a matching binary\nand symbol file,\nbecause you can just load up the binary into the debugger\n\nin the style of a dump file<\/a>.\nLike Doron, you can then let the debugger do the hard work.\n<\/p>\n
\nC:> ntsd -z contoso.dll\nModLoad: 10000000 10030000   contoso.dll\n<\/pre>\n
\nNow you just ask the debugger,\n“Could you disassemble this function for me?”\nYou give it the broken symbol+offset above.\nThe debugger looks up the symbol,\napplies the offset,\nand then looks up the correct symbol<\/i> when disassembling.\n<\/p>\n
\n0:000> u contoso!DllGetClassObject+0x93c3\ncontoso!CReportViewer::ActivateReport+0xe9<\/font>:\n10000e4f5 eb05            jmp     contoso!CReportViewer::ActivateReport+0xf0\n<\/pre>\n
\nRepeat for each broken symbol in the stack trace,\nand you have yourself a repaired stack trace.\n<\/p>\n
\nlitware!Ordinal3+0x6042 ← oops<\/font>\nlitware!CViewFrame::SetInitialKeyboardFocus+0x58\nlitware!CViewFrame::ActivateViewInFrame+0xf2\ncontoso!CReportViewer::ActivateReport+0xe9\ncontoso!CReportViewer::LoadReport+0x12c\ncontoso!CReportViewer::OnConnectionCreated+0x13f\ncontoso!CViewer::OnConnectionEvent+0x7f\ncontoso!CConnectionManager::OnConnectionCreated+0x85\ncontoso!CReportFactory::BeginCreateConnection+0x87\ncontoso!CReportViewer::CreateConnectionForReport+0x20d\ncontoso!CViewer::CreateNewConnection+0x87\ncontoso!CReportViewer::CreateNewReport+0x213\ncontoso!CViewer::OnChangeView+0xec\ncontoso!CReportViewer::WndProc+0x9a7\ncontoso!CView::s_WndProc+0xf1\nUSER32!UserCallWinProcCheckWow+0x13a\nUSER32!DispatchMessageWorker+0x1a7\ncontoso!CViewer::MessageLoop+0x24e\ncontoso!CViewReportTask::RunViewer+0x12\ncontoso+0x1d6c ← oops<\/font>\nlitware!CThreadTask::Run+0x40\nlitware!CThread::ThreadProc+0xe5\nlitware!CThread::s_ThreadProc+0x42\nKERNEL32!BaseThreadInitThunk+0x18\nntdll!RtlUserThreadStart+0x1d\n<\/pre>\n
\nOops, our trick doesn’t work for that first entry in the stack trace,\nthe one with Ordinal3<\/code>.\nWhat’s up with that?\nThere is no function called Ordinal3<\/code>!\n<\/p>\n
\nIf your module exports functions by ordinal without a name,\nthen the debugger doesn’t know what name to print for the function\n(since the name was stripped from the module),\nso it just prints the ordinal number.\nYou will have to go back to your DLL’s DEF<\/code> file\nto convert the ordinal back to a function name.\nOr you can\n\ndump the exports from the DLL\nto see what functions match up with what ordinals<\/a>.\n(Of course, for that trick to work, you need to have a matching PDB file\nin the symbol search path.)\n<\/p>\n
\nIn our example, suppose litware.dll<\/code> ordinal 3\ncorresponds to the function\nLit­Debug­Report­Profile<\/code>.\nWe would then ask the debugger\n<\/p>\n
\n0:001> u litware!LitDebugReportProfile+0x6042\nlitware!CViewFrame::FindInitialFocusControl+0x66<\/font>:\n1000084f5 33db            xor     ebx,ebx\n<\/pre>\n
\nOkay, that takes care of our first oops.\nWhat about the second one?\n<\/p>\n
\nIn the second case, the address the debugger was asked to\ngenerate a symbol for came before the first symbol in the module.\nIn our diagram above, it was in the area marked with question marks.\nThe debugger has absolutely nothing to work with, so it just\ndisassembles as relative to the start of the module.\n<\/p>\n
\nTo resolve this symbol, you take the offset and add it to the\nbase of the module as it was loaded into the debugger,\nwhich was reported in the ModLoad<\/code> output:\n<\/p>\n
\nModLoad: 10000000<\/font> 10030000   contoso.dll\n<\/pre>\n
\nIf that output scrolled off the screen, you can ask the debugger\nto show it again with the help of the lmm<\/code> command.\n<\/p>\n
\n0:001>lmm contoso*\nstart    end        module name\n10000000 10030000   contoso    (export symbols)       contoso.dll\n<\/pre>\n
\nOnce you have the base address, you\n\nadd the offset back<\/a>\nand ask the debugger what’s there:\n<\/p>\n
\n0:001> u 0x10000000+0x1d6c\ncontoso!CViewReportTask::Run+0x102<\/font>:\n100001d6c 50              push    eax\n<\/pre>\n
\nOkay, now that we patched up all our oopses,\nwe have the full stack trace with symbols:\n<\/p>\n
\nlitware!CViewFrame::FindInitialFocusControl+0x66\nlitware!CViewFrame::SetInitialKeyboardFocus+0x58\nlitware!CViewFrame::ActivateViewInFrame+0xf2\ncontoso!CReportViewer::ActivateReport+0xe9\ncontoso!CReportViewer::LoadReport+0x12c\ncontoso!CReportViewer::OnConnectionCreated+0x13f\ncontoso!CViewer::OnConnectionEvent+0x7f\ncontoso!CConnectionManager::OnConnectionCreated+0x85\ncontoso!CReportFactory::BeginCreateConnection+0x87\ncontoso!CReportViewer::CreateConnectionForReport+0x20d\ncontoso!CViewer::CreateNewConnection+0x87\ncontoso!CReportViewer::CreateNewReport+0x213\ncontoso!CViewer::OnChangeView+0xec\ncontoso!CReportViewer::WndProc+0x9a7\ncontoso!CView::s_WndProc+0xf1\nUSER32!UserCallWinProcCheckWow+0x13a\nUSER32!DispatchMessageWorker+0x1a7\ncontoso!CViewer::MessageLoop+0x24e\ncontoso!CViewReportTask::RunViewer+0x12\ncontoso!CViewReportTask::Run+0x102\nlitware!CThreadTask::Run+0x40\nlitware!CThread::ThreadProc+0xe5\nlitware!CThread::s_ThreadProc+0x42\nKERNEL32!BaseThreadInitThunk+0x18\nntdll!RtlUserThreadStart+0x1d\n<\/pre>\n
\nNow the fun actually starts:\nFiguring out why there was a break in\nCView­Frame::Find­Initial­Focus­Control<\/code>.\nHappy debugging!\n<\/p>\n
\nBonus tip<\/b>:\nBy default,\nntsd<\/code> does not include line numbers when resolving symbols.\nType .lines<\/code> to toggle line number support.<\/p>\n","protected":false},"excerpt":{"rendered":"
Has this ever happened to you? litware!Ordinal3+0x6042 litware!DllInstall+0x4c90 litware!DllInstall+0x4b9e contoso!DllGetClassObject+0x93c3 contoso!DllGetClassObject+0x97a9 contoso!DllGetClassObject+0x967c contoso!DllGetClassObject+0x94d7 contoso!DllGetClassObject+0x25ce contoso!DllGetClassObject+0x2f7b contoso!DllGetClassObject+0xad55 contoso!DllGetClassObject+0xaec7 contoso!DllGetClassObject+0xadf7 contoso!DllGetClassObject+0x3c00 contoso!DllGetClassObject+0x3b2a contoso!DllGetClassObject+0x462b USER32!UserCallWinProcCheckWow+0x13a USER32!DispatchMessageWorker+0x1a7 contoso!DllCanUnloadNow+0x19b6 contoso!DllGetClassObject+0xeaf2 contoso+0x1d6c litware!LitImportReportProfile+0x11c4 litware!LitImportReportProfile+0x1897 litware!LitImportReportProfile+0x1a3b KERNEL32!BaseThreadInitThunk+0x18 ntdll!RtlUserThreadStart+0x1d Ugh. A stack trace taken without working symbols. (There’s no way that Dll­Get­Class­Object is a deeply recursive 60KB function. Just by casual inspection, you […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-2653","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Has this ever happened to you? litware!Ordinal3+0x6042 litware!DllInstall+0x4c90 litware!DllInstall+0x4b9e contoso!DllGetClassObject+0x93c3 contoso!DllGetClassObject+0x97a9 contoso!DllGetClassObject+0x967c contoso!DllGetClassObject+0x94d7 contoso!DllGetClassObject+0x25ce contoso!DllGetClassObject+0x2f7b contoso!DllGetClassObject+0xad55 contoso!DllGetClassObject+0xaec7 contoso!DllGetClassObject+0xadf7 contoso!DllGetClassObject+0x3c00 contoso!DllGetClassObject+0x3b2a contoso!DllGetClassObject+0x462b USER32!UserCallWinProcCheckWow+0x13a USER32!DispatchMessageWorker+0x1a7 contoso!DllCanUnloadNow+0x19b6 contoso!DllGetClassObject+0xeaf2 contoso+0x1d6c litware!LitImportReportProfile+0x11c4 litware!LitImportReportProfile+0x1897 litware!LitImportReportProfile+0x1a3b KERNEL32!BaseThreadInitThunk+0x18 ntdll!RtlUserThreadStart+0x1d Ugh. A stack trace taken without working symbols. (There’s no way that Dll­Get­Class­Object is a deeply recursive 60KB function. Just by casual inspection, you […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/2653","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=2653"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/2653\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=2653"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=2653"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=2653"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}