windbg

In windbg, what can cause the message “WARNING: Unable to verify timestamp for mydll.dll”?

由 我的未来我决定 提交于 2019-12-05 23:02:23
问题 I have a dump (created by SysInternal's procdump ) and when I ask to view the call stack of a thread I get the error: "WARNING: Unable to verify timestamp for mydll.dll" I own the source code for mydll.dll and I have the PDB file for it, the call stack seems valid but I would like to know what can be the cause of the message. In the past I did not get that warning message. Thank you. 回答1: The reason might be that you don’t have the the binary for your mydll.dll available. Try to either put it

sos.dll usage in visual studio 2013

由 梦想的初衷 提交于 2019-12-05 22:55:58
问题 When I am reading docs about sos.dll @MSDN, encounter a note says If you are using Visual Studio 2013, SOS.dll is supported in the Windows Debugger within Visual Studio I know how to use sos.dll in the immediate window in Visual Studio 2012. But how to use sos.dll with visual studio 2013 debugger? 回答1: From MSDN documentation of What’s New for the Debugger in Visual Studio 2013 (Excerpt from the part Debug With Debugging Tools for Windows ) The SOS.dll (SOS Debugging Extension) that helps you

将windbg与.dmp文件关联

由 夙愿已清 提交于 2019-12-05 22:17:14
如果您厌倦了启动调试器、加载转储文件、设置sympath、加载扩展名等，这里有一个很好的方法，可以在.dmp文件的上下文菜单上获取“调试此转储文件”，并自动加载所有您喜欢的命令。 首先创建一个包含以下内容的.reg文件（在修改注册表时一定要非常小心） Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.dmp] @="Debugger.Dump" [HKEY_CLASSES_ROOT\Debugger.Dump] [HKEY_CLASSES_ROOT\Debugger.Dump\DefaultIcon] @="c:\\debuggers\\cdb.exe" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell] [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_Without_Remote] @="Debug This Dump" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_Without_Remote\Command] @="\"C:\\debuggers\\windbg\" -z \"%1\" -c \"$<c:\\debuggers\\commands.txt\"" [HKEY_CLASSES_ROOT

Process Heap Segments And Their Necessity

由 孤街浪徒 提交于 2019-12-05 21:54:39
While dumping heap of a win32 processes (Mostly in process which has high heap memory consumption like IE ) using !heap -a 004e0000 I find multiple segments of a particular heap like , Heap entries for Segment00 in Heap 004e0000 Heap entries for Segment01 in Heap 004e0000 Heap entries for Segment02 in Heap 004e0000 My questions are Question 1. Why its necessory to divide single heap into multiple segments ? Question 2. Most of the times I find a large gap between two segments. For example in below image Segment00 actually ends @ 0x005e0000 (Where un-commited bytes started) and Segment01

Mismatch in object size returned by sos.dll and in-memory process size

由 戏子无情 提交于 2019-12-05 21:41:59
I have used the following sos command to enumerate all instances of a particular type in a running asp application (hosted on windows xp 4 GB machine). .foreach (obj { !dumpheap -type ::my type:: -short ::start of address space:: ::end of address space:: }) { !objsize ${obj} }. This enumerates all objects of the given type in gc gen2. The object size on an average seems to be around 500 KB and there are around 2000 objects. This alone adds up to around 1 GB of memory whereas my asp-process memory in task manager shows only around 700 MB. One more point is that I haven't considered other loaded

Troubleshooting a COM+ application deadlock

由 谁说胖子不能爱 提交于 2019-12-05 21:26:43
I'm trying to troubleshoot a COM+ application that deadlocks intermittently. The last time it locked up, I was able to take a usermode dump of the dllhost process and analyze it using WinDbg. After inspecting all the threads and locks, it all boils down to a critical section owned by this thread: ChildEBP RetAddr Args to Child 0deefd00 7c822114 77e6bb08 000004d4 00000000 ntdll!KiFastSystemCallRet 0deefd04 77e6bb08 000004d4 00000000 0deefd48 ntdll!ZwWaitForSingleObject+0xc 0deefd74 77e6ba72 000004d4 00002710 00000000 kernel32!WaitForSingleObjectEx+0xac 0deefd88 75bb22b9 000004d4 00002710

How can the stack be broken at the very start of application

由 旧时模样 提交于 2019-12-05 20:36:47
The stack frame pointer (EBP) should always point to where the previous stack frame was right but why is that not the case in my application! That would indicate something is really wrong..hard to believe! I created multiple simple demo applications where the stack pointer always points to the previous stack frame but I can't make sense of why this is not the case in this application and it is happening when my application is just starting up! The following is my call stack 0:000> k # ChildEBP RetAddr 00 0018fee4 6381d1cd acn!CAcnApp::InitInstance+0x41 [c:\acn-project\acn\acn.cpp @ 527] 01

application exits (no Exception) when referencing 64bit dll from C#

由 余生长醉 提交于 2019-12-05 19:56:50
问题 I've compiled lzo2.dll 64 bit and now looking to use it in a C# program: I'm using the following class to test (similar code works for 32bit lzo.dll): [DllImport("lzo2.dll")] private static extern string lzo_version_string(); static void Main(string[] args) { try { if (Environment.Is64BitProcess) { Console.WriteLine(lzo_version_string());//application exits here, no exceptions caught } } catch (Exception e) { Console.WriteLine(e); } Console.ReadLine(); } At the point indicated the application

private symbol loaded but no line number displayed?

由 江枫思渺然 提交于 2019-12-05 19:22:36
I am using Windbg to load a crash dump from managed code (C#, a console application built for Any CPU), and crash dump is created on x64 platform. I am debugging on x64 platform. I have using the following command to load private symbol of my application. Here are what the commands I am using in Windbg. (set symbol path and copy FooService.pdb pdb file to local symbol path D:\Debug) 0:016> .reload /f .*** WARNING: Unable to verify checksum for FooService.exe DBGHELP: FooService.pdb- private symbols & lines D:\Debug\FooService.pdb 0:016> lm start end module name 00000000`00400000 00000000

Driver load/unload fails if WinDbg attached with breakpoint

由 匆匆过客 提交于 2019-12-05 18:31:38
I just started with driver development. For some experiments with loading, unloading and debugging I have written the following simple driver: #include <ntddk.h> void DriverUnload(PDRIVER_OBJECT pDriverObject) { UNREFERENCED_PARAMETER(pDriverObject); DbgPrint("Driver unloading\n"); } NTSTATUS DriverEntry( PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { UNREFERENCED_PARAMETER(DriverObject); UNREFERENCED_PARAMETER(RegistryPath); DriverObject->DriverUnload = DriverUnload; DbgPrint("Hello, World\n"); return STATUS_SUCCESS; } I compiled the driver for my target system, Windows 7 64bit,
订阅 windbg