Windbg附加到进程后如何显示某线程的堆栈信息?

nefory 2013-10-11 11:18:55
我想通过windbg附加到某个exe的进程后,随时观测某个动态库的运行情况。我确定了.dll对应的.pdb文件已经正确加载,可是当我选定了我想查看的线程后,却没能看到堆栈内的函数调用状况。

我baidu+google了一下网上对attach和call stack的应用介绍和教程,都说得特简单。尤其是MSDN,直接说attach+call stack,然后WALLAH!堆栈就出来了,模块名,模块地址,函数名等什么都有。可是我按同样步骤却只能显示系统的.dll。

我感觉要么是我的windbg版本或者设置不对,要么就是我却少/漏加载某个文件。

有没有大神指导一下本菜鸟啊?
...全文
1352 28 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
28 条回复
切换为时间正序
请发表友善的回复…
发表回复
赵4老师 2013-10-12
  • 打赏
  • 举报
回复
0:000> !clr10\sos.help Bp Use !GCRef to see what objects hold a reference to the given object and what references it holds. To see more tips, run !tip. ------------------------------------------------------------------------------- !Bp <module name> <method name> !Bp <module name>!<method name> !Bp sets a breakpoint on the given function. It will break even if the function isn't JIT'ed yet. 我还会……
赵4老师 2013-10-12
  • 打赏
  • 举报
回复
0:000> !clr10\sos.help Use !DumpDataTables to see interesting information about System.Data.DataTables. To see more tips, run !tip. Did you know that a lot of exceptions (!dumpallexceptions) can cause memory problems. To see more tips, run !tip. ------------------------------------------------------------------------------- SOS is a debugger extension DLL designed to aid in the debugging of managed programs. Functions are listed by category, then roughly in order of importance. Shortcut names for popular functions are listed in parenthesis. Type "!help <functionname>" for detailed info on that function. Object Inspection Examining code and stacks ----------------------------- ----------------------------- DumpObj (do) Threads (t) DumpAllExceptions (dae) CLRStack DumpStackObjects (dso) IP2MD DumpHeap (dh) U DumpVC DumpStack GCRoot EEStack ObjSize GCInfo FinalizeQueue COMState DumpDynamicAssemblies (dda) X DumpField (df) SearchStack TraverseHeap (th) GCRef Examining CLR data structures Diagnostic Utilities ----------------------------- ----------------------------- DumpDomain VerifyHeap (vh) EEHeap DumpLog Name2EE FindAppDomain SyncBlk SaveModule DumpASPNETCache (dac) SaveAllModules (sam) DumpMT GCHandles DumpClass GCHandleLeaks DumpMD FindDebugTrue Token2EE FindDebugModules EEVersion Bp DumpSig ProcInfo DumpModule StopOnException (soe) ThreadPool (tp) TD ConvertTicksToDate (ctd) Analysis ConvertVTDateToDate (cvtdd) Bl RWLock CheckCurrentException (cce) DumpConfig CurrentExceptionName (cen) DumpHttpRuntime ExceptionBp DumpSessionStateConfig FindTable DumpBuckets LoadCache DumpHistoryTable SaveCache DumpRequestTable ASPXPages DumpCollection (dc) DumpGCNotInProgress DumpDataTables CLRUsage GetWorkItems DumpLargeObjectSegments (dl) DumpModule DumpAssembly Other DumpMethodSig ----------------------------- DumpRuntimeTypes FAQ PrintIPAddress DumpHttpContext DumpXmlDocument (dxd) 我还会按帮助文档提示输入命令 !clr10\sos.help
赵4老师 2013-10-12
  • 打赏
  • 举报
回复
Debugging Managed Code You can debug managed code by using the Sos.dll extension. This extension is located in the \clr10 subdirectory of the Debugging Tools for Windows installation. To use this extension, load it and then type !clr10\sos.help.. This command lists all available extension commands and their parameters. 我还会粘贴帮助文档的片断并加红色。
Damn_boy 2013-10-11
  • 打赏
  • 举报
回复
pdb文件需要用 symstore转换才可使用 用 .reload -f加载
Damn_boy 2013-10-11
  • 打赏
  • 举报
回复
~*kb ~ns n替换为线程id
nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 22 楼 spirit008 的回复:
我说的很清楚了啊,你那个显示的就是“函数名”!!不是说你不认识的就不是函数!
我知道你的意思,我说的是如果我想做到MSDN介绍里那个效果,该如何做
木头菇 2013-10-11
  • 打赏
  • 举报
回复
我说的很清楚了啊,你那个显示的就是“函数名”!!不是说你不认识的就不是函数!
nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 18 楼 zhao4zhong1 的回复:
我只会粘贴帮助文档的片断。
老师你好懒啊 当然我更懒,万分感谢两位啊!!
nefory 2013-10-11
  • 打赏
  • 举报
回复


又发错图了....这才是msdn对call stack的介绍

nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 12 楼 spirit008 的回复:
你5楼的图和你描述的没有出入,用dump还是挂进程跑是一模一样的,这就是函数,感叹号前是所属模块(dll or exe),感叹号后是函数名+偏移地址。函数参数是不能直接显示的,就是显示出来也不一定对,因为windbg只是依赖寄存器ebp+xx来猜你的函数参数...


另外,MSDN对call stack的介绍也是能直接显示函数的,而且讲的很简单。



啊,求解答啊
赵4老师 2013-10-11
  • 打赏
  • 举报
回复
我只会粘贴帮助文档的片断。
赵4老师 2013-10-11
  • 打赏
  • 举报
回复
Debugging Tools for Windows Debugging Managed Code You can also use the WinDbg, CDB, and NTSD to perform limited debugging of target applications that contain managed code. Introduction to Managed Code Managed code is code that is executed together with the Microsoft .NET common language runtime (CLR). The .NET CLR manages raw code and data for the application and provides enhanced services such as garbage collection and platform-independent code. Compiled code that requires this runtime is called managed code. Code that does not require this runtime is called unmanaged code. An application that consists of only managed code is called a managed application. A managed .NET application can execute on any platform that supports the .NET CLR because the binary code that the compiler produces is not platform-specific. Binary code in a managed application is in Microsoft intermediate language (MSIL). The binary also includes object information and other references (known as metadata). A managed application differs from a traditional application because many details of the application's execution are determined by the runtime, such as how data structures are laid out in memory, and how native code is generated and used. When the application is run, the runtime makes decisions about data usage and code usage while the application is running, producing native code that is specific to the platform. The process of generating native code from MSIL is called managing or just-in-time (JIT) compiling (or sometimes JITting). The component of the runtime that performs this translation step is called the JIT compiler. After the JIT compiler has compiled the MSIL for a specific method, that method's stub is replaced with the address of the compiled code. Whenever this method is later called, the native code executes and the JIT compiler does not have to be involved in the process. Building Managed Code You can build managed code by using several compilers that are manufactured by a variety of software producers. In particular, Microsoft Visual Studio .NET can build managed code from four different languages: C++ with managed extensions C# Visual Basic JScript By default, Microsoft Visual C++ .NET does not build managed applications. You must request this kind of build through a command-line switch or through the graphical interface. Debugging Managed Code You can debug managed code by using the Sos.dll extension. This extension is located in the \clr10 subdirectory of the Debugging Tools for Windows installation. To use this extension, load it and then type !clr10\sos.help.. This command lists all available extension commands and their parameters. © 2009 Microsoft Corporation Send feedback on this topic Debugging Tools for Windows January 17, 2009 Build machine: CAPEBUILD
赵4老师 2013-10-11
  • 打赏
  • 举报
回复
Debugging Tools for Windows .cordll (Control CLR Debugging) The .cordll command controls managed code debugging and the Microsoft .NET common language runtime (CLR). Syntax .cordll [Options] Parameters Options One or more of the following options: -l Loads the CLR debugging modules. -u Unloads the CLR debugging modules. -e Enables CLR debugging. -d Disables CLR debugging. -D Disables CLR debugging and unloads the CLR debugging modules. -N Reloads the CLR debugging modules. -lp Path Specifies the directory path of the CLR debugging modules. -se Enables using the short name of the CLR debugging module, mscordacwks.dll. -sd Disables using the short name of the CLR debugging module, mscordacwks.dll. Instead, the debugger uses the long name of the CLR debugging module, mscordacwks_<spec>.dll. Turning off short name usage enables you to avoid having your local CLR used if you are concerned about mismatches. -ve Turns on verbose mode for CLR module loading. -vd Turns off verbose mode for CLR module loading. Environment Modes User mode, kernel mode Targets Live, crash dump Platforms All Comments The .cordll command is supported in kernel-mode debugging. However, this command might not work unless the necessary memory is paged in. © 2009 Microsoft Corporation Send feedback on this topic Debugging Tools for Windows January 17, 2009 Build machine: CAPEBUILD
nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 12 楼 spirit008 的回复:
你5楼的图和你描述的没有出入,用dump还是挂进程跑是一模一样的, 这就是函数,感叹号前是所属模块(dll or exe),感叹号后是函数名+偏移地址。 函数参数是不能直接显示的,就是显示出来也不一定对,因为windbg只是依赖寄存器ebp+xx来猜你的函数参数, 而这个推导过程是否正确取决于你的编译选项,是否选中了帧指针优化等等因素,因为有可能函数参数只是存在了某个寄存器里而已。
可是我用setunhandledexceptionfilter()+Minidumpwritedump生成的dmp配合同版本的pdb,在windbg打开时能看到堆栈内的具体函数调用情况的
nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 12 楼 spirit008 的回复:
你5楼的图和你描述的没有出入,用dump还是挂进程跑是一模一样的, 这就是函数,感叹号前是所属模块(dll or exe),感叹号后是函数名+偏移地址。 函数参数是不能直接显示的,就是显示出来也不一定对,因为windbg只是依赖寄存器ebp+xx来猜你的函数参数, 而这个推导过程是否正确取决于你的编译选项,是否选中了帧指针优化等等因素,因为有可能函数参数只是存在了某个寄存器里而已。
有pbd文件也不行吗?我的程序是debug版本,没有经过任何优化的,按理说不是应该能显示出函数名吗?
nefory 2013-10-11
  • 打赏
  • 举报
回复
我想看到的是这种效果,但是我用!clkstack的时候显示No export clrstack found,而且我也无法加载clr,即便我是framework4.0

木头菇 2013-10-11
  • 打赏
  • 举报
回复
你5楼的图和你描述的没有出入,用dump还是挂进程跑是一模一样的,
这就是函数,感叹号前是所属模块(dll or exe),感叹号后是函数名+偏移地址。
函数参数是不能直接显示的,就是显示出来也不一定对,因为windbg只是依赖寄存器ebp+xx来猜你的函数参数,
而这个推导过程是否正确取决于你的编译选项,是否选中了帧指针优化等等因素,因为有可能函数参数只是存在了某个寄存器里而已。
nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 10 楼 nefory 的回复:
[quote=引用 8 楼 spirit008 的回复:] 你5楼的图不就是call stack?你还想看到什么?
就像这样,attach到某个进程后看堆栈内的具体内容,函数的调用,参数等 [/quote] 啧,发错图了
nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 8 楼 spirit008 的回复:
你5楼的图不就是call stack?你还想看到什么?


就像这样,attach到某个进程后看堆栈内的具体内容,函数的调用,参数等

nefory 2013-10-11
  • 打赏
  • 举报
回复
引用 8 楼 spirit008 的回复:
你5楼的图不就是call stack?你还想看到什么?
我想看堆栈里的函数和参数,就跟打开dmp文件时看到的堆栈信息那样,能做到么?
加载更多回复(8)

24,860

社区成员

发帖
与我相关
我的任务
社区描述
C/C++ 工具平台和程序库
社区管理员
  • 工具平台和程序库社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧