windbg

问题 Is there a way from WinDbg, without using the DbgEng API, to display the symbol server paths (i.e. PdbSig70 and PdbAge) for all loaded modules? I know that lml does this for the modules whose symbols have loaded. I would like to know these paths for the symbols that did not load so as to diagnose the problem. Anyone know if this is possible without having to utilize the DbgEng API? edited: I also realize that you can use !sym noisy to get error messages about symbols loading. While this does

问题 I have my application crashing with following CallStack on the error (from WinDbg): ntdll!ZwWaitForMultipleObjects+0xa KERNELBASE!WaitForMultipleObjectsEx+0xe8 kernel32!WaitForMultipleObjectsExImplementation+0xb3 clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x91 clr!Thread::DoAppropriateAptStateWait+0x56 clr!Thread::DoAppropriateWaitWorker+0x1b1 clr!Thread::DoAppropriateWait+0x73 clr!CLREvent::WaitEx+0xc1 clr!CLREventWaitWithTry+0x5c clr! ?? ::FNODOBFM::`string'+0x6286a clr

问题 My dump file contains OutOfMemoryException but all the object fields seem to be null. Is it just a false alarm or is there someway to know about this exception? 0:052> !do 000000027fff10e8 The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. CLR Version: 4.0.30319.18449 SOS Version: 4.0.30319.34011 Name: System.OutOfMemoryException MethodTable: 000007fcb5476920 EEClass: 000007fcb4f3cd88 Size:

问题 How I can obtain file path from handle with windbg/kd in kernel mode? 回答1: Use !handle <handle_num> 7 <proc_id> to display detailed information for that handle where <handle_num> is the handle value and <proc_id> is the process id value (both hex based) see this msdn link for further information. You can gleam your process id from a user mode session, this is the easiest method, just attach in user mode and enter the pipe command | and it will output like so: . 0 id: 1680 attach name: D:\test

问题 I'm trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86. Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine. From the following windbg log I understand that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols. I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard

问题 I'm trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86. Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine. From the following windbg log I understand that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols. I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard

问题 We see lots of callstack like the below, may I know what's conditions \situation would happens this? OS Thread Id: 0x48654 (559) Current frame: ntdll!NtWaitForSingleObject+0xa Child-SP RetAddr Caller, Callee 00000020a76cf480 00007fffd4ea1118 KERNELBASE!WaitForSingleObjectEx+0x94, calling ntdll!NtWaitForSingleObject 00000020a76cf520 00007fffce50ce66 clr!CLRSemaphore::Wait+0x8a, calling kernel32!WaitForSingleObjectEx 00000020a76cf5e0 00007fffce50d247 clr!ThreadpoolMgr::UnfairSemaphore::Wait

问题 I'm trying to load a dll in WinDbg and got this error. Here goes the detail. Build A.dll using VisualC++ express. Place A.pdb and A.dll in d:\test\ directory. Set the image path and symbol path to d:\test .sympath gives OK D:\test try loading by using the following command .reload /f A.dll and it gives "A.dll" was not found in the image list. Debugger will attempt to load "A.dll" at given base 00000000. Please provide the full image name, including the extension (i.e. kernel32.dll) for more

问题 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

问题 I'm a complete WinDbg newbie and I've been trying to debug a WindowsXP problem that a customer has sent me where our software and some third party software prevent windows from logging off. I've reproduced the problem and have verified that only when our software and the customers software are both installed (although not necessarily running at logoff) does the log off problem occur. I've observed that WM_ENDSESSION messages are not reaching the running windows when the user tries to log off