Is there anyway to alter the “kb” statement that “!analyze -v” executes
into a “kvn” or to get kb to also show FPO data?
I think most users would consider the second format much more informative.
It should be the default.
All results shown for this version of WinDBG:
Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
and they come from the same minidump.
When I process a minidump with the “!analyze -v” I get a result like this:
STACK_TEXT:
00918d18 768b4740 oleaut32!SysAllocString+0x15
00918d20 77d3c4fc sp3deqpcadhelper!ATL::CComBSTR::CComBSTR+0x2c
00918d34 77d2210d
sp3deqpcadhelper!CCADServices::CheckMemberConditional+0x53d
00918f44 17cdff75 sp3dpullpitasm!PullPitDef::CMConditionalPullBoxSolid+0x86
00918fa8 768ccc68 oleaut32!DispCallFunc+0x165
00918fc8 4ff03c67 msvbvm60+0x63c67
00919924 4ff03975 msvbvm60+0x63975
00919980 186f1fe1 imssymbolentities!PerformMethodViaAutomation+0x3e1
00919a78 186ea61f imssymbolentities!PerformActiveXMethod+0x1bf
00919af4 1865627d imssymbolentities!CSblDefinition::InvokeMethod+0x8bd
00919c74 52353d4e
customassembly!CDMemberDescription::InvokeCMConditional+0x2de
Luckily, years ago I noticed that if I execute “kvn20” after the results of
“!analyze -v” are printed, I get a much more informative stack, with FPO
data:
EXCEPTION_STACK_TEXT:
0:000> kvn20
ChildEBP RetAddr Args to Child
00 00918d18 77d3c4fc cdcdcdcd 00918d38 00918ebc
oleaut32!SysAllocString+0x15 (FPO: [Non-Fpo])
01 00918d2c 77d2210d cdcdcdcd 21747db9 00000000
SP3DEqpCADHelper!ATL::CComBSTR::CComBSTR+0x2c (FPO: [Non-Fpo]) (CONV:
thiscall) [c:\program files (x86)\microsoft visual studio
14.0\vc\atlmfc\include\atlcomcli.h @ 775]
02 00918f3c 17cdff75 1c0e5504 15d65c24 00918f70
SP3DEqpCADHelper!CCADServices::CheckMemberConditional+0x53d (FPO:
[Non-Fpo]) (CONV: stdcall)
[m:\equipment\middle\services\equipcadhelper\sp3deqpcadhelper\cadservices.cpp
@ 1566]
03 00918fa0 768ccc68 1053c118 15d65c24 0091bff4
SP3DPullPitAsm!PullPitDef::CMConditionalPullBoxSolid+0x86
[M:\SharedContent\Src\Equipment\Symbols\SP3DPullPitAsm\PullPitDef.cls @
1082]
04 00918fc0 4ff03c67 1053c118 000000c0 00000004 oleaut32!DispCallFunc+0x165
WARNING: Stack unwind information not available. Following frames may be
wrong.
05 0091991c 4ff03975 1053c118 17cd2808 6003002e msvbvm60+0x63c67
06 00919978 186f1fe1 1053c118 6003002e 1886a110 msvbvm60+0x63975
07 00919a70 186ea61f cccc0003 cccccccc 6003002e
IMSSymbolEntities!PerformMethodViaAutomation+0x3e1 (FPO: [Non-Fpo]) (CONV:
cdecl) [x:\middle\symbol\src\sblentities\sdmethodapi.cpp @ 286]
08 00919aec 1865627d cccc0003 cccccccc 6003002e
IMSSymbolEntities!PerformActiveXMethod+0x1bf (FPO: [Non-Fpo]) (CONV: cdecl)
[x:\middle\symbol\src\sblentities\sdmethodapi.cpp @ 350]
09 00919c6c 52353d4e 2345b9b0 cccc0003 cccccccc
IMSSymbolEntities!CSblDefinition::InvokeMethod+0x8bd (FPO: [Non-Fpo])
(CONV: stdcall) [x:\middle\symbol\src\sblentities\sbldefinition.cpp @ 4078]
0a 00919dcc 520e60b2 15d65c24 0091bff4 b6fb244d
CustomAssembly!CDMemberDescription::InvokeCMConditional+0x2de (FPO:
[Non-Fpo]) (CONV: stdcall)
[m:\commonapp\middle\entities\customassembly\businessobject\dmemberdescription.cpp
@ 1435]
Both of these came from same minidump, by having a script that does
“!analyze -v;.echo EXCEPTION_STACK_TEXT:;kvn20”
Obviously, you will only get source and line number information if you have
the correct PDBs for your DLLs.
Appreciate any input,
Osiris