我正在使用WINDBG来分析转储文件,以查找内存使用率过高的程序.
其中一个涉及的对象是持有一个对象数组,引用我想看的很多对象,试图找出它们被分配的原因.
这是我尝试过的:
首先,我的ServiceContainer对象集合:
0:000> !do 05633014
Name: System.Collections.Generic.List`1[[LVK.IoC.ServiceContainer, LVK.Core]]
MethodTable: 08b3c7fc
EEClass: 6f70ca78
Size: 24(0x18) bytes
(C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Fields:
MT Field Offset Type VT Attr Value Name
6f924324 40009d8 4 System.Object[] 0 instance 1da226ec _items
6f952da0 40009d9 c System.Int32 1 instance 5356 _size
6f952da0 40009da 10 System.Int32 1 instance 5538 _version
6f950770 40009db 8 System.Object 0 instance 00000000 _syncRoot
6f924324 40009dc 0 System.Object[] 0 shared static _emptyArray
>> Domain:Value dynamic statics NYI
002b2a28:NotInit <<
那个_items数组是我想看的那个,所以我发出了这个命令:
0:000> !do 1da226ec …我将WinDbg附加到一个正在运行的进程并让进程崩溃(我有一个单独的问题重新说明那个案例).程序崩溃后,WinDbg停止并允许我调试程序.我使用命令".dump/ma"进行了故障转储以进行进一步调查.
该程序编译为"任何CPU",我使用WinDbg x64进行转储.现在我再次在同一台计算机上打开WinDbg x64并打开故障转储.这是它说的:
Loading Dump File [C:\crashdump.dmp]
User Mini Dump File with Full Memory: Only application data is available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00)
System Uptime: 17 days 0:54:39.021
Process Uptime: 12 days 14:01:31.000
................................................................
...............................................................
This dump file has an exception of interest stored in …我正在尝试从此页面安装WinDbg ,就在Windows 10调试工具(WinDbg)部分下.但是,当我下载可执行文件并运行它时,它告诉我
必须先卸载Windows软件开发工具包 - Windows 10.0.10586.15,然后才能安装最新版本的工具包.
我猜这可能与我已经安装了VS 2015(和Windows 10 SDK)的事实有关.但是,当我转到Developer Command Prompt并输入时
> where windbg
它告诉我它找不到WinDbg.那么,如何安装它而不做任何激烈的事情(比如重新安装Visual Studio)？
我尝试使用windbg在输入成员函数时打印"this"指针,如下所示.
class IBase {
int m_i;
public:
IBase() :m_i(23) {}
virtual int FuncOne(void) = 0;
virtual int FuncTwo(void) = 0;
};
class DerivedOne : public IBase {
public:
virtual int FuncOne(void) { return 1; };//set break point here.
virtual int FuncTwo(void) { return 2; };
};
class DerivedTwo : public IBase {
public:
virtual int FuncOne(void) { return 101; };
virtual int FuncTwo(void) { return 102; };
};
void DoIt(IBase* Base)
{
int i=Base->FuncOne();//break point here
}
int main(int argc, …有没有办法从另一个进程或WinDBG内部触发.NET进程中的垃圾回收？
有一些托管调试助手在您跨越本机/托管边界时强制收集,而AQTime似乎有一个按钮,建议它执行此操作,但我找不到任何有关如何执行此操作的文档.
我一直在做一些关于高内存问题的工作,我在windbg中做了很多堆分析,我很好奇不同的列在"!heap -flt -s xxxx"命令中的含义.
我读了windbg!heap输出中'size'数字的含义是什么？,我查看了我的"Windows Internals"一书,但我仍然有一堆问题.所以列和我的问题如下.
**HEAP_ENTRY** - What does this pointer really point to? How is it different than UserPtr?
**Size** - What does this size mean? How is it different than UserSize?
**Prev** - This just appears to be the negative offset to get to the previous heap entry. Still not sure exactly how it's used.
**Flags** - Is there any documentation on these flags?
**UserPtr** - What is the user pointer? In all cases I've …当我使用Windbg的"Open Executable ..."功能来使用Windbg逐步执行可执行文件时,是否可以指定在运行可执行文件时使用的命令行参数？如果是这样,我该怎么做呢？
我正在IIS 7.5下运行ASP.NET 4.0应用程序.一天几次,我们的应用程序池意外回收.发生这种情况时,我们的系统日志显示以下事件:
为应用程序池"X"提供服务的进程与Windows进程激活服务发生致命的通信错误.进程ID为'5768'.数据字段包含错误编号.
要么
为应用程序池"X"提供服务的进程无法响应ping.进程ID为"1032".
几乎总是,在应用程序日志中的完全相同的时间有一个相应的事件,如下所示:
Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b
Faulting module name: clr.dll, version: 4.0.30319.269, time stamp: 0x4ee9ae83
Exception code: 0xc00000fd
Fault offset: 0x00001916
Faulting process id: 0x508
Faulting application start time: 0x01cd4d8958ecf9ad
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 8dcc413b-b98a-11e1-8075-001c23d6d910
因此,我安装了IIS调试工具并设置了崩溃规则,指定了"特定的IIS Web应用程序池",没有记录第一次机会异常,也没有"高级设置"(例外,断点,事件)下的任何内容.
我也(同时)使用以下命令行从Windows调试工具运行ADPlus:
adplus -crash -pn w3wp.exe -NoDumpOnFirst -o c:\logs
但是,由于我已经附加了调试器,我在系统日志中收到了几条"警告"级别的消息(关于"进程服务应用程序池'X'遭遇了致命的通信错误......"),但是我我不再在应用程序日志中获得相应的错误级别事件.
我唯一能得到的是以下(其中约有50个):
[6/18/2012 7:50:25 PM] Thread exited. Exiting thread system id - System ID: 3300. Exit code …我正在尝试使用WinDBG来分析我们的一台生产机器的崩溃转储.我的问题的根源似乎是我有一个不同于生产机器的.NET框架版本,只是我不知道如何解决问题.当我转!sym吵闹然后运行!dlk(来自SOSEX)我得到以下错误,因为它试图找到mscordacwks dll
0:000> !dlk
CLRDLL: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll:2.0.50727.3623 f:0
doesn't match desired version 2.0.50727.3607 f:0
SYMSRV: c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3607.dll/4ADD5446590000/mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV: c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV: c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3607.dll/4ADD5446590000/mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV: c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
CLRDLL: Unable to find mscordacwks_x86_x86_2.0.50727.3607.dll by mscorwks search
CLRDLL: Unable to find 'mscordacwks_x86_x86_2.0.50727.3607.dll' on the path
SYMSRV: c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/mscorwks.dll/4ADD5446590000/mscorwks.dll not found
SYMSRV: c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\mscorwks.dll - file not found
SYMSRV: c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found …在上个月,我们的ASP.NET Web应用程序已停止响应请求,我们不得不重置应用程序池以使其备份.
我们无法确定问题的确切原因,因为服务器的事件日志中没有错误.该网站只是停止响应.
因此,我们一直在使用WinDbg来尝试分析在Tess Ferrandez的博客条目帮助下网站没有响应的内存转储:GC挂起和高CPU挂起
通过运行,!threadpool我可以看到以下内容:
CPU utilization: 81%
Worker Thread: Total: 10 Running: 8 Idle: 2 MaxLimit: 400 MinLimit: 160
Work Request in Queue: 1930
--------------------------------------
Number of Timers: 72
--------------------------------------
Completion Port Thread:Total: 1 Free: 1 MaxFree: 8 CurrentLimit: 0 MaxLimit: 400 MinLimit: 120
根据Tess在悬挂博客文章中的说法,这表明我们陷入垃圾收集的中间(通常需要纳秒时间),因为处理器显示81%,这是.NET框架设置的内容虽然这是垃圾收集.它设置为this,因为当此值大于80%时,不会生成新线程.此外 - 您可以看到队列中有1930个请求,即使可能有400个工作线程只有10个.
通过运行该!threads命令,我可以看到两个PreEmptive GC设置为禁用的线程:
PreEmptive GC Alloc Lock
ID OSID ThreadOBJ State GC Context Domain Count APT Exception
10 1 18bc 00000000001b9710 …