sos

问题 I have a managed code Windows Service application that is crashing occasionally in production due to a managed StackOverFlowException. I know this because I've run adplus in crash mode and analyzed the crash dump post mortem using SoS. I have even attached the windbg debugger and set it to "go unhandled exception". My problem is, I can't see any of the managed stacks or switch to any of the threads. They're all being torn down by the time the debugger breaks. I'm not a Windbg expert, and,

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

问题 Let's say I have a memory dump of a process. I want to run a report on it, so essentially I want to open WinDBG, load SOS and run a script that runs some commands, parses the output and then runs some more commands based on that. Apart from hackish stuff like SendKeys, is there a way to automate/script this process? Or can I write my own tool on top of SOS.dll/whatever? 回答1: The best way to do this is through a DbgEng based application. Essentially this serves as a replacement for WinDBG,

问题 I've started to read some materials on advanced debugging tools and techniques. I use VS2012 Ultimate and the target framework is .NET 4.0. I got to the point where I need to load SOS.dll in the Immediate window during a debug session and it just doesn't work. I tried these with no luck .load sos .load sos.dll .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll I always get this message: Invalid expression term '.' So, any idea ? What am I missing here ? 回答1: You can change this

问题 I have a simple test program causing an infinite wait on lock. public class SyncBlock { } class Program { public static SyncBlock sync = new SyncBlock(); private static void ThreadProc() { try { Monitor.Enter(sync); } catch (Exception) { //Monitor.Exit(sync); Console.WriteLine("3rd party code threw an exception"); } } static void Main(string[] args) { Thread newThread = new Thread(ThreadProc); newThread.Start(); Console.WriteLine("Acquiring lock"); Monitor.Enter(sync); Console.WriteLine(

问题 Is there a Windbg/NTSD command to tell me if a process I have attached to in a live debugging session is a 32-bit one or a 64-bit one? Could you please tell me for both: An unmanaged process? and A managed one? For a managed one, I can find that out programmatically in C# but still I'd like to know if there's a Windbg command for this. UPDATE The target process I am debugging is Microsoft Word (winword.exe). The Office version is 2016 but I am not sure if it is a 32-bit or a 64-bit binary.

问题 How do I dump a struct using windbg, is there a dumpstruct command similar to dumpobject? Or can dumpobject dump structs aswell? 回答1: Yes, you could use the !dumpvc command. Since structs don't have an object header, the debugger doesn't know its type, so you will have to pass it the struct's MethodTable address. >!DumpVC <METHOD_TABLE_ADDRESS> <OBJECT_ADDRESS> 来源： https://stackoverflow.com/questions/3717292/windbg-with-sos-how-to-dump-a-c-sharp-struct

问题 I have a dump which has both .NET versions loaded: 0:000> lm m clr start end module name 65490000 65aff000 clr (deferred) 0:000> lm m mscorwks start end module name 6a980000 6af2c000 mscorwks (deferred) Now I'm uncertain which version of SOS to use. Both will load without problems. 0:000> .loadby sos mscorwks 0:000> .loadby sos clr How would I find out which version to use best for my analysis? Or will I always need both? Is .cordll -ve -u -l reliable in this case? .symfix c:\symbols .cordll

问题 I am using WinDbg to look into a process dump. The dump has been taken on an x86 server with .NET 4 SP1 (4.0.30319.237). I'm attempting to debug on my x64 machine using the x86 version of WinDbg, but I get the following issue. 0:000> !EEVersion 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.237 SOS Version: 4.0.30319.239 4.0.30319.237 retail Workstation mode SOS

问题 I'm looking into why a managed process is using a lot of memory. Is there a way to run GC.Collect(3) from WinDbg, so that I can focus on the actual memory allocation? 回答1: I don't think there is any way to run a .NET garbage collection from WinDbg, but I also don't think it is necessary. See Rico Mariani's Performance Tidbits - Tracking down managed memory leaks (how to find a GC leak) for information about finding out what kind of stuff is on your heap. Additional possibly useful links: When