[Windbg] 各种dump文件分析 速查手册

http://www.dumpanalysis.org/windows-memory-analysis-checklist
http://www.windbg.org/

General:

  • Symbol servers (.symfix)
  • Internal database(s) search
  • Google or Microsoft search for suspected components as this could be a known issue. Sometimes a simple search immediately points to the fix on a vendor's site
  • The tool used to save a dump (to flag false positive, incomplete or inconsistent dumps)
  • OS/SP version (version) =>OS版本信息
  • Language
  • Debug time
  • System uptime
  • Computer name (dS srv!srvcomputername or !envvar COMPUTERNAME)
  • List of loaded and unloaded modules (lmv or !dlls) =>所有加载的驱动模块及版本信息
  • Hardware configuration (!sysinfo) => 可以PC的machieid、硬件、软件、SMBIOS等信息
  • .kframes 1000 => kb stack 深度信息, 实用

Application or service:

  • Default analysis (!analyze -v or !analyze -v -hang for hangs)
  • Critical sections (!cs -s -l -o, !locks) for both crashes and hangs
  • Component timestamps, duplication and paths. DLL Hell- (lmv and !dlls)
  • Do any newer components exist-
  • Process threads (~*kv or !uniqstack) for multiple exceptions and blocking functions
  • Process uptime
  • Your components on the full raw stack of the problem thread
  • Your components on the full raw stack of the main application thread
  • Process size
  • Number of threads
  • Gflags value (!gflag)
  • Time consumed by threads (!runaway)
  • Environment (!peb) =>程序运行的环境信息
  • Import table (!dh)
  • Hooked functions (!chkimg)
  • Exception handlers (!exchain)
  • Computer name (!envvar COMPUTERNAME)
  • Process heap stats and validation (!heap -s, !heap -s -v)
  • CLR threads- (mscorwks or clr modules on stack traces) Yes: use .NET checklist below
  • Hidden (unhandled and handled) exceptions on thread raw stacks

System hang:

  • Default analysis (!analyze -v -hang)
  • ERESOURCE contention (!locks)
  • Processes and virtual memory including session space (!vm 4)
  • Important services are present and not hanging
  • Pools (!poolused)
  • Waiting threads (!stacks) =>等待中的进程call stack。
  • Critical system queues (!exqueue f)
  • I/O (!irpfind)
  • The list of all thread stack traces (!process 0 3f)
  • LPC/ALPC chain for suspected threads (!lpc message or !alpc /m after search for "Waiting for reply to LPC" or "Waiting for reply to ALPC" in !process 0 3f output)
  • RPC threads (search for "RPCRT4!OSF" in !process 0 3f output)
  • Mutants (search for "Mutants - owning thread" in !process 0 3f output)
  • Critical sections for suspected processes (!cs -l -o -s)
  • Sessions, session processes (!session, !sprocess)
  • Processes (size, handle table size) (!process 0 0)
  • Running threads (!running)
  • Ready threads (!ready)
  • DPC queues (!dpcs)
  • The list of APCs (!apc)
  • Internal queued spinlocks (!qlocks)
  • Computer name (dS srv!srvcomputername)
  • File cache, VACB (!filecache)
  • File objects for blocked thread IRPs (!irp -> !fileobj)
  • Network (!ndiskd.miniports and !ndiskd.pktpools)
  • Disk (!scsikd.classext -> !scsikd.classext class_device 2)
  • Modules rdbss, mrxdav, mup, mrxsmb in stack traces
  • Functions Ntfs!Ntfs, nt!Fs and fltmgr!Flt* in stack traces

BSOD:

  • Default analysis (!analyze -v)
  • Pool address (!pool)
  • Component timestamps (lmv)
  • Processes and virtual memory (!vm 4) =>所有进程信息
  • Current threads on other processors
  • Raw stack
  • Bugcheck description (including ln exception address for corrupt or truncated dumps)
  • Bugcheck callback data (!bugdump for systems prior to Windows XP SP1)
  • Bugcheck secondary callback data (.enumtag)
  • Computer name (dS srv!srvcomputername)
  • Hardware configuration (!sysinfo)

.NET application or service:

  • CLR module and SOS extension versions (lmv and .chain)
  • Managed exceptions (~*e !pe)
  • Nested managed exceptions (!pe -nested)
  • Managed threads (!Threads -special)
  • Managed stack traces (~*e !CLRStack)
  • Managed execution residue (~*e !DumpStackObjects and !DumpRuntimeTypes)
  • Managed heap (!VerifyHeap, !DumpHeap -stat and !eeheap -gc)
  • GC handles (!GCHandles, !GCHandleLeaks)
  • Finalizer queue (!FinalizeQueue)
  • Sync blocks (!syncblk)

转载于:https://www.cnblogs.com/herryzz/p/10476958.html

简介: 很多被加壳的 PE 文件在脱壳以后,往往该 PE 文件的资源部分无法用某些资源查看器进行 查看、修改。这其中的主要原因是由于很多加壳程序将部分资源(如 Icon、Version Information) 从资源节 (resource section) 移到了壳增加的节里,这导致很多资源查看器不能 正确识别分布在两个节里的资源(顺便说一下,PE Explorer 基本能识别大部分这种情况的资 源),DT_FixRes 是一个 PE 文件资源修复、重建引擎,它可以将分布在多个节里的资源重新移 到一个资源节里,并且对资源进行了完全优化,修复后的资源不含有任何垃圾数据,如同资源编 译器的编译效果,可以媲美未加壳前的原始资源。通过本引擎修复、重建脱壳后的 PE 文件资源, 可以让所有资源查看器能够对资源部分进行查看、修改。使用者须通过编程方式在自己的程序中 使用该引擎。该引擎特别适合进行软件汉化工作的朋友。 声明: 1.您可以免费使用该引擎,如果您发布了使用该引擎的程序,请在相关说明中注明该引擎的版 权信息,以表示支持作者的辛勤劳动; 2.本软件是安全的,但是作者不承诺对任何由于使用本软件而引起的损失或者伤害负责。 使用说明: 本引擎以动态链接库(dll)形式实现,该 dll 共输出五个函数,函数按功能分为两大类。 第一类:PE 文件资源修复功能。修复后,引擎会无条件地为 PE 文件增加一个资源节,会导致文 件体积变大,该功能适合进行简单修复脱壳后 PE 资源部分。 <1> 输出函数 FixResFromFile C 形式函数原型: BOOL __stdcall FixResFromFile(const char* PEFile, char* ErrBuff); Delphi 形式函数原型: function FixResFromFile(const AFileName: PChar; ErrMsg: PChar): Boolean; stdcall; 参数说明: PEFile --- 指向你需要进行资源修正的 PE 文件路径指针; ErrBuff --- 指向一块至少具有 80 个字节空间的 Buffer 指针,在执行该函数返回错误时,接收 错误消息。 该函数适用任何 Win32 平台的编程语言去调用。 <2> 输出函数 FixResFromStream Delphi 形式函数原型: function FixResFromStream(AStream: TMemoryStream; ErrMsg: PChar): Boolean; 参数说明: AStream 为 PE 映象的内存流,其他说明同 <1> 。 此函数对写注册机的朋友特别适用,当你将 dump 出来的 PE 内存映象保存到硬盘之前,你可以先 进行资源修复,通过对内存流的操作,可以减少代码工作量。注意:该函数仅适用于 Delphi 语言。 第二类:导出重建后的资源节功能。由于不同的加壳程序对原始 PE 文件的结构改变的千差万别, 导致对脱壳文件的 PE 结构优化方案也是千差万别的,因此很难在一个程序里完成对所有 脱壳类型的 PE 结构优化,引擎将机会留给用户自己。作为使用者,你可能知道如何脱某 种类型的壳以及如何优化脱壳后的 PE 结构,那么你也就可能需要将修复后的资源节加载 在你认为更合适的 RVA 地址起始处。该功能接口能满足你的这个定制需要,由于该功能的 相对复杂性,要求使用者对 PE 结构必须十分属性,因此本功能仅适合高级用户使用。 <1> 输出函数 DumpResFromFile C 形式函数原型: BOOL __stdcall DumpResFromFile(const char* PEFile, char* ResFile, DWORD NewRVA, DWord FileAlign, char* ErrBuff); Delphi 形式函数原型: function DumpResFromFile(const PEFile: PChar; const ResFile: PChar; NewRVA: DWord; FileAlign: DWord; ErrMsg: PChar): Boolean; stdcall; 参数说明: PEFile --- 指向你需要进行资源修正的 PE 文件路径指针; ResFile --- 指向你需要导出的资源节的保存文件路径; NewRVA --- 你希望修复后的 PE 文件资源的加载 RVA 地址,即 resouce data directroy 的 virtual address。该地址应该大于 0x1000,并且应该是 DWORD 边界对齐,建议是 0x1000 的倍数。 FileAlign --- 资源节的文件对齐方式,值只能是 0x200 或者 0x1000。 ErrBuff --- 指向一块至少具有 80 个字节空间的 Buffer 指针,在执行该函数返回错误时,接收 错误消息。 该函数适用任何 Win32 平台的编程语言去调用。 <2> 输出函数 DumpResFromStream Delphi 形式函数原型: function DumpResFromStream(PEStream: TMemoryStream; const ResFile: string; NewRVA: DWord; FileAlign: DWord; ErrMsg: PChar): Boolean; 参数说明: PEStream 为 PE 映象的内存流,其他说明同 <1> 。 通过对内存流的操作,可以减少代码工作量。注意:该函数仅适用于 Delphi 语言。 <3> 输出函数 DumpResFromStreamEx Delphi 形式函数原型: function DumpResFromStreamEx(PEStream: TMemoryStream; ResStream: TMemoryStream; NewRVA: DWord; FileAlign: DWord; ErrMsg: PChar): Boolean; 此函数对写注册机的朋友特别适用,当你将 dump 出来的 PE 内存映象保存到硬盘之前,你可能需 要进行 PE 结构的优化,在优化之前很可能需要导出重建的资源节。通过对内存流的操作,可以减 少代码工作量。注意:该函数仅适用于 Delphi 语言。 特别提示:引擎只在正确 PE 格式的基础上修复、重建 PE 资源,因此应用以上五个函数之前请保 证被操作文件或者内存流均具有正确的 PE 格式,否则可能造成不可预期的错误。 调用范例(Delphi 语言): procedure FixResDemo; type TFixPERes = function(const AFileName: PChar; ErrBuff: PChar): Boolean; stdcall; var ErrBuff: array[1..80] of Char; Handle: THandle; FixPERes: TFixPERes; begin Handle := LoadLibrary('DT_FixRes.dll'); if Handle <> 0 then begin @FixPERes := GetProcAddress(Handle, 'FixResFromFile'); if @FixPERes <> nil then if not FixPERes(PChar('ur PE file'), @ErrBuff) then ShowMessage(ErrBuff); FreeLibrary(Handle); end; end;
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值